Hvorfor en DHCP-reservasjon ikke er en statisk IP for VPN-serveren din
En reservasjon matcher en klientidentifikator, ikke en maskin, og den gjør aldri den offentlige IP-en din statisk. Hva som faktisk flytter adressen til en hjemme-VPN-server.
Jeg flyttet en hjemme-VPN-boks fra Wi-Fi til Ethernet, og den «permanente» adressen endret seg samme kveld. Ingenting på ruteren var ødelagt. Reservasjonen hadde matchet den trådløse adapteren, og den adapteren var ikke lenger i veien.
Den samme misforståelsen har en andre halvdel. Å fikse LAN-adressen gjør ingenting for adressen vennene dine kobler til, og den har ingenting med den private poolen VPN-en gir klientene. Tre adresser, tre atskilte feilmoduser, og bare én av dem er en reservasjons jobb.
En reservasjon matcher en klient, ikke en enhet
I DHCPv4 er reservasjonen knyttet til klientens maskinvareadresse; i DHCPv6 er den knyttet til en DUID klienten forventes å beholde. Feltet hostname er en etikett for mennesker. Det ruteren faktisk sammenligner, er identifikatoren som kommer i forespørselen.
Les oppføringen som en betingelse: når denne identifikatoren spør, gi den denne adressen. Fornyelser beholder samme lease så lenge matchingen holder, og en omstart spør bare igjen. Når identifikatoren endres, bommer forespørselen på reservasjonen og klienten tar det den dynamiske poolen tilbyr. Ingen feil, ingen advarsel, bare en annen adresse.
OpenWrt viser formen tydelig. Én config host-blokk i /etc/config/dhcp binder et navn, en MAC og en adresse sammen, og dokumentasjonen om statiske leases forklarer hvordan oppføringen samspiller med poolen. Andre rutere skjuler de samme tre feltene bak andre etiketter.
Der matchingen stille faller gjennom
Å bytte maskinvare er det vanlige tilfellet. Bytt nettverkskortet, eller flytt maskinen mellom Ethernet og Wi-Fi, og adressen ruteren ser endres med den. Den gamle reservasjonen blir i listen og ser fortsatt riktig ut.
En reinstallasjon er det andre tilfellet, og den biter hardest på IPv6. En fersk installasjon kan generere en ny DUID mens den gamle IPv4-leasen fortsatt er gyldig, så v4-adressen overlever en stund og v6-oppføringen slutter å gjelde uten noen synlig redigering.
Det tredje er en fastlåst klientidentifikator. Flere DHCP-klienter lar deg sette en identifikatorstreng i stedet for å bruke MAC-en. Hvis en oppgradering eller en omskriving av konfigurasjonen dropper den innstillingen, forsvinner matchingen selv om maskinen ikke har flyttet seg.
Det fjerde er duplisering: en utdatert blokk og en ny blokk for samme vert. Serveren svarer med regelen som matcher, ofte pooladressen du ville unngå. Slett den utdaterte oppføringen i stedet for å legge til en ny.
Konfigurasjon på verten og hva den koster
Å sette adressen på verten fjerner spørsmålet om matching helt. Grensesnittet kommer opp med den adressen enten DHCP svarer eller ikke, og det er det du vil ha fra en maskin som må være tilgjengelig etter en omstart av ruteren.
Prisen er eierskap. Du leverer nå prefikset, gatewayen og resolverne, og du må holde adressen utenfor den dynamiske poolen selv. 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-brukere 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, deretter nmcli con up "Wired connection 1". Bruk netplan med netplan try ved første forsøk i stedet for netplan apply; en feilskrevet gateway tar boksen av nettverket og lar deg lete etter en konsoll.
Behold likevel en matchende reservasjon. Den er ikke overflødig. Oppføringen registrerer adressen på ruteren sin side og hindrer DHCP-serveren i å gi den adressen til en gjesteenhet hvis noen senere utvider poolen.
En stabil LAN-adresse er ikke et offentlig endepunkt
Rett port forwarding mot 192.168.50.10, og regelen overlever hver endring på LAN-siden. Den gir deg ikke en stabil internettadresse. Din offentlige IP tilhører internettleverandøren og kan flytte seg ved en gjentilkobling eller et modembytte, som er det dynamisk DNS er til for.
Bak carrier-grade NAT finnes det ingen offentlig IPv4 å videresende i det hele tatt, og ingen reservasjon lager en. Sjekk WAN-siden på ruteren før noe annet: ligger adressen i et delt område, kan innkommende videresending ikke fungere, uansett hvor ren reservasjonen er.
Den tredje adressen er tunnelpoolen, ofte noe som 10.8.0.0/24. Disse adressene finnes bare inne i tunnelen og dukker aldri opp på LAN-et. Å forveksle dem med serverens LAN-adresse er måten en port til slutt blir videresendt til en klient som bare er på nett mens den er tilkoblet.
Sjekk veien i den rekkefølgen den bryter
Start på ruteren. Sammenlign oppføringen i lease-tabellen med målet for reservasjonen; har serveren tatt en pooladresse, er identifikatoren feil, og ip link show på verten gir deg verdien å sammenligne med.
Så verten. ip -4 addr show eth0 bør rapportere den forventede adressen og prefikset. En andre adresse på samme grensesnitt betyr vanligvis at DHCP fortsatt kjører ved siden av den statiske konfigurasjonen din.
Så videresendingen. Bekreft at målet fortsatt er lik adressen du nettopp verifiserte, og bekreft at noe lytter med ss -lntp. En videresending mot en lukket port ser utenfra nøyaktig ut som en ødelagt videresending.
Avslutt utenfra, på en telefon med Wi-Fi slått av. Den ene testen skiller «den lokale adressen er feil» fra «den offentlige tilgjengeligheten er ødelagt», de to problemene dette oppsettet stadig blander sammen.
Skriv ned de tre adressene, LAN, offentlig og tunnelpool, og noter hvilket system som eier hver. Når en tilkobling feiler neste måned, vet du hvilken du skal undersøke i stedet for å endre alle tre samtidig.