Statisch IP-adres instellen onder Debian en Ubuntu

Vier gegevens die u moet hebben voordat u begint

Een statisch adres is zo ingevoerd. Dat er toch zoveel servers na een herstart zwijgen, ligt bijna nooit aan de syntaxis. Het ligt eraan dat een van de vier basisgegevens geraden is in plaats van afgelezen: de naam van de interface, het adres inclusief prefixlengte, de gateway en de nameservers. Lees deze waarden af terwijl de machine nog draait en bereikbaar is.

ip -brief address show
ip -4 route show
ip -6 route show
cat /etc/resolv.conf

De eerste regel levert de naam van de interface. Op virtuele servers heet die afhankelijk van het platform ens3, enp1s0 of eth0, op fysieke machines vaak eno1. Neem de naam letterlijk over en raad hem niet. Een typefout op deze plek levert een syntactisch foutloze configuratie op die eenvoudigweg bij geen enkele aanwezige netwerkkaart past.

Bijzonder belangrijk is de prefixlengte. Veel aanbieders routeren één enkel IPv4-adres met /32 naar de server, waardoor de gateway buiten het eigen subnet ligt. Anderen geven klassieke /24-netwerken uit. Welk geval bij u van toepassing is, verraadt het pad dat werkelijk gebruikt wordt:

ip route get 1.1.1.1

Maak daarna een back-up. Dat kost tien seconden en is het verschil tussen een rollback en een ticket.

cp -a /etc/netplan /root/netplan.bak
cp -a /etc/network/interfaces /root/interfaces.bak

Welk systeem stuurt uw netwerk op dit moment aan?

Debian en Ubuntu gebruiken verschillende tools, en de meest voorkomende totale uitval ontstaat wanneer er twee tegelijk dezelfde netwerkkaart configureren. Verschaf uzelf eerst duidelijkheid:

ls -l /etc/netplan/
ls -l /etc/network/interfaces /etc/network/interfaces.d/
ls -l /etc/systemd/network/

De vuistregel voor de vier actuele versies: Ubuntu 24.04 en Ubuntu 22.04 worden via netplan geconfigureerd, dat op de achtergrond systemd-networkd aanstuurt. Debian 13 en Debian 12 komen na een standaardinstallatie met ifupdown en het bestand /etc/network/interfaces. systemd-networkd is op Debian wel aanwezig, maar niet actief, en netplan valt daar bij te installeren, alleen is dat niet de bedoelde weg.

Bij cloud-images komt er nog een laag bij: cloud-init schrijft bij de eerste start een eigen bestand, meestal /etc/netplan/50-cloud-init.yaml of onder Debian een blok in /etc/network/interfaces.d/. Wie dat bestand bewerkt zonder cloud-init af te remmen, treft na de volgende herstart gewoon weer de oude configuratie aan.

Ubuntu 24.04 en 22.04: een statisch adres met netplan

netplan leest alle bestanden in /etc/netplan/ in alfabetische volgorde en vertaalt ze naar configuratie voor systemd-networkd. Maak geen tweede bestand aan voor dezelfde interface, maar bewerk het bestaande of schakel het oude netjes uit. Een volledige configuratie met IPv4 en IPv6 ziet er zo uit:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      addresses:
        - 203.0.113.10/24
        - "2001:db8:1234::2/64"
      routes:
        - to: default
          via: 203.0.113.1
        - to: default
          via: "2001:db8:1234::1"
      nameservers:
        addresses: [9.9.9.9, 149.112.112.112, 2620:fe::fe]

Drie punten daarin verdienen een aparte toelichting.

Ten eerste staan de standaardroutes onder routes en niet meer onder gateway4 of gateway6. Die twee sleutels zijn sinds netplan 0.103 afgeschaft. Ze werken op Ubuntu 22.04 en 24.04 nog wel, maar beantwoorden elke aanroep met `gateway4` has been deprecated, use default routes instead. Wie een configuratie opnieuw opschrijft, schrijft routes.

Ten tweede schakelt accept-ra: false de automatische IPv6-configuratie uit. Laat u die aan staan terwijl u tegelijk een vast adres toekent, dan krijgt de netwerkkaart twee adressen en twee standaardroutes. Welke daarvan wint, bepaalt de metric en niet uw bedoeling.

