Varför en DHCP-reservation inte är en statisk IP för din VPN-server

Jag flyttade en hemma-VPN-box från wifi till Ethernet och dess ”permanenta” adress ändrades samma kväll. Inget på routern var trasigt. Reservationen hade matchat den trådlösa adaptern, och den adaptern var inte längre i vägen.

Samma missförstånd har en andra halva. Att fixa LAN-adressen gör ingenting för adressen som dina vänner ansluter till, och den har inget med den privata poolen som VPN:en ger klienterna att göra. Tre adresser, tre separata felmoder, och bara en av dem är en reservations jobb.

En reservation matchar en klient, inte en enhet

I DHCPv4 är reservationen knuten till klientens maskinvaruadress; i DHCPv6 till en DUID som klienten förväntas behålla. Fältet hostname är en etikett för människor. Det routern faktiskt jämför är identifieraren som kommer i förfrågan.

Läs posten som ett villkor: när den här identifieraren frågar, ge den den här adressen. Förnyelser behåller samma lease så länge matchningen håller, och en omstart frågar bara igen. När identifieraren ändras missar förfrågan reservationen och klienten tar det den dynamiska poolen erbjuder. Inget fel, ingen varning, bara en annan adress.

OpenWrt visar formen tydligt. Ett config host-block i /etc/config/dhcp binder ihop ett namn, en MAC och en adress, och dokumentationen om statiska leases förklarar hur posten samspelar med poolen. Andra routrar gömmer samma tre fält bakom andra etiketter.

Där matchningen tyst faller igenom

Att byta hårdvara är det vanliga fallet. Byt nätverkskort, eller flytta maskinen mellan Ethernet och wifi, och adressen routern ser ändras med den. Den gamla reservationen ligger kvar i listan och ser fortfarande korrekt ut.

En ominstallation är det andra fallet, och den biter hårdast på IPv6. En ny installation kan generera en ny DUID medan den gamla IPv4-leasen fortfarande gäller, så v4-adressen överlever ett tag och v6-posten slutar gälla utan någon synlig redigering.

Det tredje är en fastnålad klientidentifierare. Flera DHCP-klienter låter dig sätta en identifierarsträng i stället för att använda MAC-adressen. Om en uppgradering eller en omskrivning av konfigurationen tappar den inställningen försvinner matchningen även om maskinen inte har flyttats.

Det fjärde är duplicering: ett gammalt block och ett nytt block för samma värd. Servern svarar med regeln som matchar, ofta pooladressen du ville undvika. Ta bort den gamla posten i stället för att lägga till en andra.

Konfiguration på värdsidan och vad den kostar

Att sätta adressen på värden tar bort matchningsfrågan helt. Gränssnittet kommer upp med den adressen oavsett om DHCP svarar eller inte, och det är vad du vill ha från en maskin som måste nås efter en omstart av routern.

Priset är ägandet. Du levererar nu prefixet, gatewayen och resolvrarna, och du måste själv hålla adressen utanför den dynamiska poolen. På Ubuntu med netplan bär /etc/netplan/01-vpn.yaml den:

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-användare når samma tillstånd med nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, sedan nmcli con up "Wired connection 1". Använd netplan med netplan try vid första försöket i stället för netplan apply; en felstavad gateway tar boxen av nätet och lämnar dig letande efter en konsol.

Behåll ändå en matchande reservation. Den är inte överflödig. Posten registrerar adressen på routersidan och hindrar DHCP-servern från att ge den adressen till en gästenhet om någon senare utökar poolen.

En stabil LAN-adress är inte en publik ändpunkt

Rikta port forwarding mot 192.168.50.10 och regeln överlever varje ändring på LAN-sidan. Den ger dig ingen stabil internetadress. Din publika IP tillhör internetleverantören och kan flytta sig vid en återanslutning eller ett modembyte, vilket är vad dynamisk DNS är till för.

Bakom carrier-grade NAT finns ingen publik IPv4 att vidarebefordra alls, och ingen reservation skapar en. Kontrollera routerns WAN-sida först: ligger adressen i ett delat intervall kan inkommande vidarebefordran inte fungera, hur ren reservationen än är.

Den tredje adressen är tunnelpoolen, ofta något som 10.8.0.0/24. De adresserna finns bara inne i tunneln och dyker aldrig upp på LAN:et. Att blanda ihop dem med serverns LAN-adress är sättet en port till slut vidarebefordras till en klient som bara är online medan den är ansluten.

Kontrollera vägen i den ordning den brister

Börja på routern. Jämför posten i lease-tabellen med reservationens mål; har servern tagit en pooladress är identifieraren fel, och ip link show på värden ger dig värdet att jämföra med.

Sedan värden. ip -4 addr show eth0 bör rapportera den förväntade adressen och prefixet. En andra adress på samma gränssnitt betyder oftast att DHCP fortfarande körs bredvid din statiska konfiguration.

Sedan vidarebefordran. Bekräfta att målet fortfarande är lika med adressen du just verifierade, och att något lyssnar med ss -lntp. En vidarebefordran mot en stängd port ser utifrån exakt ut som en trasig vidarebefordran.

Avsluta utifrån, på en telefon med wifi avstängt. Det enda testet skiljer ”den lokala adressen är fel” från ”den publika nåbarheten är trasig”, de två problem som den här uppsättningen ständigt blandar ihop.

Skriv ner de tre adresserna, LAN, publik och tunnelpool, och notera vilket system som äger varje. När en anslutning misslyckas nästa månad vet du vilken du ska undersöka i stället för att ändra alla tre samtidigt.