Miks DHCP-reserveering ei ole teie VPN-serveri jaoks staatiline IP

Reserveering vastab kliendi identifikaatorile, mitte masinale, ega muuda kunagi teie avalikku IP-d staatiliseks. Mis tegelikult koduse VPN-serveri aadressi liigutab.

Lülitasin koduse VPN-karbi Wi-Fi pealt Ethernetile ja selle „püsiv“ aadress muutus samal õhtul. Ruuteril ei olnud midagi katki. Reserveering oli sobitunud juhtmevaba adapteriga ja seda adapterit ei olnud enam teel.

Samal eksiarvamusel on teine pool. LAN-aadressi parandamine ei tee midagi aadressi jaoks, millega teie sõbrad ühenduvad, ja sellel pole midagi pistmist privaatse basseiniga, mille VPN klientidele annab. Kolm aadressi, kolm eraldi rikkerežiimi ja ainult üks neist on reserveeringu töö.

Reserveering vastab kliendile, mitte seadmele

DHCPv4 puhul on reserveering seotud kliendi riistvaraaadressiga; DHCPv6 puhul DUID-ga, mille klient peaks alles hoidma. Väli hostname on silt inimeste jaoks. Ruuter võrdleb tegelikult identifikaatorit, mis päringuga saabub.

Lugege kirjet tingimusena: kui see identifikaator küsib, andke talle see aadress. Uuendused hoiavad sama rendilepingut seni, kuni sobivus püsib, ja taaskäivitus lihtsalt küsib uuesti. Kui identifikaator muutub, jääb päring reserveeringust mööda ja klient võtab selle, mida dünaamiline bassein pakub. Ei viga, ei hoiatust, lihtsalt teine aadress.

OpenWrt näitab kuju selgelt. Üks config host plokk failis /etc/config/dhcp seob nime, MAC-i ja aadressi kokku ning staatiliste rendilepingute dokumentatsioon selgitab, kuidas see kirje basseiniga suhtleb. Teised ruuterid peidavad samad kolm välja erinevate siltide taha.

Kus sobivus vaikselt läbi kukub

Riistvara vahetamine on tavaline juhtum. Vahetage võrgukaart või liigutage masin Etherneti ja Wi-Fi vahel ning aadress, mida ruuter näeb, muutub sellega kaasa. Vana reserveering jääb nimekirja ja näeb endiselt õige välja.

Ümberpaigaldus on teine juhtum ja see hammustab kõige valusamalt IPv6 juures. Värske paigaldus võib luua uue DUID-i, samal ajal kui vana IPv4 rendileping kehtib veel, nii et v4-aadress elab mõnda aega edasi ja v6-kirje lakkab kehtimast ilma nähtava muudatuseta.

Kolmas on kinnistatud kliendiidentifikaator. Mitmed DHCP-kliendid lasevad MAC-i kasutamise asemel määrata identifikaatori stringi. Kui uuendus või konfiguratsiooni ümberkirjutamine selle seade välja jätab, kaob sobivus, kuigi masin ei liikunud.

Neljas on dubleerimine: vananenud plokk ja uus plokk sama hosti jaoks. Server vastab selle reegliga, mis sobib, sageli just selle basseini aadressiga, mida te vältida tahtsite. Kustutage vananenud kirje, selle asemel et teist lisada.

Hostipoolne konfiguratsioon ja mis see maksab

Aadressi seadmine hostil eemaldab sobivuse küsimuse täielikult. Liides tuleb üles selle aadressiga olenemata sellest, kas DHCP vastab, ja seda te tahategi masinalt, mis peab olema kättesaadav ka pärast ruuteri taaskäivitust.

Hind on omand. Nüüd annate eesliite, lüüsi ja resolverid teie ning aadressi peate ise dünaamilisest basseinist väljas hoidma. Ubuntus netplaniga kannab seda /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]

NetworkManageri kasutajad jõuavad samasse olekusse käsuga nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, seejärel nmcli con up "Wired connection 1". Rakendage netplan esimesel katsel käsuga netplan try, mitte netplan apply; valesti trükitud lüüs võtab karbi võrgust välja ja jätab teid konsooli otsima.

Hoidke siiski sobiv reserveering alles. See ei ole üleliigne. Kirje fikseerib aadressi ruuteri poolel ja takistab DHCP-serveril seda aadressi külaliseadmele anda, kui keegi basseini hiljem laiendab.

Stabiilne LAN-aadress ei ole avalik lõpp-punkt

Suunake pordi edasisaadetis aadressile 192.168.50.10 ja reegel elab üle iga muudatuse LAN-i poolel. Stabiilset internetiaadressi see teile ei anna. Teie avalik IP kuulub teenusepakkujale ja võib uuesti ühendumisel või modemi vahetamisel liikuda, milleks dünaamiline DNS mõeldud ongi.

Operaatori tasandi NAT-i taga ei ole üldse avalikku IPv4-e, mida edasi saata, ja ükski reserveering seda ei loo. Kontrollige kõigepealt ruuteri WAN-lehte: kui aadress on jagatud vahemikus, ei saa sissetulev edasisaatmine töötada ükskõik kui puhas reserveering on.

Kolmas aadress on tunnelibassein, sageli midagi sellist nagu 10.8.0.0/24. Need aadressid eksisteerivad ainult tunneli sees ega ilmu kunagi LAN-is. Nende segiajamine serveri LAN-aadressiga on see, kuidas port lõpuks suunatakse kliendile, mis on võrgus ainult ühendatud olles.

Kontrollige teed selles järjekorras, nagu see katkeb

Alustage ruuterist. Võrrelge rendilepingute tabeli kirjet reserveeringu sihtmärgiga; kui server võttis basseini aadressi, on identifikaator vale, ja ip link show hostil annab teile võrdlemiseks väärtuse.

Siis host. ip -4 addr show eth0 peaks näitama oodatud aadressi ja eesliidet. Teine aadress samal liidesel tähendab tavaliselt, et DHCP töötab endiselt teie staatilise konfiguratsiooni kõrval.

Siis edasisaatmine. Kinnitage, et sihtkoht on endiselt võrdne aadressiga, mille just kontrollisite, ja et midagi kuulab käsuga ss -lntp. Suletud pordile suunatud edasisaatmine näeb väljast täpselt välja nagu katkine edasisaatmine.

Lõpetage väljastpoolt, telefoniga, mille Wi-Fi on väljas. See üks test eristab „kohalik aadress on vale“ ja „avalik kättesaadavus on katki“, need kaks probleemi, mida see seadistus pidevalt segamini ajab.

Kirjutage kolm aadressi üles, LAN, avalik ja tunnelibassein, ja märkige, milline süsteem igaüht omab. Kui järgmisel kuul ühendus ebaõnnestub, teate, millist uurida, selle asemel et kõiki kolme korraga muuta.

Seotud artiklid