Miksi DHCP-varaus ei ole staattinen IP VPN-palvelimellesi

Siirsin kodin VPN-laatikon Wi-Fi:stä Ethernetiin, ja sen “pysyvä” osoite vaihtui samana iltana. Reitittimessä ei ollut mitään rikki. Varaus oli vastannut langatonta sovitinta, eikä se sovitin ollut enää reitillä.

Samalla väärinkäsityksellä on toinen puoli. LAN-osoitteen korjaaminen ei tee mitään sille osoitteelle, johon ystäväsi yhdistävät, eikä sillä ole mitään tekemistä sen yksityisen altaan kanssa, jonka VPN antaa asiakkaille. Kolme osoitetta, kolme erillistä vikatilaa, ja vain yksi niistä on varauksen työtä.

Varaus vastaa asiakasta, ei laitetta

DHCPv4:ssä varaus perustuu asiakkaan laiteosoitteeseen; DHCPv6:ssa se perustuu DUID-tunnisteeseen, joka asiakkaan odotetaan säilyttävän. hostname-kenttä on ihmisille tarkoitettu nimiö. Reititin vertaa itse asiassa sitä tunnistetta, joka saapuu pyynnössä.

Lue merkintä ehdollisena: kun tämä tunniste kysyy, anna sille tämä osoite. Uudistukset pitävät saman vuokrasuhteen niin kauan kuin vastaavuus pitää, ja uudelleenkäynnistys vain kysyy uudelleen. Kun tunniste muuttuu, pyyntö ohittaa varauksen ja asiakas ottaa sen, mitä dynaaminen allas tarjoaa. Ei virhettä, ei varoitusta, vain eri osoite.

OpenWrt näyttää muodon selvästi. Yksi config host-lohko tiedostossa /etc/config/dhcp sitoo nimen, MAC-osoitteen ja osoitteen yhteen, ja staattisten vuokrausten dokumentaatio kertoo, miten tämä merkintä toimii altaan kanssa. Muut reitittimet piilottavat samat kolme kenttää eri nimikkeiden taakse.

Missä vastaavuus hiljaa pettää

Laitteiston vaihtaminen on tavallinen tapaus. Vaihda verkkokortti tai siirrä kone Ethernetin ja Wi-Fi:n välillä, ja osoite, jonka reititin näkee, vaihtuu mukana. Vanha varaus jää luetteloon ja näyttää edelleen oikealta.

Uudelleenasennus on toinen tapaus, ja se puree kovimmin IPv6:ssa. Tuore asennus voi luoda uuden DUID-tunnisteen, kun vanha IPv4-vuokraus on vielä voimassa, joten v4-osoite säilyy hetken ja v6-merkintä lakkaa toimimasta ilman näkyvää muokkausta.

Kolmas on kiinnitetty asiakastunniste. Useat DHCP-asiakkaat antavat asettaa tunnisteen merkkijonon MAC-osoitteen käyttämisen sijaan. Jos päivitys tai määrityksen uudelleenkirjoitus pudottaa tämän asetuksen, vastaavuus katoaa, vaikka kone ei olisi liikkunut.

Neljäs on kahdentaminen: vanhentunut lohko ja uusi lohko samalle isännälle. Palvelin vastaa sillä säännöllä, joka vastaa, usein juuri sillä altaan osoitteella, jota halusit välttää. Poista vanhentunut merkintä sen sijaan, että lisäisit toisen.

Isäntäpuolen määritys ja mitä se maksaa

Osoitteen asettaminen isäntään poistaa vastaavuuskysymyksen kokonaan. Liitäntä nousee sillä osoitteella riippumatta siitä, vastaako DHCP, ja sitä haluat koneelta, jonka on oltava tavoitettavissa reitittimen uudelleenkäynnistyksen jälkeen.

Hinta on omistajuus. Sinä toimitat nyt etuliitteen, yhdyskäytävän ja ratkaisijat, ja sinun on itse pidettävä osoite dynaamisen altaan ulkopuolella. Ubuntussa netplanilla sen kantaa /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]

NetworkManagerin käyttäjät pääsevät samaan tilaan komennolla nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1 ja sitten nmcli con up "Wired connection 1". Käytä netplania ensimmäisellä yrityksellä komennolla netplan try eikä netplan apply; väärin kirjoitettu yhdyskäytävä pudottaa laatikon verkosta ja jättää sinut etsimään konsolia.

Pidä silti vastaava varaus. Se ei ole tarpeeton. Merkintä tallentaa osoitteen reitittimen puolelle ja estää DHCP-palvelinta antamasta sitä osoitetta vieraslaitteelle, jos joku myöhemmin laajentaa allasta.

Vakaa LAN-osoite ei ole julkinen päätepiste

Suuntaa portin edelleenohjaus osoitteeseen 192.168.50.10, ja sääntö kestää jokaisen LAN-puolen muutoksen. Se ei anna sinulle vakaata internet-osoitetta. Julkinen IP-osoitteesi kuuluu operaattorille ja voi siirtyä uudelleenyhdistämisessä tai modeemin vaihdossa, mihin dynaaminen DNS on tarkoitettu.

Operaattoritason NAT:n takana ei ole lainkaan julkista IPv4-osoitetta edelleenohjattavaksi, eikä mikään varaus luo sellaista. Tarkista reitittimen WAN-sivu ennen muuta: jos osoite on jaetulla alueella, saapuva edelleenohjaus ei voi toimia, niin puhdas varaus kuin onkaan.

Kolmas osoite on tunneliallas, usein jotain kuten 10.8.0.0/24. Ne osoitteet ovat olemassa vain tunnelin sisällä eivätkä koskaan ilmesty LANiin. Niiden sekoittaminen palvelimen LAN-osoitteeseen on se tapa, jolla portti päätyy edelleenohjatuksi asiakkaalle, joka on verkossa vain ollessaan yhteydessä.

Tarkista polku siinä järjestyksessä, jossa se katkeaa

Aloita reitittimestä. Vertaa vuokrataulukon merkintää varauksen kohteeseen; jos palvelin otti altaan osoitteen, tunniste on väärä, ja ip link show isännässä antaa vertailtavan arvon.

Sitten isäntä. ip -4 addr show eth0 näyttää odotetun osoitteen ja etuliitteen. Toinen osoite samassa liitännässä tarkoittaa yleensä, että DHCP käy edelleen staattisen määrityksesi rinnalla.

Sitten edelleenohjaus. Varmista, että kohde on edelleen sama kuin juuri tarkistamasi osoite, ja että jokin kuuntelee komennolla ss -lntp. Suljettuun porttiin osoittava edelleenohjaus näyttää ulkopuolelta täsmälleen rikkinäiseltä edelleenohjaukselta.

Viimeistele ulkopuolelta, puhelimella, jonka Wi-Fi on pois päältä. Se yksi testi erottaa toisistaan “paikallinen osoite on väärä” ja “julkinen tavoitettavuus on rikki”, ne kaksi ongelmaa, jotka tämä kokoonpano sekoittaa jatkuvasti.

Kirjoita kolme osoitetta muistiin, LAN, julkinen ja tunneliallas, ja merkitse, mikä järjestelmä omistaa minkäkin. Kun yhteys ensi kuussa epäonnistuu, tiedät mitä tutkia sen sijaan, että vaihtaisit kaikki kolme kerralla.