Hvorfor en DHCP-reservation ikke er en statisk IP til din VPN-server

Jeg flyttede en hjemme-VPN-boks fra Wi-Fi til Ethernet, og dens “permanente” adresse ændrede sig samme aften. Intet på routeren var i stykker. Reservationen havde matchet den trådløse adapter, og den adapter var ikke længere i vejen.

Der er en anden halvdel af den samme misforståelse. At rette LAN-adressen gør intet for den adresse, dine venner forbinder til, og den har intet at gøre med den private pulje, VPN'en udleverer til klienter. Tre adresser, tre adskilte fejlmåder, og kun én af dem er en reservations arbejde.

En reservation matcher en klient, ikke en enhed

I DHCPv4 er reservationen bundet til klientens hardwareadresse; i DHCPv6 til en DUID, som klienten forventes at beholde. Feltet hostname er en etiket for mennesker. Det, routeren faktisk sammenligner, er den identifikator, der ankommer i anmodningen.

Læs posten som en betingelse: når denne identifikator spørger, giv den denne adresse. Fornyelser beholder samme lease, så længe matchningen holder, og en genstart spørger bare igen. Når identifikatoren ændrer sig, rammer anmodningen ved siden af reservationen, og klienten tager, hvad den dynamiske pulje tilbyder. Ingen fejl, ingen advarsel, bare en anden adresse.

OpenWrt viser formen tydeligt. Én config host-blok i /etc/config/dhcp binder et navn, en MAC og en adresse sammen, og dokumentationen om statiske leases forklarer, hvordan den post spiller sammen med puljen. Andre routere skjuler de samme tre felter bag forskellige etiketter.

Hvor matchningen stille falder igennem

At skifte hardware er det almindelige tilfælde. Skift netværkskortet, eller flyt maskinen mellem Ethernet og Wi-Fi, og adressen, routeren ser, ændrer sig med. Den gamle reservation bliver i listen og ser stadig rigtig ud.

En geninstallation er det andet tilfælde, og den bider hårdest på IPv6. En frisk installation kan generere en ny DUID, mens den gamle IPv4-lease stadig er gyldig, så v4-adressen overlever et stykke tid, og v6-posten holder op med at gælde uden nogen synlig redigering.

Det tredje er en fastlåst klientidentifikator. Flere DHCP-klienter lader dig sætte en identifikatorstreng i stedet for at bruge MAC'en. Hvis en opgradering eller en omskrivning af konfigurationen dropper den indstilling, forsvinder matchningen, selv om maskinen ikke har flyttet sig.

Det fjerde er duplikering: en forældet blok og en ny blok til samme host. Serveren svarer med den regel, der matcher, ofte puljeadressen, du ville undgå. Slet den forældede post i stedet for at tilføje en anden.

Konfiguration på hosten og hvad den koster

At sætte adressen på hosten fjerner spørgsmålet om matchning helt. Interfacet kommer op med den adresse, uanset om DHCP svarer, og det er, hvad du vil have fra en maskine, der skal kunne nås efter en genstart af routeren.

Prisen er ejerskab. Du leverer nu præfiks, gateway og resolvere, og du skal selv holde adressen uden for den dynamiske pulje. På Ubuntu med netplan bærer /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-brugere når samme tilstand med nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, derefter nmcli con up "Wired connection 1". Anvend netplan med netplan try ved første forsøg i stedet for netplan apply; en fejlskrevet gateway tager boksen af netværket og lader dig lede efter en konsol.

Behold alligevel en matchende reservation. Den er ikke overflødig. Posten registrerer adressen på routersiden og forhindrer DHCP-serveren i at give den adresse til en gæsteenhed, hvis nogen senere udvider puljen.

En stabil LAN-adresse er ikke et offentligt endepunkt

Ret port forwarding mod 192.168.50.10, og reglen overlever hver ændring på LAN-siden. Den giver dig ikke en stabil internetadresse. Din offentlige IP tilhører udbyderen og kan flytte sig ved en genopkobling eller et modemskift, hvilket er hvad dynamisk DNS er til.

Bag carrier-grade NAT er der slet ingen offentlig IPv4 at videresende, og ingen reservation skaber en. Tjek routerens WAN-side først: hvis adressen ligger i et delt interval, kan indgående videresendelse ikke fungere, uanset hvor ren reservationen er.

Den tredje adresse er tunnelpuljen, ofte noget i retning af 10.8.0.0/24. De adresser findes kun inde i tunnelen og optræder aldrig på LAN'et. At forveksle dem med serverens LAN-adresse er måden, hvorpå en port ender med at blive videresendt til en klient, der kun er online, mens den er forbundet.

Tjek vejen i den rækkefølge, den bryder

Start på routeren. Sammenlign lease-tabellens post med reservationens mål; har serveren taget en puljeadresse, er identifikatoren forkert, og ip link show på hosten giver dig værdien at sammenligne med.

Så hosten. ip -4 addr show eth0 bør vise den forventede adresse og præfiks. En anden adresse på samme interface betyder som regel, at DHCP stadig kører ved siden af din statiske konfiguration.

Så videresendelsen. Bekræft, at destinationen stadig svarer til den adresse, du netop har verificeret, og bekræft, at noget lytter med ss -lntp. En videresendelse mod en lukket port ser udefra præcis ud som en brudt videresendelse.

Afslut udefra, på en telefon med Wi-Fi slået fra. Den ene test skiller “den lokale adresse er forkert” fra “den offentlige tilgængelighed er brudt”, de to problemer, dette setup bliver ved med at blande sammen.

Skriv de tre adresser ned, LAN, offentlig og tunnelpulje, og noter, hvilket system der ejer hver. Når en forbindelse fejler næste måned, ved du, hvilken du skal undersøge i stedet for at ændre alle tre på én gang.