Konfiguracja sieci na stałe

Wstęp

W nocy przyszła aktualizacja jądra. Serwer się zrestartował, sam, tak jak miał. I wstał z innym adresem. Bo ktoś kiedyś ustawił adres przez ip addr add i poszło do domu. Albo zostawił DHCP, a router przydzielił nowy numer. Strona nie działa, bo DNS dalej wskazuje stary adres.

Serwer musi mieć adres stały, zapisany w konfiguracji. Problem: Ubuntu i Red Hat robią to zupełnie inaczej. Poznasz oba sposoby.

Kto rządzi siecią

W jądrze siedzą adresy i trasy, które oglądałeś w lekcji 69. Ktoś musi je tam wpisać przy starcie. To robi usługa sieciowa, która czyta pliki konfiguracji.

[Ubuntu] Na Ubuntu Server konfigurację piszesz dla netplana, w plikach YAML w /etc/netplan/. Netplan sam niczego nie konfiguruje. On tłumaczy Twój plik na język wykonawcy, którego nazywa rendererem. Na serwerze wykonawcą jest zwykle systemd-networkd, na desktopie NetworkManager. Jak tłumacz w ambasadzie: Ty mówisz po swojemu, on przekłada na język urzędnika, który akurat siedzi w okienku.

[RHEL] Na Red Hacie, Rocky i Almie rządzi NetworkManager. Trzyma profile połączeń, każdy w osobnym pliku w /etc/NetworkManager/system-connections/. Dawne pliki ifcfg-eth0 w /etc/sysconfig/network-scripts/ to przeszłość: RHEL 9 zapisuje profile w nowym formacie keyfile, a RHEL 10 wsparcie dla ifcfg usunął całkiem. Jeśli tutorial każe Ci edytować ifcfg-eth0, to jest tutorial z czasów, kiedy telefony miały klapkę.

Netplan na Ubuntu

Najpierw zobacz, co już jest:

ls -l /etc/netplan/
sudo cat /etc/netplan/50-cloud-init.yaml

Na świeżej instalacji serwera często znajdziesz plik z instalatora albo cloud-init, mniej więcej taki:

network:
  version: 2
  ethernets:
    enp1s0:
      dhcp4: true

Czytamy jak list: sieć, wersja formatu 2, karty ethernetowe, karta enp1s0, adres z DHCP. Teraz piszemy stały adres. Robię nowy plik, żeby nie grzebać w cudzym:

sudo nano /etc/netplan/60-staly-adres.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp1s0:
      dhcp4: false
      addresses:
        - 192.168.1.50/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [192.168.1.1, 9.9.9.9]
        search: [firma.lan]

Adres z maską, trasa domyślna przez bramę, dwa serwery DNS i domena wyszukiwania. Dzięki niej wpisujesz ping nas, a system sam dopisuje .firma.lan.

Trzy zasady YAML, bo YAML jest jak teściowa: wszystko widzi i nic nie wybacza.

1. Wcięcia tylko spacjami. Tabulator to błąd.
2. Wcięcie decyduje, co do czego należy. Jedna spacja za dużo i adres należy do innej karty albo do nikogo.
3. Po dwukropku spacja.

Pliki są czytane w kolejności alfabetycznej i łączone. Późniejszy plik nadpisuje wcześniejszy. Mój 60-... wygrywa z 50-cloud-init.yaml, więc dhcp4: false z mojego pliku zastąpi true z tamtego. Co wyszło z połączenia, pokaże:

sudo netplan get

Pliki mają być czytelne tylko dla roota, bo czasem trzymają hasła do Wi-Fi. Jeśli zapomnisz, netplan Ci o tym przypomni:

WARNING **: Permissions for /etc/netplan/60-staly-adres.yaml are too open. Netplan configuration should NOT be accessible by others.

sudo chmod 600 /etc/netplan/60-staly-adres.yaml

netplan try — spadochron

Teraz najważniejsza komenda tej lekcji. Jeśli zmieniasz sieć serwera przez SSH, nigdy nie zaczynaj od apply. Zaczynaj od:

sudo netplan try

Netplan włącza nową konfigurację i pyta, czy chcesz ją zachować. Masz nacisnąć Enter. Domyślnie czeka 120 sekund. Jeśli w tym czasie nie potwierdzisz, sam wraca do poprzedniej konfiguracji i wypisuje Reverting.

