Kodėl DHCP rezervacija nėra statinis IP jūsų VPN serveriui

Perkėliau namų VPN dėžutę iš Wi-Fi į Ethernet, ir jos „nuolatinis“ adresas pasikeitė tą patį vakarą. Maršrutizatoriuje niekas nebuvo sugedę. Rezervacija atitiko belaidį adapterį, o to adapterio kelyje jau nebuvo.

Tas pats klaidingas supratimas turi antrą pusę. LAN adreso sutvarkymas nieko nepadaro adresui, prie kurio jungiasi jūsų draugai, ir neturi nieko bendra su privačiu baseinu, kurį VPN duoda klientams. Trys adresai, trys atskiri gedimo režimai, ir tik vienas jų yra rezervacijos darbas.

Rezervacija atitinka klientą, o ne įrenginį

DHCPv4 rezervacija siejama su kliento aparatiniu adresu; DHCPv6 – su DUID, kurį klientas turėtų išlaikyti. hostname laukas yra žmonėms skirta etiketė. Maršrutizatorius iš tikrųjų lygina identifikatorių, kuris ateina užklausoje.

Skaitykite įrašą kaip sąlygą: kai šis identifikatorius paprašo, duokite jam šį adresą. Atnaujinimai išlaiko tą pačią nuomą, kol atitikimas galioja, o perkrovimas tiesiog vėl paprašo. Kai identifikatorius pasikeičia, užklausa praleidžia rezervaciją ir klientas gauna tai, ką siūlo dinaminis baseinas. Jokios klaidos, jokio įspėjimo, tik kitas adresas.

OpenWrt aiškiai parodo formą. Vienas config host blokas faile /etc/config/dhcp susieja vardą, MAC ir adresą, ir statinės nuomos dokumentacija paaiškina, kaip tas įrašas sąveikauja su baseinu. Kiti maršrutizatoriai tuos pačius tris laukus slepia po kitokiomis etiketėmis.

Kur atitikimas tyliai nutrūksta

Aparatinės įrangos keitimas yra įprastas atvejis. Pakeiskite tinklo plokštę arba perkelkite mašiną tarp Ethernet ir Wi-Fi, ir adresas, kurį mato maršrutizatorius, pasikeičia kartu. Sena rezervacija lieka sąraše ir vis dar atrodo teisinga.

Perdiegimas yra antras atvejis, ir jis stipriausiai kandžiojasi IPv6. Naujas diegimas gali sukurti naują DUID, kol sena IPv4 nuoma dar galioja, todėl v4 adresas kurį laiką išlieka, o v6 įrašas nustoja galioti be jokio matomo pakeitimo.

Trečias – prisegtas kliento identifikatorius. Keli DHCP klientai leidžia nustatyti identifikatoriaus eilutę vietoj MAC naudojimo. Jei atnaujinimas ar konfigūracijos perrašymas tą nustatymą numeta, atitikimas išnyksta, nors mašina nepasistūmėjo.

Ketvirtas – dubliavimas: senas blokas ir naujas blokas tam pačiam hostui. Serveris atsako ta taisykle, kuri atitinka, dažnai tuo baseino adresu, kurio norėjote išvengti. Ištrinkite seną įrašą, o ne pridėkite antrą.

Konfigūracija hosto pusėje ir kiek ji kainuoja

Adreso nustatymas hoste visiškai pašalina atitikimo klausimą. Sąsaja pakyla su tuo adresu, nesvarbu, ar DHCP atsako, ir to jūs norite iš mašinos, kuri turi būti pasiekiama po maršrutizatoriaus perkrovimo.

Kaina – nuosavybė. Dabar prefiksą, tinklų sietuvą ir sprendėjus tiekite jūs, ir adresą patys turite laikyti už dinaminio baseino ribų. Ubuntu su netplan tai neša /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]

NetworkManager naudotojai pasiekia tą pačią būseną su nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, paskui su nmcli con up "Wired connection 1". Pirmuoju bandymu taikykite netplan su netplan try, o ne su netplan apply; neteisingai įvestas tinklų sietuvas išima dėžutę iš tinklo ir palieka ieškoti konsolės.

Vis tiek palikite atitinkančią rezervaciją. Ji nėra nereikalinga. Įrašas užfiksuoja adresą maršrutizatoriaus pusėje ir neleidžia DHCP serveriui duoti to adreso svečio įrenginiui, jei kas nors vėliau padidins baseiną.

Stabilus LAN adresas nėra viešas galinis taškas

Nukreipkite prievado persiuntimą į 192.168.50.10, ir taisyklė atlaikys kiekvieną LAN pusės pakeitimą. Stabilaus interneto adreso ji neduoda. Jūsų viešasis IP priklauso ISP ir gali pasistumėti persijungus ar pakeitus modemą, tam ir yra dinaminis DNS.

Už operatoriaus lygio NAT viešo IPv4 persiuntimui apskritai nėra, ir jokia rezervacija jo nesukuria. Pirmiausia patikrinkite maršrutizatoriaus WAN puslapį: jei adresas yra bendrame diapazone, įeinantis persiuntimas negali veikti, kad ir kokia tvarkinga būtų rezervacija.

Trečias adresas yra tunelio baseinas, dažnai kažkas panašaus į 10.8.0.0/24. Tie adresai egzistuoja tik tunelio viduje ir niekada nepasirodo LAN tinkle. Sumaišyti juos su serverio LAN adresu – tai kelias, kuriuo prievadas galiausiai persiunčiamas klientui, kuris būna prisijungęs tik tol, kol yra prijungtas.

Tikrinkite kelią ta tvarka, kuria jis lūžta

Pradėkite nuo maršrutizatoriaus. Palyginkite nuomos lentelės įrašą su rezervacijos tikslu; jei serveris paėmė baseino adresą, identifikatorius neteisingas, o ip link show hoste duoda reikšmę palyginimui.

Tada hostas. ip -4 addr show eth0 turėtų parodyti laukiamą adresą ir prefiksą. Antras adresas toje pačioje sąsajoje paprastai reiškia, kad DHCP vis dar veikia šalia jūsų statinės konfigūracijos.

Tada persiuntimas. Patvirtinkite, kad paskirties vieta vis dar lygi adresui, kurį ką tik patikrinote, ir kad kažkas klausosi su ss -lntp. Persiuntimas į uždarą prievadą iš išorės atrodo lygiai kaip sugedęs persiuntimas.

Užbaikite iš išorės, telefone išjungus Wi-Fi. Tas vienas testas atskiria „vietinis adresas neteisingas“ nuo „viešas pasiekiamumas sugedęs“, dvi problemas, kurias ši sąranka nuolat maišo.

Užsirašykite tris adresus, LAN, viešąjį ir tunelio baseiną, ir pažymėkite, kuri sistema kurį valdo. Kai kitą mėnesį ryšys nutrūks, žinosite, kurį tikrinti, o ne keisite visus tris iš karto.