Miért nem statikus IP a DHCP-foglalás a VPN-szerveredhez

Átvittem egy otthoni VPN-dobozt Wi-Fi-ről Ethernetre, és a „végleges” címe még aznap este megváltozott. A routeren semmi nem volt elromolva. A foglalás a vezeték nélküli adapterhez illeszkedett, és az az adapter már nem volt az útvonalon.

Ugyanennek a tévhitnek van egy második fele. A LAN-cím rendbetétele semmit nem tesz azért a címért, amelyre a barátaid csatlakoznak, és semmi köze ahhoz a privát poolhoz, amelyet a VPN az ügyfeleknek ad. Három cím, három külön hiba mód, és ezek közül csak egy tartozik a foglalás feladatához.

A foglalás ügyfélhez illeszkedik, nem eszközhöz

DHCPv4-ben a foglalás az ügyfél hardvercíméhez kötődik; DHCPv6-ban egy DUID-hez, amelyet az ügyfélnek meg kell tartania. A hostname mező embereknek szóló címke. Amit a router valójában összehasonlít, az a kérésben érkező azonosító.

Olvasd a bejegyzést feltételként: amikor ez az azonosító kér, add neki ezt a címet. A megújítások ugyanazt a bérletet tartják, amíg az egyezés fennáll, és az újraindítás csak újra kér. Amikor az azonosító megváltozik, a kérés elkerüli a foglalást, és az ügyfél azt kapja, amit a dinamikus pool kínál. Nincs hiba, nincs figyelmeztetés, csak egy másik cím.

Az OpenWrt tisztán mutatja a formát. Egy config host blokk a /etc/config/dhcp fájlban összeköti a nevet, a MAC-címet és a címet, és a statikus bérletek dokumentációja elmagyarázza, hogyan hat kölcsön a bejegyzés a poolra. Más routerek ugyanezt a három mezőt különböző címkék mögé rejtik.

Ahol az egyezés csendben megszakad

A hardvercsere a szokásos eset. Cseréld a hálózati kártyát, vagy mozgasd a gépet Ethernet és Wi-Fi között, és a cím, amelyet a router lát, vele együtt változik. A régi foglalás a listán marad, és továbbra is helyesnek látszik.

Az újratelepítés a második eset, és IPv6-nál harap a legjobban. Egy friss telepítés új DUID-et hozhat létre, miközben a régi IPv4-bérlet még érvényes, így a v4-cím egy ideig túlél, a v6-bejegyzés pedig látható szerkesztés nélkül érvénytelenné válik.

A harmadik a rögzített ügyfél-azonosító. Több DHCP-ügyfél engedi, hogy a MAC helyett azonosító karakterláncot állíts be. Ha egy frissítés vagy a konfiguráció újraírása kihagyja ezt a beállítást, az egyezés eltűnik, pedig a gép nem mozdult el.

A negyedik a duplikáció: egy régi blokk és egy új blokk ugyanahhoz a hoszthoz. A szerver azzal a szabállyal válaszol, amelyik illeszkedik, gyakran épp azzal a pool-címmel, amelyet el akartál kerülni. Töröld a régi bejegyzést, ahelyett hogy másodikat adnál hozzá.

Konfiguráció a host oldalán, és hogy mi az ára

A cím hoston való beállítása teljesen kiveszi az egyezés kérdését. Az interfész ezzel a címmel jön fel, akár válaszol a DHCP, akár nem, és ezt akarod egy olyan géptől, amelynek a router újraindítása után is elérhetőnek kell lennie.

Az ár a tulajdonjog. Most te adod a prefixet, az átjárót és a feloldókat, és neked kell a címet a dinamikus poolon kívül tartanod. Az Ubuntu netplannal ezt a /etc/netplan/01-vpn.yaml hordozza:

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]

A NetworkManager felhasználói ugyanerre az állapotra jutnak a nmcli con mod "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.50.10/24 ipv4.gateway 192.168.50.1, majd a nmcli con up "Wired connection 1" használatával. Az első próbálkozásnál a netplan apply helyett a netplan try eszközzel alkalmazd a netplant; egy elgépelt átjáró leveszi a dobozt a hálózatról, és konzolt keresve hagy.

Tarts mégis egyező foglalást. Nem felesleges. A bejegyzés a router oldalán rögzíti a címet, és megakadályozza, hogy a DHCP-szerver ezt a címet egy vendégeszköznek adja, ha valaki később nagyobbítja a poolt.

A stabil LAN-cím nem nyilvános végpont

Irányítsd a porttovábbítást a 192.168.50.10-re, és a szabály túlél minden LAN oldali változást. Stabil internetcímet nem ad. A nyilvános IP-d a szolgáltatóé és újracsatlakozáskor vagy modemcserénél elmozdulhat, a dinamikus DNS épp ezért van.

Operátorszintű NAT mögött egyáltalán nincs nyilvános IPv4, amit továbbíthatnál, és egyetlen foglalás sem hoz létre egyet. Mindenekelőtt a router WAN-oldalát nézd meg: ha a cím megosztott tartományban van, a bejövő továbbítás nem működhet, bármilyen tiszta a foglalás.

A harmadik cím az alagút poolja, gyakran valami, mint a 10.8.0.0/24. Azok a címek csak az alagúton belül léteznek, és soha nem jelennek meg a LAN-on. Összekeverni őket a szerver LAN-címével az az út, amelyen egy port végül egy olyan ügyfélhez továbbítódik, amely csak akkor van online, amíg csatlakozva van.

Ellenőrizd az útvonalat abban a sorrendben, ahogy elszakad

Kezdd a routeren. Hasonlítsd össze a bérlettábla bejegyzését a foglalás céljával; ha a szerver pool-címet vett fel, az azonosító rossz, és a hoston a ip link show megadja az összehasonlításhoz szükséges értéket.

Aztán a host. A ip -4 addr show eth0 jeleznie kell a várt címet és prefixet. Egy második cím ugyanazon az interfészen általában azt jelenti, hogy a DHCP még a statikus konfigurációd mellett fut.

Aztán a továbbítás. Erősítsd meg, hogy a cél továbbra is egyenlő azzal a címmel, amelyet épp ellenőriztél, és hogy valami figyel a ss -lntp segítségével. Egy zárt portra mutató továbbítás kívülről pontosan úgy néz ki, mint egy elromlott továbbítás.

Kívülről fejezd be, egy telefonnal, kikapcsolt Wi-Fi mellett. Ez az egyetlen teszt választja el a „rossz a helyi cím” és a „nyilvános elérhetőség elromlott” esetét, a két problémát, amelyet ez a beállítás folyton összekever.

Írd fel a három címet, LAN, nyilvános és alagút-pool, és jegyezd meg, melyik rendszer birtokolja melyiket. Ha jövő hónapban egy kapcsolat meghiúsul, tudni fogod, melyiket vizsgáld, ahelyett hogy mindhármat egyszerre változtatnád.