A VPN-adapter /32-t mutat: ez nem egyetlen célt jelent

Az adapterek 255.255.255.255-öt mutatnak, és gyakran az a következtetés, hogy a VPN pontosan egy címre ér el. Ez az olvasat összekeveri a kliens saját címét az alagúton keresztül irányított célok halmazával. Pont-pont vagy irányított interfészen a kettő külön objektum, és csak az egyikük korlátozza az elérhetőséget. A mítosz azért marad fenn, mert a maszk úgy néz ki, mint az Etherneten tanult alhálózati maszk.

A mítosz: egy hosztmaszk egyetlen elérhető hosztot jelent

A /32 kiosztás megmondja az interfésznek, melyik cím tartozik a kapcsolat ezen végéhez, és pont-pont kapcsolaton ez minden, amit jelent. A partner címe külön mező, és az útvonalak, amelyek megmondják, mi van a partneren túl, megint külön vannak. Semmi a maszkban nem írja le a távoli hálózatot, mert a maszk nem az a hely, ahol a távoli hálózatokat leírják. Elérhetőségi korlátként olvasni olyan, mint a saját házszámunkat azon címek listájaként olvasni, amelyeket meglátogathatunk.

A zavarnak valódi gyökere van: Etherneten egy hosztmaszk valóban egyetlen címet jelentene azon a szegmensen. Az alagút nem Ethernet-szegmens, és hogy mi halad át rajta, azt a kliens útvonaltáblája dönti el, nem a maszk. Ezért állhat ugyanaz a /32 egy egész adatközpont előtt.

A címet és az útvonalakat külön objektumként olvassa

Nyomtassa ki az interfészt és a táblát együtt, majd olvassa őket két kérdés két válaszaként. A cím arra válaszol, ki ez a vég; az útvonalak arra, hova mehet a forgalom. Egy harmadik kérdés, hogy mely célokat engedi az átjáró, egyáltalán nem látszik a kliensen. Az iproute2 címreferenciája éppen ezért írja le külön a helyi cím, a partner és az előtag-útvonal mezőit.

ip addr show tun0
ip route show
ip route get 10.60.5.10

Windows alatt ugyanez a szétválás létezik a címek listája és az útvonaltábla között, és a keresőparancs a leggyorsabb módja annak, hogy lássuk, melyik nyer egy adott célra. Ha a keresés az alagút interfészét adja vissza, a kliens oda küldi a csomagot. Ha a fizikai adaptert adja vissza, a kliens soha nem kérdezi a VPN-t, és semmilyen kiszolgálóoldali engedély nem változtat ezen. Azt a célt ellenőrizze, amelyre valóban szüksége van, ne egy általános nyilvános címet.

Get-NetIPAddress -InterfaceAlias "VPN"
Find-NetRoute -RemoteIPAddress 10.60.5.10

Álljon meg, ha a keresés a rossz interfészre mutat. Ez a kliens útvonalválasztási problémája, és a kliensen javítják.

Miért rontja a maszk szélesítése általában a helyzetet

A kiosztás /24-re változtatása, hogy úgy nézzen ki, mint az irodai LAN, kapcsolati előtagot hozhat létre: a kernel most azt hiszi, hogy az egész /24 közvetlenül az alagút interfészhez kapcsolódik. Azoknak a címeknek a forgalma, amelyeket az átjárón keresztül kellene irányítani, akkor úgy megy ki, mintha szomszéd lenne a kapcsolaton. Az eredmény egy fekete lyuk, amely kiszolgálóhibának látszik.

Elrejti a valódi problémát is, vagyis a hiányzó útvonalat vagy a hiányzó engedélyt az átjárón. Egyiket sem hozza létre a szélesebb maszk, és mindkettő túléli a változtatást. Ha a tervezés nagyobb előtagot igényel az interfészen, az a használt interfészmodell döntése, amelyet a dokumentációval a kézben hoznak meg. A maszk másolása egy másik termék képernyőképeiről nem ez a döntés.

Ha a távoli előtag útvonala hiányzik, javítsa a kiépítését. Ha jelen van, és a kapcsolatot mégis elutasítják, a maszk soha nem volt a diagnózis.

Amikor az útvonal helyes, és a folyam mégis meghiúsul

A helyes útvonal csak azt bizonyítja, hogy a kliens elküldi a csomagot. Az átjárónak továbbra is el kell fogadnia a célt, a visszaútnak léteznie kell a kiosztott címhez, és a szolgáltatásnak engedélyeznie kell a folyamot. Ezt a hármat külön tesztelje: a keresést a kliensen, az átjáró engedélyezett hatókörét és egy kérést egy szükséges kiszolgálóhoz. Az, hogy a hitelesítés sikerül, mielőtt mindhárom a helyén van, normális, és ezért egy csatlakozott kliens mégis elérhet semmit.

ping -c1 10.60.5.10
traceroute -n 10.60.5.10
curl -sv https://app.internal.example/ -o /dev/null

Tartsa a hálózati objektumokat és a csoportengedélyeket a tulajdonosuknál egy eszköz által kezelt szolgáltatásban. Hogy a kliensnek mihez kell eljutnia, és hogy mit használhat, külön beállítások, gyakran külön képernyőkön. Az egyik módosítása és a másik tesztelése az, ahogyan egy jegy két csapat között pattog.

A nyugdíjazandó mítosz az, hogy a maszk elérhetőségi korlát. Olvassa a címet, az útvonalakat és az átjáró házirendjét három külön tényként, és a /32 megszűnik korlátozásnak látszani, és elkezd normál alagút-kiosztásnak látszani.