Waarom een DHCP-reservering geen statisch IP voor je VPN-server is

Ik verhuisde een thuis-VPN-box van wifi naar ethernet en zijn „permanente“ adres veranderde diezelfde avond. Op de router was niets stuk. De reservering had bij de draadloze adapter gehoord, en die adapter zat niet meer in het pad.

Dezelfde misvatting heeft een tweede helft. Het LAN-adres repareren doet niets voor het adres waar je vrienden mee verbinden, en het heeft niets te maken met de privépool die de VPN aan clients geeft. Drie adressen, drie losse faalwijzen, en slechts één daarvan is het werk van een reservering.

Een reservering hoort bij een client, niet bij een apparaat

In DHCPv4 hangt de reservering aan het hardwareadres van de client; in DHCPv6 aan een DUID die de client hoort te bewaren. Het veld hostname is een label voor mensen. Wat de router echt vergelijkt, is de identificatie die in het verzoek binnenkomt.

Lees de regel als een voorwaarde: als deze identificatie vraagt, geef hem dit adres. Verlengingen houden dezelfde lease zolang de match standhoudt, en een herstart vraagt gewoon opnieuw. Verandert de identificatie, dan mist het verzoek de reservering en neemt de client wat de dynamische pool biedt. Geen fout, geen waarschuwing, alleen een ander adres.

OpenWrt laat de vorm duidelijk zien. Eén config host-blok in /etc/config/dhcp verbindt een naam, een MAC en een adres, en de documentatie over statische leases legt uit hoe die regel met de pool omgaat. Andere routers verstoppen dezelfde drie velden achter andere labels.

Waar de match stilletjes wegvalt

Hardware wisselen is het gewone geval. Verwissel de NIC, of verplaats de machine tussen ethernet en wifi, en het adres dat de router ziet verandert mee. De oude reservering blijft in de lijst staan en ziet er nog steeds goed uit.

Een herinstallatie is het tweede geval, en die bijt het hardst op IPv6. Een verse installatie kan een nieuwe DUID maken terwijl de oude IPv4-lease nog geldig is, dus het v4-adres overleeft een tijdje en de v6-regel geldt niet meer zonder zichtbare aanpassing.

Het derde is een vastgezette client-identificatie. Meerdere DHCP-clients laten je een identificatietekenreeks instellen in plaats van de MAC te gebruiken. Als een upgrade of een herschreven configuratie die instelling laat vallen, verdwijnt de match ook al is de machine niet verhuisd.

Het vierde is duplicatie: een oud blok en een nieuw blok voor dezelfde host. De server antwoordt met de regel die past, vaak het pooladres dat je wilde vermijden. Verwijder de oude regel in plaats van een tweede toe te voegen.

Configuratie aan de hostkant en wat die kost

Het adres op de host zetten haalt de matchvraag helemaal weg. De interface komt met dat adres omhoog of DHCP nu antwoordt of niet, en dat is wat je wilt van een machine die na een herstart van de router bereikbaar moet zijn.

De prijs is eigendom. Je levert nu het prefix, de gateway en de resolvers, en je moet het adres zelf buiten de dynamische pool houden. Op Ubuntu met netplan draagt /etc/netplan/01-vpn.yaml het:

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: false
      addresses: [192.168.50.10/24]
      routes:
        - to: default
          via: 192.168.50.1
      nameservers:
        addresses: [192.168.50.1]

NetworkManager-gebruikers komen met nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, en daarna nmcli con up "Wired connection 1", in dezelfde toestand. Pas netplan bij de eerste poging toe met netplan try in plaats van netplan apply; een verkeerd getypte gateway haalt de box van het netwerk en laat je naar een console zoeken.

Houd toch een passende reservering. Die is niet overbodig. De regel legt het adres aan de routerkant vast en houdt de DHCP-server ervan af dat adres aan een gastapparaat te geven als iemand de pool later vergroot.

Een stabiel LAN-adres is geen publiek eindpunt

Richt de port forward op 192.168.50.10 en de regel overleeft elke wijziging aan de LAN-kant. Een stabiel internetadres geeft het je niet. Je publieke IP is van de provider en kan verschuiven bij een herverbinding of een modemwissel, daar is dynamische DNS voor.

Achter carrier-grade NAT is er helemaal geen publiek IPv4 om door te sturen, en geen enkele reservering maakt er een. Controleer eerst de WAN-pagina van de router: staat het adres in een gedeeld bereik, dan kan inkomende forwarding niet werken, hoe schoon de reservering ook is.

Het derde adres is de tunnelpool, vaak iets als 10.8.0.0/24. Die adressen bestaan alleen binnen de tunnel en verschijnen nooit op de LAN. Ze verwarren met het LAN-adres van de server is de manier waarop een poort uiteindelijk wordt doorgestuurd naar een client die alleen online is zolang hij verbonden is.

Controleer het pad in de volgorde waarin het breekt

Begin op de router. Vergelijk de regel in de leasetabel met het doel van de reservering; heeft de server een pooladres genomen, dan is de identificatie fout, en ip link show op de host geeft je de waarde om te vergelijken.

Dan de host. ip -4 addr show eth0 hoort het verwachte adres en prefix te melden. Een tweede adres op dezelfde interface betekent meestal dat DHCP nog naast je statische configuratie draait.

Dan de forwarding. Bevestig dat de bestemming nog gelijk is aan het adres dat je net hebt gecontroleerd, en bevestig dat er iets luistert met ss -lntp. Een forwarding naar een gesloten poort ziet er van buiten precies zo uit als een kapotte forwarding.

Sluit af van buiten, op een telefoon met wifi uit. Die ene test scheidt „het lokale adres is fout“ van „de publieke bereikbaarheid is stuk“, de twee problemen die deze opzet steeds door elkaar haalt.

Schrijf de drie adressen op, LAN, publiek en tunnelpool, en noteer welk systeem welke bezit. Als volgende maand een verbinding faalt, weet je welke je moet bekijken in plaats van alle drie tegelijk te veranderen.