Waarom ’n DHCP-reservering nie ’n statiese IP vir jou VPN-bediener is nie

Ek het ’n tuis-VPN-boks van Wi-Fi na Ethernet geskuif en sy “permanente” adres het dieselfde aand verander. Niks op die router was stukkend nie. Die reservering het by die draadlose adapter gepas, en daardie adapter was nie meer in die pad nie.

Daar is ’n tweede helfte aan dieselfde wanopvatting. Om die LAN-adres reg te maak, doen niks vir die adres waarmee jou vriende verbind nie, en dit het niks te doen met die private poel wat die VPN aan kliënte gee nie. Drie adresse, drie afsonderlike foutmodusse, en net een daarvan is ’n reservering se werk.

’n Reservering pas by ’n kliënt, nie by ’n toestel nie

In DHCPv4 word die reservering op die kliënt se hardewareadres geskoei; in DHCPv6 word dit op ’n DUID geskoei wat die kliënt veronderstel is om te behou. Die gasheernaamveld is ’n etiket vir mense. Wat die router werklik vergelyk, is die identifiseerder wat in die versoek aankom.

Lees die inskrywing as ’n voorwaardelike: wanneer hierdie identifiseerder vra, gee hom hierdie adres. Hernuwings behou dieselfde huur solank die passing hou, en ’n herbegin vra net weer. Wanneer die identifiseerder verander, mis die versoek die reservering en die kliënt neem wat die dinamiese poel ook al bied. Geen fout, geen waarskuwing, net ’n ander adres.

OpenWrt wys die vorm duidelik. Een config host-blok in /etc/config/dhcp bind ’n naam, ’n MAC en ’n adres saam, en die dokumentasie oor statiese hutlease verduidelik hoe daardie inskrywing met die poel omgaan. Ander routers versteek dieselfde drie velde agter verskillende etikette.

Waar die passing stilweg misluk

Om hardeware te ruil is die algemene geval. Verander die NIC, of skuif die masjien tussen Ethernet en Wi-Fi, en die adres wat die router sien, verander saam. Die ou reservering bly in die lys, steeds korrek gelykend.

Hernuinstallasie is die tweede geval, en dit byt die hardste op IPv6. ’n Vars installasie kan ’n nuwe DUID genereer terwyl die ou IPv4-huur nog geldig is, so die v4-adres oorleef ’n rukkie en die v6-inskrywing hou op om te geld sonder enige sigbare wysiging.

Derde is ’n vasgepen kliëntidentifiseerder. Verskeie DHCP-kliënte laat jou ’n identifiseerderstring stel in plaas van die MAC te gebruik. As ’n opgradering of ’n konfigurasie-herskrywing daardie instelling laat val, verdwyn die passing selfs al het die masjien nie beweeg nie.

Vierde is duplikasie: ’n verouderde blok en ’n nuwe blok vir dieselfde gasheer. Die bediener antwoord met watter reël ook al pas, dikwels die poeladres wat jy wou vermy. Skrap die verouderde inskrywing in plaas daarvan om ’n tweede by te voeg.

Gasheerkant-konfigurasie en wat dit kos

Om die adres op die gasheer te stel, verwyder die passing-vraag heeltemal. Die koppelvlak kom op met daardie adres of DHCP antwoord of nie, wat is wat jy wil hê van ’n masjien wat bereikbaar moet wees ná ’n herbegin van die router.

Die koste is eienaarskap. Jy voorsien nou die voorvoegsel, die gateway en die oplossers, en jy moet die adres self buite die dinamiese poel hou. Op Ubuntu met netplan dra /etc/netplan/01-vpn.yaml dit:

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-gebruikers bereik dieselfde toestand met nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, dan nmcli con up "Wired connection 1". Pas netplan toe met netplan try by die eerste poging eerder as netplan apply; ’n verkeerd getikte gateway haal die boks van die netwerk af en laat jou na ’n konsole gryp.

Hou nietemin ’n ooreenstemmende reservering. Dit is nie oorbodig nie. Die inskrywing teken die adres aan die routerkant aan en keer dat die DHCP-bediener daardie adres aan ’n gas toestel gee as iemand later die poel verbreed.

’n Stabiele LAN-adres is nie ’n openbare eindpunt nie

Rig die port forward na 192.168.50.10 en die reël oorleef elke verandering aan die LAN-kant. Dit gee jou nie ’n stabiele internetadres nie. Jou openbare IP behoort aan die ISP en kan verskuif by ’n herverbinding of ’n modem-ruil, wat is waarvoor dinamiese DNS is.

Agter carrier-grade NAT is daar glad geen openbare IPv4 om na te stuur nie, en geen reservering skep een nie. Kyk eerste na die router se WAN-bladsy: as die adres in ’n gedeelde reeks sit, kan inkomende deurstuur nooit werk nie, maak nie saak hoe skoon die reservering is nie.

Die derde adres is die tonnelpoel, dikwels iets soos 10.8.0.0/24. Daardie adresse bestaan net binne die tonnel en verskyn nooit op die LAN nie. Om hulle met die bediener se LAN-adres te verwar, is hoe ’n poort uiteindelik na ’n kliënt gestuur word wat net aanlyn is terwyl dit gekoppel is.

Kontroleer die pad in die orde waarin dit breek

Begin op die router. Vergelyk die huurtabel-inskrywing met die reservering se teiken; as die bediener ’n poeladres geneem het, is die identifiseerder verkeerd, en ip link show op die gasheer gee jou die waarde om te vergelyk.

Dan die gasheer. ip -4 addr show eth0 behoort die verwagte adres en voorvoegsel te rapporteer. ’n Tweede adres op dieselfde koppelvlak beteken gewoonlik DHCP loop nog langs jou statiese konfigurasie.

Dan die doorstuur. Bevestig die bestemming is steeds gelyk aan die adres wat jy pas geverifieer het, en bevestig iets luister met ss -lntp. ’n Doorstuur na ’n geslote poort lyk presies soos ’n stukkende doorstuur van buite.

Eindig van buite, op ’n selfoon met Wi-Fi af. Daardie een toets skei “die plaaslike adres is verkeerd” van “openbare bereikbaarheid is stukkend”, die twee probleme wat hierdie opstelling aanhoudend vermeng.

Skryf die drie adresse neer, LAN, openbaar en tonnelpoel, en let op watter stelsel elkeen besit. Wanneer ’n verbinding volgende maand faal, sal jy weet watter een om te ondersoek in plaas daarvan om al drie gelyk te verander.