De ce o rezervare DHCP nu este un IP static pentru serverul tău VPN

Am mutat o cutie VPN de acasă de pe Wi-Fi pe Ethernet și adresa ei „permanentă“ s-a schimbat în aceeași seară. Pe router nu era nimic stricat. Rezervarea corespundea adaptorului wireless, iar acel adaptor nu mai era pe traseu.

Aceeași neînțelegere are o a doua jumătate. Repararea adresei LAN nu face nimic pentru adresa la care se conectează prietenii tăi și nu are nicio legătură cu pool-ul privat pe care VPN-ul îl dă clienților. Trei adrese, trei moduri separate de eșec și doar unul dintre ele este treaba unei rezervări.

O rezervare corespunde unui client, nu unui dispozitiv

În DHCPv4 rezervarea este legată de adresa hardware a clientului; în DHCPv6 este legată de un DUID pe care clientul ar trebui să îl păstreze. Câmpul hostname este o etichetă pentru oameni. Ce compară de fapt routerul este identificatorul care sosește în cerere.

Citește intrarea ca pe o condiție: când acest identificator cere, dă-i această adresă. Reînnoirile păstrează același lease cât timp potrivirea rezistă, iar o repornire doar cere din nou. Când identificatorul se schimbă, cererea ratează rezervarea și clientul ia ce oferă pool-ul dinamic. Fără eroare, fără avertisment, doar o altă adresă.

OpenWrt arată forma clar. Un bloc config host în /etc/config/dhcp leagă un nume, un MAC și o adresă împreună, și documentația despre lease-urile statice explică modul în care acea intrare interacționează cu pool-ul. Alte routere ascund aceleași trei câmpuri în spatele unor etichete diferite.

Unde potrivirea cade în liniște

Schimbarea hardware-ului este cazul obișnuit. Schimbă placa de rețea sau mută mașina între Ethernet și Wi-Fi, iar adresa pe care o vede routerul se schimbă cu ea. Rezervarea veche rămâne în listă și încă pare corectă.

O reinstalare este al doilea caz și mușcă cel mai tare pe IPv6. O instalare nouă poate genera un DUID nou în timp ce lease-ul IPv4 vechi este încă valid, așa că adresa v4 supraviețuiește o vreme, iar intrarea v6 încetează să se aplice fără nicio modificare vizibilă.

Al treilea este un identificator de client fixat. Mai mulți clienți DHCP îți permit să setezi un șir de identificator în loc să folosești MAC-ul. Dacă un update sau o rescriere a configurației aruncă acea setare, potrivirea dispare chiar dacă mașina nu s-a mișcat.

Al patrulea este duplicarea: un bloc vechi și un bloc nou pentru același host. Serverul răspunde cu regula care se potrivește, adesea cu adresa din pool pe care voiai să o eviți. Șterge intrarea veche în loc să adaugi una nouă.

Configurația de pe partea hostului și cât costă

Setarea adresei pe host elimină complet întrebarea despre potrivire. Interfața urcă cu acea adresă indiferent dacă DHCP răspunde sau nu, și asta vrei de la o mașină care trebuie să fie accesibilă după o repornire a routerului.

Costul este proprietatea. Acum tu furnizezi prefixul, gateway-ul și resolverele, iar adresa trebuie ținută de tine în afara pool-ului dinamic. Pe Ubuntu cu netplan, o duce /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]

Utilizatorii NetworkManager ajung în aceeași stare cu nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, apoi cu nmcli con up "Wired connection 1". Aplică netplan cu netplan try la prima încercare în loc de netplan apply; un gateway scris greșit scoate cutia din rețea și te lasă căutând o consolă.

Păstrează totuși o rezervare potrivită. Nu este redundată. Intrarea înregistrează adresa pe partea routerului și împiedică serverul DHCP să dea acea adresă unui dispozitiv oaspete dacă cineva lărgește pool-ul mai târziu.

O adresă LAN stabilă nu este un punct final public

Îndreaptă port forward-ul spre 192.168.50.10 și regula supraviețuiește fiecărei schimbări de pe partea LAN. Nu îți dă o adresă de internet stabilă. IP-ul tău public aparține ISP-ului și se poate muta la o reconectare sau la o schimbare de modem, pentru asta există DNS-ul dinamic.

În spatele NAT-ului de nivel de operator nu există niciun IPv4 public de redirecționat, iar nicio rezervare nu creează unul. Verifică pagina WAN a routerului înainte de orice: dacă adresa este într-un interval partajat, redirecționarea de intrare nu poate funcționa, oricât de curată ar fi rezervarea.

A treia adresă este pool-ul tunelului, adesea ceva ca 10.8.0.0/24. Acele adrese există doar în interiorul tunelului și nu apar niciodată în LAN. Confundarea lor cu adresa LAN a serverului este felul în care un port ajunge redirecționat către un client care este online doar cât timp este conectat.

Verifică traseul în ordinea în care se rupe

Începe cu routerul. Compară intrarea din tabelul de lease-uri cu ținta rezervării; dacă serverul a luat o adresă din pool, identificatorul este greșit, iar ip link show pe host îți dă valoarea de comparat.

Apoi hostul. ip -4 addr show eth0 ar trebui să raporteze adresa și prefixul așteptate. O a doua adresă pe aceeași interfață înseamnă de obicei că DHCP încă rulează lângă configurația ta statică.

Apoi redirecționarea. Confirmă că destinația este încă egală cu adresa pe care tocmai ai verificat-o și că ceva ascultă cu ss -lntp. O redirecționare către un port închis arată din exterior exact ca o redirecționare stricată.

Termină din exterior, pe un telefon cu Wi-Fi oprit. Acel singur test separă „adresa locală este greșită“ de „accesibilitatea publică este stricată“, cele două probleme pe care această configurație le amestecă mereu.

Notează cele trei adrese, LAN, publică și pool-ul tunelului, și marchează ce sistem o deține pe fiecare. Când luna viitoare o conexiune va eșua, vei ști pe care să o inspectezi în loc să le schimbi pe toate trei deodată.