Po co? Bo jeśli pomyliłeś adres, to straciłeś SSH i nie możesz nacisnąć Entera. Wtedy po dwóch minutach serwer sam wraca do starego adresu i możesz się zalogować ponownie. To jak spadochron, który otwiera się sam, kiedy skoczek zapomni pociągnąć za linkę. Kiedy wszystko działa i już potwierdziłeś, zatwierdzasz zmiany na dobre:

sudo netplan apply
ip -br a show enp1s0
ip r

Czas możesz zmienić opcją --timeout, na przykład sudo netplan try --timeout 60.

Uwaga na cloud-init. Na maszynach w chmurze i z niektórych instalatorów plik 50-cloud-init.yaml może zostać nadpisany przy restarcie. W nagłówku tego pliku jest instrukcja, jak to wyłączyć: plik /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg z treścią network: {config: disabled}. Przeczytaj nagłówek swojego pliku, zanim zaczniesz.

NetworkManager i nmcli na RHEL

NetworkManager to zarządca budynku z segregatorem. Dla każdej karty ma profil, kartę meldunkową: jaki adres, jaka brama, jaki DNS. Profil to nie karta. Jedna karta może mieć kilka profili, na przykład „biuro” i „dom”, ale aktywny jest jeden naraz.

Narzędzie do rozmowy z zarządcą to nmcli. Najpierw rozpoznanie:

nmcli device status        # karty i to, czy mają aktywny profil
nmcli con show             # profile, w skrócie od connection

Zwykle zobaczysz profil o nazwie takiej jak karta, na przykład enp1s0, ustawiony na DHCP. Zmieniam go na stały adres:

sudo nmcli con mod enp1s0 ipv4.method manual ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 ipv4.dns '192.168.1.1 9.9.9.9' ipv4.dns-search firma.lan
sudo nmcli con up enp1s0

ipv4.method manual to „adres wpisuję sam, nie pytaj DHCP”. DHCP to auto. I teraz rzecz, na której wyłożył się każdy: con mod zmienia tylko kartkę w segregatorze. Karta sieciowa dalej działa po staremu. Dopiero con up mówi zarządcy: „wdroż to teraz”. Zapomnisz con up, to zmiana zadziała dopiero po restarcie, czyli zwykle o 3:12 w nocy.

Sprawdzam, co jest w profilu. Przetestowałem to na własnym profilu testowym lab70-staly:

nmcli -f ipv4.method,ipv4.addresses,ipv4.gateway,ipv4.dns,connection.autoconnect con show lab70-staly

ipv4.method:                            manual
ipv4.addresses:                         192.168.1.50/24
ipv4.gateway:                           192.168.1.1
ipv4.dns:                               192.168.1.1,9.9.9.9
connection.autoconnect:                 no

Drugi adres dodajesz plusem, bez plusa zastąpisz wszystkie:

sudo nmcli con mod lab70-staly +ipv4.addresses 192.168.1.51/24
nmcli -g ipv4.addresses con show lab70-staly

192.168.1.50/24, 192.168.1.51/24

Nowy profil od zera to nmcli con add. A jak wygląda kartka w segregatorze? Na RHEL 9 i 10 to plik w /etc/NetworkManager/system-connections/NAZWA.nmconnection. Taki plik dla stałego adresu wygląda tak:

[connection]
id=serwer-lan
uuid=5eda7eed-586c-4d99-8e4a-c1ae57bb8ca4
type=ethernet
interface-name=enp1s0

[ipv4]
address1=192.168.1.50/24,192.168.1.1
dns=192.168.1.1;9.9.9.9;
method=manual

Zwykły plik tekstowy w stylu INI. Można go edytować ręcznie, ale potem trzeba powiedzieć zarządcy, żeby przeczytał segregator od nowa: sudo nmcli con reload. Na egzaminie i w pracy bezpieczniej używać nmcli, bo sprawdza błędy, zanim zapisze.

nmtui — okienka dla zestresowanych

Nie pamiętasz składni? sudo nmtui otwiera tekstowe okienka, sterowane strzałkami i Enterem, jak instalator z lat dziewięćdziesiątych. Edit a connection, wybierasz profil, wpisujesz adres, OK. Potem Activate a connection, wyłączasz i włączasz profil, żeby zmiany weszły. Ten sam zarządca, ten sam segregator, tylko formularz zamiast dyktowania. Na egzaminie RHCSA to zupełnie legalna droga.

