Kvifor ein DHCP-reservasjon ikkje er ein statisk IP for VPN-tenaren din

Eg flytta ein heime-VPN-boks frå Wi-Fi til Ethernet, og den «permanente» adressa hans endra seg same kvelden. Ingenting på rutaren var øydelagt. Reservasjonen hadde passa til den trådlause adapteren, og den adapteren var ikkje lenger i vegen.

Den same mistydinga har ei andre halvdel. Å rette LAN-adressa gjer ingenting for adressa venene dine koplar til, og ho har ingenting med den private poolen VPN-en gir klientane. Tre adresser, tre atskilde feilmodus, og berre éin av dei er jobben til ein reservasjon.

Ein reservasjon passar til ein klient, ikkje til eit apparat

I DHCPv4 er reservasjonen knytt til maskinvareadressa til klienten; i DHCPv6 er han knytt til ein DUID klienten blir venta å halde på. Feltet hostname er ei etikett for menneske. Det rutaren faktisk samanliknar, er identifikatoren som kjem i førespurnaden.

Les oppføringa som eit vilkår: når denne identifikatoren spør, gje han denne adressa. Fornyingar held same leige så lenge matchinga held, og ein omstart spør berre igjen. Når identifikatoren endrar seg, bommar førespurnaden på reservasjonen og klienten tek det den dynamiske poolen tilbyr. Inga feil, inga åtvaring, berre ei anna adresse.

OpenWrt viser forma tydeleg. Éin config host-blokk i /etc/config/dhcp bind eit namn, ein MAC og ei adresse saman, og dokumentasjonen om statiske leiger forklarer korleis oppføringa samspelar med poolen. Andre rutarar gøymer dei same tre felta bak andre etikettar.

Der matchinga stille fell gjennom

Å byte maskinvare er det vanlege tilfellet. Byte nettverkskortet, eller flytt maskina mellom Ethernet og Wi-Fi, og adressa rutaren ser endrar seg med. Den gamle reservasjonen blir i lista og ser framleis rett ut.

Ein reinstallasjon er det andre tilfellet, og han bit hardast på IPv6. Ein fersk installasjon kan lage ein ny DUID medan den gamle IPv4-leiga framleis er gyldig, så v4-adressa overlever ei stund og v6-oppføringa sluttar å gjelde utan noka synleg endring.

Det tredje er ein fastlåst klientidentifikator. Fleire DHCP-klientar lèt deg setje ein identifikatorstreng i staden for å bruke MAC-en. Viss ei oppgradering eller ei omskriving av konfigurasjonen droppar den innstillinga, forsvinn matchinga sjølv om maskina ikkje har flytta seg.

Det fjerde er duplisering: ein utdatert blokk og ein ny blokk for same vert. Tenaren svarar med regelen som passar, ofte pooladressa du ville unngå. Slett den utdaterte oppføringa i staden for å leggje til ei ny.

Konfigurasjon på verten og kva han kostar

Å setje adressa på verten fjernar spørsmålet om matching heilt. Grensesnittet kjem opp med den adressa anten DHCP svarar eller ikkje, og det er det du vil ha frå ei maskin som må vere tilgjengeleg etter ein omstart av rutaren.

Prisen er eigarskap. Du leverer no prefikset, gatewayen og resolverane, og du må halde adressa utanfor den dynamiske poolen sjølv. På Ubuntu med netplan ber /etc/netplan/01-vpn.yaml henne:

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-brukarar når same 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 staden for netplan apply; ein feilskriven gateway tek boksen av nettet og lèt deg leite etter ein konsoll.

Hald likevel ein passande reservasjon. Han er ikkje overflødig. Oppføringa registrerer adressa på rutarsida og hindrar DHCP-tenaren i å gje den adressa til ein gjesteapparat viss nokon seinare utvidar poolen.

Ei stabil LAN-adresse er ikkje eit offentleg endepunkt

Ret port forwarding mot 192.168.50.10, og regelen overlever kvar endring på LAN-sida. Han gjev deg ikkje ei stabil internettadresse. Den offentlege IP-en din høyrer til internettleverandøren og kan flytte seg ved ei ny tilkopling eller eit modembyte, som er det dynamisk DNS er til for.

Bak carrier-grade NAT finst det inga offentleg IPv4 å videresende i det heile, og ingen reservasjon lagar ei. Sjekk WAN-sida på rutaren før noko anna: ligg adressa i eit delt område, kan innkomande videresending ikkje fungere, uansett kor rein reservasjonen er.

Den tredje adressa er tunnelpoolen, ofte noko som 10.8.0.0/24. Desse adressene finst berre inne i tunnelen og dukkar aldri opp på LAN-et. Å forveksle dei med LAN-adressa til tenaren er måten ein port til slutt blir videresend til ein klient som berre er på nett medan han er tilkopla.

Sjekk vegen i den rekkjefølgja han bryt

Start på rutaren. Samanlikn oppføringa i leigetabellen med målet for reservasjonen; har tenaren teke ei pooladresse, er identifikatoren feil, og ip link show på verten gjev deg verdien å samanlikne med.

Så verten. ip -4 addr show eth0 bør rapportere den venta adressa og prefikset. Ei andre adresse på same grensesnitt tyder vanlegvis på at DHCP framleis køyrer ved sida av den statiske konfigurasjonen din.

Så videresendinga. Stadfest at målet framleis er lik adressa du nettopp verifiserte, og stadfest at noko lyttar med ss -lntp. Ei videresending mot ein lukka port ser utanfrå nøyaktig ut som ei øydelagd videresending.

Avslutt utanfrå, på ein telefon med Wi-Fi slått av. Den eine testen skil «den lokale adressa er feil» frå «den offentlege tilgjengelegheita er øydelagd», dei to problema dette oppsettet stadig blandar saman.

Skriv ned dei tre adressene, LAN, offentleg og tunnelpool, og noter kva system som eig kvar. Når ei tilkopling feilar neste månad, veit du kva du skal undersøkje i staden for å endre alle tre samtidig.