Ten derde de bestandsrechten. Sinds netplan 0.106 waarschuwt elke aanroep wanneer het YAML-bestand voor andere gebruikers leesbaar is: Permissions for /etc/netplan/01-static.yaml are too open. Netplan configuration should NOT be accessible by others. Dat is geen cosmetica, want in zulke bestanden staan ook wifisleutels en tunnelgegevens.

chmod 600 /etc/netplan/*.yaml

Als de gateway buiten het eigen subnet ligt

Bij een afzonderlijk gerouteerd adres met /32 kent de kernel geen directe weg naar de gateway en wijst hij de route af. In het journal staat dan Could not set route: Network is unreachable, en bij een handmatige poging met ip route add luidt het antwoord RTNETLINK answers: Network is unreachable. De oplossing heet on-link:

      addresses:
        - 203.0.113.10/32
      routes:
        - to: default
          via: 192.0.2.1
          on-link: true

Bij IPv6 is de uitzondering juist de regel: veel netwerken geven als gateway het link-local-adres fe80::1 op. Omdat netplan routes altijd aan een interface koppelt, volstaat via: "fe80::1" in het blok van de betreffende netwerkkaart.

cloud-init stilleggen

Ligt er in de map een 50-cloud-init.yaml, leg dan bovendien een blokkade vast, anders wordt uw werk bij de volgende start overschreven:

echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

netplan try: het commando dat u niet buitensluit

De volgorde luidt: controleren, testen, vastleggen. netplan generate vertaalt de YAML-bestanden zonder iets te activeren en meldt syntaxfouten meteen. Pas daarna volgt de eigenlijke test.

netplan generate
netplan try --timeout 120
netplan apply

netplan try past de nieuwe configuratie toe en zet de oude automatisch terug wanneer u niet binnen de gestelde tijd op de entertoets drukt. De standaardwaarde ligt op 120 seconden. Precies daarom begint u op een server op afstand nooit met netplan apply: een typefout in het gatewayadres beëindigt de SSH-sessie, en zonder terugvaloptie eindigt de zaak in de console of in een herinstallatie.

Vertrouw niet blind op het automatisch terugdraaien. Er zijn gevallen gedocumenteerd waarin netplan try na het verstrijken van de tijd de verbinding niet heeft hersteld, vooral bij het bewerken van het door cloud-init aangemaakte bestand. Controleer na elke terugdraaiactie of het bestand op de schijf werkelijk weer in de oude toestand is.

Voor alles wat netplan try niet afdekt (en voor Debian met ifupdown, waar dit commando helemaal niet bestaat) heeft een tweede veiligheidsgordel zich bewezen: een opruimtaak die de back-up terugzet als u zich niet op tijd meldt.

nohup sh -c 'sleep 300; cp -a /root/netplan.bak/. /etc/netplan/; netplan apply' >/dev/null 2>&1 &

Onthoud het procesnummer uit de uitvoer. Werkt alles, dan beëindigt u de taak met kill. Komt u er niet meer in, dan herstelt de server zichzelf binnen vijf minuten. Werk daarnaast in tmux of screen, zodat een wegvallende SSH-sessie uw editor niet midden in de omzetting meesleurt.

Bij KVM-rootservers blijft als laatste redmiddel de console in het klantenpaneel over, waarmee u ook zonder werkend netwerk bij het systeem komt. Bij dedicated servers is de weg terug een stuk bewerkelijker, daar telt de voorzorgsroutine dubbel.

Debian 13 en 12 met /etc/network/interfaces

Na een standaardinstallatie stuurt ifupdown het netwerk aan. De configuratie is regelgeoriënteerd en kent gescheiden blokken per adresfamilie:

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1

iface ens3 inet6 static
    address 2001:db8:1234::2/64
    gateway 2001:db8:1234::1
    accept_ra 0

De regel auto ens3 geldt voor beide blokken, een tweede auto-regel hebt u niet nodig. Ligt de gateway buiten het subnet, dan helpt hetzelfde idee als bij netplan, alleen met de hand geformuleerd:

iface ens3 inet static
    address 203.0.113.10/32
    post-up ip route add 192.0.2.1 dev ens3
    post-up ip route add default via 192.0.2.1
    pre-down ip route del default via 192.0.2.1

Het grootste struikelblok onder Debian is niet de syntaxis, maar het activeren. systemctl restart networking haalt de netwerkkaart even omlaag, en houdt de nieuwe configuratie geen stand, dan is de sessie weg. ifdown ens3 && ifup ens3 is nog riskanter, omdat het ifup nooit wordt uitgevoerd zodra de verbinding al bij het ifdown wegvalt. Maak dus van tevoren de hierboven beschreven opruimtaak aan en roep daarna aan:

systemctl restart networking
systemctl status networking

Twee meldingen komt u hier regelmatig tegen. ifup: interface ens3 already configured betekent dat ifupdown de netwerkkaart nog als actief boekt, terwijl dat misschien niet meer klopt; de toestand staat in /run/network/ifstate. En Job for networking.service failed because the control process exited with error code is slechts de buitenkant, de eigenlijke reden staat in journalctl -xeu networking, meestal een dubbel toegekende standaardroute met RTNETLINK answers: File exists.

DNS onder ifupdown

De voor de hand liggende regel dns-nameservers 9.9.9.9 in het bestand werkt alleen wanneer er een tussenschakel is geïnstalleerd die haar naar /etc/resolv.conf overbrengt, klassiek het pakket resolvconf. Zonder die tussenschakel blijft de regel zonder gevolg, en dat valt pas op wanneer namen niet meer worden omgezet: Temporary failure in name resolution. Wie niets wil bijinstalleren, onderhoudt /etc/resolv.conf rechtstreeks en controleert met ls -l /etc/resolv.conf of het bestand een symlink is en dus door een andere dienst wordt beheerd.

Debian met systemd-networkd draaien

Wie op een Debian-server toch al systemd-gereedschap gebruikt of veel interfaces en tunnels beheert, werkt met systemd-networkd consistenter. De overstap bestaat uit drie stappen: de configuratie aanmaken, de nieuwe dienst activeren, de oude stilleggen.

[Match]
Name=ens3

[Network]
Address=203.0.113.10/24
Address=2001:db8:1234::2/64
Gateway=203.0.113.1
Gateway=2001:db8:1234::1
DNS=9.9.9.9
DNS=2620:fe::fe
IPv6AcceptRA=no

Dit bestand hoort in /etc/systemd/network/10-ens3.network. Voor een gateway buiten het subnet hangt u er een eigen routeblok achter:

[Route]
Gateway=192.0.2.1
GatewayOnLink=yes

Daarna volgt de omschakeling, bij voorkeur weer met een opruimtaak achter de hand:

systemctl enable --now systemd-networkd
systemctl disable networking
networkctl status ens3

De uitvoer van networkctl status is de eerlijkste terugkoppeling die dit onderwerp te bieden heeft. Staat daar State: routable (configured), dan heeft de dienst het bestand geaccepteerd en doorgevoerd. Staat daar configuring of degraded, dan heeft hij het geprobeerd en is het mislukt, ook al kwam het startcommando zonder fout terug.

Het DNS-gedeelte staat onder Debian op zichzelf: systemd-networkd zet nameservers alleen in de naamsomzetting wanneer systemd-resolved draait en /etc/resolv.conf naar het bestand daarvan wijst.

apt-cache policy systemd-resolved

Deze controle is versieafhankelijk en misleidt op een onopvallende manier. Een zelfstandig pakket systemd-resolved bestaat pas vanaf Debian 12 en Ubuntu 24.04, daar noemt het commando een versie. Op Ubuntu 22.04 zit de dienst daarentegen nog in het pakket systemd zelf, en daar loopt het commando wel zonder fout door, maar geeft het helemaal niets terug. Een installatie mislukt dan ook met Unable to locate package systemd-resolved. De lege uitvoer betekent dus niet dat de resolver ontbreekt, maar dat het pakket op deze versie niet bestaat. Op oudere systemen zoals Debian 11 gaat het net zo. Controleer op die versies in plaats daarvan:

apt-cache policy systemd
systemctl status systemd-resolved

De dienst activeert u met systemctl enable --now systemd-resolved, daarna wijst de gebruikelijke symlink naar /run/systemd/resolve/stub-resolv.conf. Wie dat niet wil, laat systemd-resolved weg en schrijft de nameservers statisch in /etc/resolv.conf. Wat u niet moet doen: allebei half.

Extra IP-adressen toevoegen

Extra adressen zijn geen bijzonder geval, maar simpelweg nog een regel erbij. Onder netplan groeit de lijst:

      addresses:
        - 203.0.113.10/24
        - 203.0.113.11/24
        - 203.0.113.12/24
        - "2001:db8:1234::2/64"
        - "2001:db8:1234::3/64"

Onder systemd-networkd schrijft u meerdere Address=-regels onder elkaar. Onder ifupdown vult u de bestaande definitie aan in plaats van een tweede aan te maken:

iface ens3 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    post-up ip addr add 203.0.113.11/24 dev ens3
    post-up ip addr add 203.0.113.12/24 dev ens3
    pre-down ip addr del 203.0.113.11/24 dev ens3
    pre-down ip addr del 203.0.113.12/24 dev ens3

De oude schrijfwijze met ens3:0 werkt nog steeds, maar is een overblijfsel uit de tijd vóór het gereedschap ip. Ze maakt geen echte extra apparaten aan, alleen benamingen, en zorgt in firewallregels voor meer verwarring dan nut.

Drie dingen gaan bij extra adressen doorgaans mis. Ten eerste is het adres aan de serverkant niet toegekend; geen enkele configuratie van het besturingssysteem krijgt een IP aan de praat die niet naar uw server is gerouteerd, daarom is een blik in het klantenpaneel de eerste stap en niet de laatste. Ten tweede hoort bij een tweede adres uit hetzelfde netwerk geen tweede standaardroute; een tweede standaardgateway levert u RTNETLINK answers: File exists op of, erger nog, wisselende antwoordpaden. Ten derde geldt bij IPv6 bijna altijd dat het volledige /64 naar de server is gerouteerd. U kunt dus vrij uit dat bereik kiezen, terwijl alleen het door de aanbieder genoemde adres werkelijk als geconfigureerd interface-adres nodig is.

Of een extra adres werkelijk naar buiten draagt, controleert u gericht via het bronadres:

ping -c 3 -I 203.0.113.11 1.1.1.1

Waaraan u ziet dat het echt goed zit

Dat een commando zonder foutmelding is doorgelopen, zegt weinig over de toestand van het netwerk. Deze vijf controles zeggen wel iets:

1. Het adres zit op de juiste netwerkkaart: ip -brief address show toont precies de gewenste adressen en geen resten van de oude configuratie.
2. De weg naar buiten klopt inclusief bronadres: ip route get 1.1.1.1 noemt de verwachte gateway en de verwachte src.
3. IPv6 heeft een eigen standaardroute: ip -6 route show default mag niet leeg zijn, anders loopt alles stilzwijgend over IPv4.
4. De naamsomzetting werkt los van de bereikbaarheid: getent hosts deb.debian.org levert een adres op en niet alleen stilte.
5. De enige echte test is een herstart. Pas daarna weet u of de configuratie uit het bestand komt of nog uit het werkgeheugen.

Onder Ubuntu geeft netplan status --all daarnaast een compacte samenvatting, onder systemd-networkd doet networkctl status hetzelfde. Beide laten bij twijfel zien dat een adres wel in het bestand staat, maar nooit is overgenomen.

Foutmeldingen letterlijk

De vier distributies rechtstreeks vergeleken

Neemt u direct na de netwerkconfiguratie de firewall in gebruik, let er dan op dat regels voor het nieuwe adres en voor IPv6 apart gelden. Hoe u dat netjes opzet, leest u in onze handleiding over UFW onder Debian en Ubuntu, en hoe u de toegang daarna beveiligt in SSH-server beveiligen.

Korte versie voor de volgende server

Waarden aflezen in plaats van raden, een back-up maken, de configuratie schrijven, testen met netplan try of met een eigen opruimtaak, vastleggen, herstarten en pas daarna afvinken. Wie deze volgorde aanhoudt, verliest in het ergste geval vijf minuten. Wie de volgorde inkort, verliest in het ergste geval de server, totdat iemand aan de console zit.