Kial DHCP-rezervo ne estas statika IP por via VPN-servilo

Mi movis hejman VPN-skatolon de Wi-Fi al Ethernet kaj ĝia „daŭra“ adreso ŝanĝiĝis tiun saman vesperon. Nenio ĉe la enkursigilo estis rompita. La rezervo kongruis kun la sendrata adaptilo, kaj tiu adaptilo jam ne estis en la vojo.

Estas dua duono de la sama miskompreno. Ripari la LAN-adreson faras nenion por la adreso, al kiu viaj amikoj konektiĝas, kaj ĝi havas nenion komunan kun la privata baseno, kiun la VPN donas al klientoj. Tri adresoj, tri apartaj fiaskmanieroj, kaj nur unu el ili estas la tasko de rezervo.

Rezervo kongruas kun kliento, ne kun aparato

En DHCPv4 la rezervo baziĝas sur la aparatara adreso de la kliento; en DHCPv6 ĝi baziĝas sur DUID, kiun la kliento devas konservi. La kampo hostname estas etikedo por homoj. Kion la enkursigilo efektive komparas, estas la identigilo, kiu alvenas en la peto.

Legu la rikordon kiel kondiĉon: kiam ĉi tiu identigilo petas, donu al ĝi ĉi tiun adreson. Renovigoj konservas la saman luon dum la kongruo validas, kaj restarto simple demandas denove. Kiam la identigilo ŝanĝiĝas, la peto maltrafas la rezervon kaj la kliento prenas tion, kion la dinamika baseno proponas. Neniu eraro, neniu averto, simple alia adreso.

OpenWrt montras la formon klare. Unu config host-bloko en /etc/config/dhcp ligas nomon, MAC kaj adreson kune, kaj la dokumentaro pri statikaj luoj klarigas, kiel tiu rikordo interagas kun la baseno. Aliaj enkursigiloj kaŝas la samajn tri kampojn malantaŭ malsamaj etikedoj.

Kie la kongruo silente falas

Anstataŭigi aparataron estas la ordinara kazo. Ŝanĝu la retkarton, aŭ movu la maŝinon inter Ethernet kaj Wi-Fi, kaj la adreso, kiun la enkursigilo vidas, ŝanĝiĝas kun ĝi. La malnova rezervo restas en la listo, ankoraŭ aspektante ĝusta.

Reinstalo estas la dua kazo, kaj ĝi plej forte mordas ĉe IPv6. Freŝa instalo povas generi novan DUID dum la malnova IPv4-luo ankoraŭ validas, do la v4-adreso postvivas iom da tempo kaj la v6-rikordo ĉesas validi sen ia videbla redakto.

La tria estas fiksita klienta identigilo. Pluraj DHCP-klientoj permesas agordi identigilan ĉenon anstataŭ uzi la MAC-on. Se ĝisdatigo aŭ reverkado de la agordo forigas tiun agordon, la kongruo malaperas eĉ se la maŝino ne moviĝis.

La kvara estas duobligo: malnova bloko kaj nova bloko por la sama gastiganto. La servilo respondas per tiu regulo, kiu kongruas, ofte per la basena adreso, kiun vi volis eviti. Forigu la malnovan rikordon anstataŭ aldoni duan.

Agordo ĉe la gastiganto kaj kion ĝi kostas

Agordi la adreson ĉe la gastiganto tute forigas la demandon pri kongruo. La interfaco leviĝas kun tiu adreso ĉu DHCP respondas ĉu ne, kaj tion vi volas de maŝino, kiu devas esti atingebla post restarto de la enkursigilo.

La kosto estas posedo. Vi nun provizas la prefikson, la enirejon kaj la solvilojn, kaj vi mem devas teni la adreson ekster la dinamika baseno. En Ubuntu kun netplan, /etc/netplan/01-vpn.yaml portas ĝin:

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]

Uzantoj de NetworkManager atingas la saman staton per nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, poste per nmcli con up "Wired connection 1". Apliku netplan per netplan try ĉe la unua provo anstataŭ per netplan apply; mistajpita enirejo forprenas la skatolon de la reto kaj lasas vin serĉi konzolon.

Tamen konservu kongruan rezervon. Ĝi ne estas superflua. La rikordo registras la adreson ĉe la enkursigila flanko kaj malhelpas la DHCP-servilon doni tiun adreson al gastaparato, se iu poste pligrandigas la basenon.

Stabila LAN-adreso ne estas publika finpunkto

Direktu la pordan plusendadon al 192.168.50.10 kaj la regulo postvivas ĉiun ŝanĝon ĉe la LAN-flanko. Ĝi ne donas al vi stabilan interretan adreson. Via publika IP apartenas al la provizanto kaj povas moviĝi ĉe rekonekto aŭ modemŝanĝo, por kio servas dinamika DNS.

Malantaŭ NAT de operatora nivelo tute ne ekzistas publika IPv4 por plusendi, kaj neniu rezervo kreas unu. Kontrolu la WAN-paĝon de la enkursigilo antaŭ ĉio alia: se la adreso estas en dividita gamo, envenanta plusendado ne povas funkcii, kiel pura ajn la rezervo estas.

La tria adreso estas la tunela baseno, ofte io kiel 10.8.0.0/24. Tiuj adresoj ekzistas nur ene de la tunelo kaj neniam aperas en la LAN. Konfuzi ilin kun la LAN-adreso de la servilo estas la maniero, kiel pordo finas plusendita al kliento, kiu estas surrete nur dum ĝi estas konektita.

Kontrolu la vojon en la ordo, en kiu ĝi rompiĝas

Komencu ĉe la enkursigilo. Komparu la rikordon de la lua tabelo kun la celo de la rezervo; se la servilo prenis basenan adreson, la identigilo estas malĝusta, kaj ip link show ĉe la gastiganto donas al vi la valoron por kompari.

Poste la gastiganto. ip -4 addr show eth0 devus raporti la atendatan adreson kaj prefikson. Dua adreso sur la sama interfaco kutime signifas, ke DHCP ankoraŭ funkcias apud via statika agordo.

Poste la plusendado. Konfirmu, ke la celo ankoraŭ egalas la adreson, kiun vi ĵus kontrolis, kaj konfirmu, ke io aŭskultas per ss -lntp. Plusendado al fermita pordo aspektas de ekstere ĝuste kiel rompita plusendado.

Finu de ekstere, per telefono kun Wi-Fi malŝaltita. Tiu unu testo apartigas «la loka adreso estas malĝusta» de «la publika atingeblo estas rompita», la du problemojn, kiujn ĉi tiu aranĝo senĉese miksas.

Skribu la tri adresojn, LAN, publika kaj tunela baseno, kaj notu, kiu sistemo posedas ĉiun. Kiam venontmonate konekto fiaskos, vi scios, kiun kontroli anstataŭ ŝanĝi ĉiujn tri samtempe.