Nazwa komputera — hostnamectl

Nazwa komputera to tabliczka na drzwiach budynku. Zmieniasz ją tak, na obu rodzinach:

sudo hostnamectl set-hostname serwer1
hostnamectl

Nazwa zapisuje się do pliku /etc/hostname i przetrwa restart. Sam hostnamectl bez argumentów pokazuje nazwę i informacje o systemie. Nowsze wersje mają też krótszy zapis: hostnamectl hostname serwer1. Znak zachęty w terminalu zmieni się dopiero w nowej sesji. Nie panikuj, że nie zadziałało.

/etc/hosts — notes przy telefonie

Zanim komputer zapyta biuro numerów, czyli DNS, zagląda do notesu przy telefonie. To plik /etc/hosts. Kolejność ustala linijka w /etc/nsswitch.conf:

grep ^hosts: /etc/nsswitch.conf

hosts:          files dns

files przed dns: najpierw notes, potem biuro numerów. Dopisuję do notesu domowy serwer plików:

echo '192.168.1.50   nas.firma.lan   nas' | sudo tee -a /etc/hosts
getent hosts nas

192.168.1.50    nas.firma.lan nas

Adres, pełna nazwa, skróty. getent pyta system dokładnie tak, jak pytają programy, więc to najlepszy test. W pracy /etc/hosts przydaje się do szybkich testów i małych sieci. Przy dziesięciu serwerach to już robota dla prawdziwego DNS, bo dziesięć notesów zawsze się rozjedzie.

/etc/resolv.conf i resolvectl — które biuro numerów

/etc/resolv.conf mówi programom, gdzie jest DNS. Zasada na obu rodzinach: nie edytuj go ręcznie. Ten plik należy do usługi sieciowej i ona go nadpisze przy najbliższej okazji. Jak kartka na lodówce we wspólnym mieszkaniu: możesz dopisać „kup mleko”, ale wieczorem i tak ktoś ją wyrzuci.

DNS ustawiasz tam, gdzie adres: w netplanie (nameservers:) albo w nmcli (ipv4.dns).

[Ubuntu] /etc/resolv.conf to drogowskaz do pliku od systemd-resolved, a w środku stoi nameserver 127.0.0.53, czyli lokalny pośrednik. Prawdziwe serwery i całą resztę pokazuje:

resolvectl status              # serwery DNS globalnie i dla każdej karty
resolvectl query nas.firma.lan # zapytaj o nazwę przez resolved
sudo resolvectl flush-caches   # wyczyść pamięć podręczną DNS

resolvectl status wypisze dla karty enp1s0 linię DNS Servers z adresami z Twojego netplana. Jeśli ich tam nie ma, netplan ich nie przekazał i szukasz błędu w YAML.

[RHEL] Zwykle NetworkManager wpisuje serwery bezpośrednio do /etc/resolv.conf i cat wystarczy. Podgląd tego, co ustawił NetworkManager: nmcli dev show enp1s0 | grep DNS.

Jak to działa pod spodem

Netplan nie dotyka karty sieciowej. Komenda netplan generate czyta YAML i produkuje pliki dla wykonawcy. Zrobiłem to w osobnym katalogu, żeby podejrzeć wynik:

sudo netplan generate --root-dir lab
cat lab/run/systemd/network/10-netplan-enp1s0.network

[Match]
Name=enp1s0

[Network]
LinkLocalAddressing=ipv6
Address=192.168.1.50/24
DNS=192.168.1.1
DNS=9.9.9.9
Domains=firma.lan

[Route]
Destination=0.0.0.0/0
Gateway=192.168.1.1

To jest Twój YAML przetłumaczony na język systemd-networkd. Ląduje w /run, czyli w pamięci, i jest generowany od nowa przy każdym starcie. Dlatego nie edytujesz tych plików: źródłem prawdy jest /etc/netplan. netplan apply robi generate i każe wykonawcy wdrożyć wynik.

A potem? Zarówno systemd-networkd, jak i NetworkManager robią dokładnie to, co Ty robiłeś ręcznie w lekcji 69. Mówią jądru przez netlink: „podnieś kartę, dodaj adres, dodaj trasę”. Dlatego wynik zawsze sprawdzasz przez ip a i ip r. Konfiguracja to obietnica. ip pokazuje, co z niej zostało.

Ściąga flag