Az az L2TP-cím IPCP, nem DHCP-bérlet a LAN-on

A kapcsolat feljön, és az adapter az iroda tartományába eső címet mutat, így a természetes következtetés az, hogy a VPN LAN-címet adott, és ezzel a LAN-ra helyezett. Ennek egyik fele sem teljesen igaz. L2TP PPP-munkamenetet szállít, és a PPP az IPCP-vel tárgyalja a belső IPv4-címet. Ez a cím két fél között megállapodott munkamenet-paraméter, nem az iroda DHCP-kiszolgálója által kiadott bérlet, és a birtoklása nem tesz szomszéddá az iroda kábelén.

Két cím egy kapcsolatban

Egy L2TP-kapcsolatban két független tárgyalás van. A külső védett útvonalat épít a készüléke és a VPN-végpont között a már meglévő hálózatán. A belső a PPP-munkamenet, és ott állapodnak meg a munkamenet-címéről és a másik fél címéről. Az internetes forgalom teljesen egy harmadik cím, a végpont nyilvános címe alatt is kiléphet, ezért a VPN-ellenőrző oldal és az adapter címe ritkán egyezik.

E három szerep szétválasztása megválaszolja a legtöbb kérdést, amit az emberek ehhez a réteghez hoznak. A VPN-interfészen egy privát szám normális és várható. Nem mond semmit arról, hogy a végpont megváltoztatta-e a nyilvános kimenetét, és önmagában nem dönti el, mely célokat éri el a forgalom.

Mit tesz pontosan az IPCP

Az IPCP a PPP IPv4-vezérlő protokollja. Mindkét fél Configure-Request üzeneteket küld a kívánt beállításokról, és a címopció ezek egyike. Az a kliens, amelynek még nincs címe, általában 0.0.0.0-val kérdez, a kiszolgáló pedig egy Configure-Nak üzenettel válaszol, amelyben a kliens számára kívánt címet hordozza. Ezután a kliens kéri ezt a címet, és a munkamenet feljön egy helyi és egy távoli címmel.

Ezt a cserét a PPP és IPCP specifikációi dokumentálják, és megmagyaráz egy hibának látszó részletet: a címet a kiszolgáló a saját szabályzata szerint választja, ami lehet gyűjtemény, felhasználónkénti beállítás vagy a hitelesített személyhez kötött cím. Ha a gyűjtemény kimerül, vagy a szabályzat ütközik a kéréssel, a hitelesítés sikerülhet, miközben a címtárgyalás meghiúsul, és a kliens soha meg nem állapodó kapcsolatot jelent.

ip addr show ppp0
ip route show default
dmesg | grep -i pppd

A pppd naplójában egy helyi és egy távoli címet megnevező sor e tárgyalás sikeres vége. Ha ez hiányzik egy sikeres hitelesítés mellett, az a cím szakaszára utal, nem a hitelesítő adatokra.

Miért nem tud a LAN válaszolni önnek

A távoli fél tartományából származó cím azt a várakozást kelti, hogy azon a LAN-on lévő gazdagépek elérnek, és legtöbbször nem érnek el, hacsak a kiszolgáló vissza nem irányítja a munkamenet-címét az alagútba. Egy gyűjteményen belül lenni a kiosztásról szóló állítás, nem a topológiáról. Az iroda fájlkiszolgálójának nincs útvonala a munkamenet-címéhez, hacsak a VPN-kiszolgáló tovább nem adja, és még ha tovább is adja, lehet, hogy nem engedélyezett.

Ezért okoznak az átfedő tartományok látszólagos méretükhöz képest aránytalan gondokat. Ha a gyűjtemény átfed egy olyan LAN-nal, amelyet a kliens már használ, a kliens útválasztási táblájában most két igény van ugyanarra az előtagra, és gyakran a rossz nyer olyan okokból, amelyeknek semmi közük az alagúthoz.

Először a munkamenetet, aztán az útvonalat

Először az interfészt, aztán az útvonalakat, aztán egy fontos célt ellenőrizzen. Mindegyik lépésnek megvan a maga hibaformája, és mindhárom egyszerre való tesztelése olyan következtetést ad, amelyet később nem tud megvédeni.

curl -sS --max-time 5 https://ifconfig.me
ping -c 3 10.50.30.20
ip route get 10.50.30.20

Ha a nyilvános ellenőrzés a végpont címét mutatja, miközben egy privát cél időtúllépéssel lejár, az alagút az alapértelmezett útvonalát szállítja, és a távoli fél nem válaszol arra a célra. Ha a privát cél válaszol, de a nyilvános ellenőrzés nem változik, a profil osztott alagutazást használ, és csak a forgalom egy része használja a munkamenetet.

Tartsa külön a három szakaszt

A hitelesítés, a címtárgyalás és a továbbítás különbözőképpen hibázik, és mindegyiknek más a felelőse. A hitelesítő adatok identitásprobléma, az IPCP kimerülése kiszolgálószabályzat-probléma, a hiányzó visszaútvonal pedig hálózattervezési probléma. Mindhármat „a VPN tönkrement” néven jelenteni lassú javítást garantál.

Jegyezze fel a kiosztott címet, a gyűjteményt, amelyből jött, és hogy a LAN-nak el kell-e érnie. Ez az egyetlen feljegyzés megakadályozza, hogy a következő ember DHCP-bérletet feltételezzen, és olyan tartományt keressen, amely soha nem volt érintett.