Zakaj rezervacija DHCP ni statični IP za vaš strežnik VPN

Rezervacija se ujema z identifikatorjem odjemalca, ne s strojem, in nikoli ne naredi vašega javnega IP statičnega. Kaj v resnici premakne naslov domačega strežnika VPN.

Domačo škatlo VPN sem prestavil z Wi-Fi na Ethernet in njen „trajni“ naslov se je spremenil še isti večer. Na usmerjevalniku ni bilo nič pokvarjeno. Rezervacija se je ujemala z brezžičnim adapterjem, tega adapterja pa ni bilo več na poti.

Ista napačna predstava ima drugo polovico. Popravljanje naslova LAN ne naredi ničesar za naslov, na katerega se povezujejo vaši prijatelji, in nima nobene zveze z zasebnim bazenom, ki ga VPN daje odjemalcem. Trije naslovi, trije ločeni načini odpovedi, in samo eden od njih je delo rezervacije.

Rezervacija se ujema z odjemalcem, ne z napravo

V DHCPv4 je rezervacija vezana na strojni naslov odjemalca; v DHCPv6 na DUID, ki naj bi ga odjemalec obdržal. Polje hostname je oznaka za ljudi. Usmerjevalnik v resnici primerja identifikator, ki prispe v zahtevi.

Zapis berite kot pogoj: ko ta identifikator vpraša, mu dajte ta naslov. Podaljšanja obdržijo isti zakup, dokler ujemanje drži, ponovni zagon pa preprosto vpraša znova. Ko se identifikator spremeni, zahteva zgreši rezervacijo in odjemalec vzame, kar ponudi dinamični bazen. Brez napake, brez opozorila, samo drug naslov.

OpenWrt jasno pokaže obliko. En blok config host v /etc/config/dhcp poveže ime, MAC in naslov, in dokumentacija o statičnih zakupih pojasni, kako ta zapis sodeluje z bazenom. Drugi usmerjevalniki skrijejo ista tri polja za drugačnimi oznakami.

Kjer se ujemanje tiho pretrga

Zamenjava strojne opreme je običajen primer. Zamenjajte omrežno kartico ali premaknite stroj med Ethernetom in Wi-Fi in naslov, ki ga vidi usmerjevalnik, se spremeni z njo. Stara rezervacija ostane na seznamu in je še vedno videti pravilna.

Ponovna namestitev je drugi primer in najbolj ugrizne pri IPv6. Nova namestitev lahko ustvari nov DUID, medtem ko je stari zakup IPv4 še veljaven, zato naslov v4 nekaj časa preživi, zapis v6 pa preneha veljati brez kakršnega koli vidnega urejanja.

Tretji je pripet identifikator odjemalca. Več odjemalcev DHCP omogoča, da namesto MAC nastavite niz identifikatorja. Če posodobitev ali prepis konfiguracije to nastavitev izpusti, ujemanje izgine, čeprav se stroj ni premaknil.

Četrti je podvajanje: star blok in nov blok za istega gostitelja. Strežnik odgovori s pravilom, ki se ujema, pogosto z naslovom iz bazena, ki ste se mu hoteli izogniti. Izbrišite star zapis, namesto da dodate drugega.

Konfiguracija na strani gostitelja in kaj stane

Nastavitev naslova na gostitelju popolnoma odpravi vprašanje ujemanja. Vmesnik se dvigne s tem naslovom ne glede na to, ali DHCP odgovori, in to si želite od stroja, ki mora biti dosegljiv tudi po ponovnem zagonu usmerjevalnika.

Cena je lastništvo. Zdaj predpono, prehod in razločevalnike zagotavljate vi, naslov pa morate sami držati zunaj dinamičnega bazena. V Ubuntu z netplanom ga nosi /etc/netplan/01-vpn.yaml:

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]

Uporabniki NetworkManagera dosežejo isto stanje z nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, nato z nmcli con up "Wired connection 1". Uporabite netplan z netplan try pri prvem poskusu, ne z netplan apply; napačno vtipkan prehod vzame škatlo z omrežja in vas pusti iskati konzolo.

Vseeno obdržite ustrezno rezervacijo. Ni odveč. Zapis zabeleži naslov na strani usmerjevalnika in prepreči strežniku DHCP, da bi ta naslov dal gostujoči napravi, če kdo pozneje razširi bazen.

Stabilen naslov LAN ni javna končna točka

Usmerite posredovanje vrat na 192.168.50.10 in pravilo bo preživelo vsako spremembo na strani LAN. Stabilnega internetnega naslova pa vam ne da. Vaš javni IP pripada ponudniku in se lahko premakne ob ponovni povezavi ali zamenjavi modema, čemur je namenjen dinamični DNS.

Za NAT na ravni operaterja ni nobenega javnega IPv4 za posredovanje in nobena rezervacija ga ne ustvari. Najprej preverite stran WAN usmerjevalnika: če je naslov v skupnem obsegu, dohodno posredovanje ne more delovati, naj bo rezervacija še tako čista.

Tretji naslov je bazen tunela, pogosto nekaj kot 10.8.0.0/24. Ti naslovi obstajajo samo znotraj tunela in se nikoli ne pojavijo v omrežju LAN. Zamenjati jih z naslovom LAN strežnika je pot, po kateri vrata na koncu končajo posredovana odjemalcu, ki je na spletu le, dokler je povezan.

Preverite pot v vrstnem redu, v katerem se zlomi

Začnite na usmerjevalniku. Primerjajte zapis v tabeli zakupov s ciljem rezervacije; če je strežnik vzel naslov iz bazena, je identifikator napačen in ip link show na gostitelju vam da vrednost za primerjavo.

Nato gostitelj. ip -4 addr show eth0 bi moral pokazati pričakovani naslov in predpono. Drugi naslov na istem vmesniku običajno pomeni, da DHCP še vedno teče poleg vaše statične konfiguracije.

Nato posredovanje. Potrdite, da je cilj še vedno enak naslovu, ki ste ga pravkar preverili, in da nekaj posluša z ss -lntp. Posredovanje na zaprta vrata je od zunaj videti natanko kot pokvarjeno posredovanje.

Končajte od zunaj, na telefonu z izklopljenim Wi-Fi. Ta en sam test loči „lokalni naslov je napačen“ od „javna dosegljivost je pokvarjena“, dve težavi, ki jih ta nastavitev nenehno meša.

Zapišite tri naslove, LAN, javni in bazen tunela, in zabeležite, kateri sistem ima katerega. Ko bo naslednji mesec povezava spodletela, boste vedeli, katerega pregledati, namesto da bi spremenili vse tri hkrati.

Sorodni članki