Melyik VPN-szakasz hiúsult meg: IPsec, L2TP-vezérlés vagy PPP-hitelesítés

Megváltoztatta a jelszót, és semmi sem mozdult, mert a hiba soha nem a PPP-ben volt. Az L2TP/IPsec egyetlen kapcsolódási hibát jelent öt egészen különböző átadásra, és mindegyik átadásnak megvan a maga javítása. Dolgozzon visszafelé: keresse meg az utolsó sikeres szakaszt, és csak azt változtassa meg, ami utána jön. Az alábbi sorrend azt is eldönti, milyen bizonyítékokat gyűjt először.

Válaszoljon négy kérdésre sorrendben

Kényszerítsen ki egy új próbát, mert egyes kliensek az előző hibát mutatják, amíg a profil le nem csatlakozik és újra nem csatlakozik. Ezután válaszoljon erre: volt-e IPsec biztonsági társítás, megjelent-e L2TP vezérlőkapcsolat és hívás, eljutott-e a PPP hitelesítési döntésig, és adott-e az IPCP címet az ügyfélnek? Az első nem az a szakasz, amelyet javít. Minden utána tesztelés nélküli, ezért egy elutasított felhasználónév semmit sem bizonyít, ha soha nem létezett társítás.

Szinkronizálja az órákat mindkét végén az összehasonlítás előtt. Egy újrapróbálkozás, amely megtisztította az IPsec-et és a PPP-nél elbukott, egyetlen hibának tűnik, amikor az ügyfél csak az utolsó üzenetet mutatja, és a kiszolgáló naplója még az előző próbát őrzi. Időbélyeg szerint olvasson, ne a leghangosabb sor szerint.

Ha csak a felhasználó képernyőképe van meg, a legolcsóbb felosztásra támaszkodjon: egy rossz előre megosztott kulcs és egy soha nem válaszoló xl2tpd ugyanazt a szöveget adja a Windows párbeszédablakában, de az egyikhez mindkét végén módosított titok kell, a másikhoz pedig egy elindított daemon vagy egy tűzfalszabály magán a kiszolgálón. A középen lévő eszköz nem dobhatja el a belső 1701-et, miután az IPsec szállítási módban becsomagolta, ezért ne keressen olyan útvonalszűrőt, amely nincs ott.

Mit birtokol valójában az egyes rétegek

Az IPsec a két fél közötti csomagokat védi; az L2TP PPP-munkamenetet visz a védett útvonalon belül, ezért ír elő a RFC 3193 szállítási módot saját alagút helyett. Az ügyfél címkéje L2TP-t mond, így az alagút és a bejelentkezés egyetlen mechanizmusnak tűnik. Nem azok: az L2TP vezérlőkapcsolat a telepítés által engedélyezett helyen hitelesíti az alagút végpontjait, a PPP pedig külön hitelesíti a felhasználót CHAP, PAP vagy MS-CHAPv2 segítségével a kiszolgáló házirendje szerint.

Ez a felosztás magyarázza azt a két titkot, amelyet az emberek összekevernek. Az előre megosztott kulcs az IPsec partnereket hitelesíti. A felhasználónév és a jelszó a felhasználót azonosítja a PPP felé. A Windows megosztott titkának újragépelése egy tanúsítványokkal hitelesítő profilon semmit sem változtat a hibás szakaszban, és a PPP-jelszó szerkesztése nem pótolhat hiányzó védett csatornát. Ugyanez a mértéktartás vonatkozik az identitásellenőrzésre: ne kapcsolja ki a partner identitását vagy a tanúsítvány-érvényesítést azért, hogy alagutat kapjon, mert akkor az útvonal kapcsolódik, nem a partner.

A hitelesítés sem a PPP vége. Miután a felhasználót elfogadták, az IPCP megtárgyalja az ügyfél címét, valamint a DNS- és WINS-beállításokat, amelyeket a kiszolgáló hajlandó kiadni. Az ügyfél átmehet a CHAP-on vagy MS-CHAPv2-n, és mégis cím nélkül maradhat, ami a PPP-n belüli hiba, nem útvonalválasztási probléma. Az IPsec nélküli egyszerű L2TP érvényes és védelem nélküli marad, ezért egy sikeres kapcsolat soha nem bizonyítja, hogy a forgalom védett; azt ellenőrizze, mit ír elő a kiszolgáló, ne az ügyfél címkéjét.

Az első hiányzó szakasz alapján döntsön

A táblázatot az első hiányzó elem szerint olvassa, balról jobbra. A jobb oldali oszlop az egyetlen abban a pillanatban érdemes munka; minden, ami tőle balra van, már bizonyított, és újbóli tesztelése elégeti a kiesési ablakot anélkül, hogy információt adna.

Három sor érdemel figyelmeztetést. Az 1701-es sor az, ahol a NAT mögötti Windows-kliensek rendszerint landolnak: a társítás befejeződik, aztán semmi nem érkezik, és az ok a beágyazás, nem a rossz jelszó. Az IPCP-sor az, amelyet tévesen útvonalproblémának olvasnak, mert a Windows a hiányzó címet a 720-as hibába csomagolja, és a tálcai ikon csak azt mondja, hogy a kapcsolat meghiúsult; ez a hiba a hitelesítés után és az útvonalválasztás előtt helyezkedik el. Az utolsó sor egyáltalán nem IPsec-hiba, pedig az ikon bontott kapcsolatot jelez.

Parancsok, amelyek elválasztják a rétegeket

A strongSwant futtató Linux-kiszolgálón az swanctl --list-sas parancs felsorolja a létrejött társításokat a partner identitásával, az ipsec statusall pedig lefedi a régebbi strongSwan- és libreswan-gazdákat. Alatta az ip xfrm state a kernel tényleges társításait mutatja, míg az ss -lunp | grep 1701 bizonyítja, hová van kötve az xl2tpd. Futtassa az xl2tpd -D parancsot előtérben, hogy lássa megjelenni a vezérlőkapcsolatokat és a hívásokat, és kapcsolja be a pppd hibakeresését az /etc/ppp/options.xl2tpd fájlban, hogy lássa a felajánlott módszert és a választ.

Amikor a naplók sikeres hitelesítést mutatnak, a következő kérdés az, hogy befejeződött-e az IPCP. Ellenőrizze, hogy az /etc/xl2tpd/xl2tpd.conf fájl [lns default] szakaszában az ip range parancsnak van-e még szabad címe, és hogy az /etc/ppp/options.xl2tpd valóban tartalmazza-e az ms-dns és ms-wins beállítást, ha az ügyfél számít rájuk. Egy kimerült címkészlet és egy hiányzó DNS-beállítás másképp látszik a vonalon: az első cím nélkül és 720-cal hagyja az ügyfelet, a második címet ad, de feloldót nem, így a nevek meghiúsulnak, míg a nyers címekre küldött ping működik. Egyiket sem javítja a jelszó újrabeírása.

Az ügyfélen a NetworkManager L2TP-bővítménye a naplóba írja a pppd-beszélgetést, ezért az journalctl -u NetworkManager -b általában elválasztja a alagút áll, hitelesítés elutasítva állapotot a nincs alagút egyáltalán állapottól. Windowson az Get-VpnConnection a profil tényleges hitelesítési beállításait jelenti, és az Event Viewer Application alatti RasClient-eseményei megnevezik a hibás összetevőt. Ha a párbeszédablak túl homályos, engedélyezze az netsh ras set tracing * enable parancsot.

A rögzítésekhez egy óvatosság kell. Az IPsec szállítási módjában a belső UDP 1701 titkosított, ezért a külső interfészen készült rögzítés ESP-t mutat, vagy NAT-T alatt UDP 4500-at, és egyáltalán nem mutat L2TP-t. Az 1701 hiánya a rögzítésben várható, és nem bizonyíték a zárt portra; figyelje, mozognak-e az ESP- vagy 4500-számlálók.

NAT, MTU és útvonalak: ahol a verem megtéveszti

A NAT még azelőtt megtöri a feltevéseket, hogy bármi hitelesítve lenne. Az ESP saját IP-protokoll, ezért a fordító eszköz eldobja, hacsak a partnerek be nem ágyazzák; ezt nyújtja az UDP 4500. Egy olyan Windows-kiszolgálón, amely maga is otthoni útválasztó vagy felhő-NAT-átjáró mögött áll, az IPsec-szakasz 789-es hibával hiúsul meg, amíg az AssumeUDPEncapsulationContextOnSendRule a PolicyAgent kulcs alatt 2-re nem állítódik, és a gép újra nem indul, és a hiba megkülönböztethetetlen marad a zárt porttól. A NAT mögötti ügyfelek könnyebbek: ha a kiszolgálón nyilvános cím van, a NAT-T az UDP 4500-on viszi őket, és az az érték nem játszik szerepet.

Amikor a PPP áll, a fekete lyukas MTU halott alagutat utánoz: a kis csomagok átjutnak, a TLS-kézfogás vagy az oldalbetöltés elakad, és az ügyfél még mindig csatlakozottnak látszhat. Csökkentse az interfész MTU-ját, vagy szorítsa meg az MSS-t az átjárón, mielőtt a kiszolgálót hibáztatja. Az osztott alagút útvonalválasztása a másik csaló; a rossz maszkkal küldött alhálózat egészségesen hagyja az alagutat, és egy alkalmazást elérhetetlenné tesz. Egy privát gazdanév saját ugrást ad hozzá: ha a lekérdezés a helyi feloldón keresztül megy ki, a név nem oldódik fel, mielőtt bármely útvonalat tesztelnének.

Ellenőrzőlista, mielőtt a hitelesítő adatokhoz nyúl

Dolgozza végig a listát sorrendben, és álljon meg az első hibás elemnél. Minden lépés olcsó, és mindegyik kizárja a módosítások egy egész osztályát.

1. Erősítse meg, hogy a társítás mindkét végén létezik, a partner identitása szerint párosítva, nem csatlakozott címke alapján.
2. Erősítse meg, hogy az UDP 1701 eléri az xl2tpd-t; a hívás nélküli társítás az Ön hibája.
3. Olvassa el a PPP ítéletét, és ha hitelesített, az IPCP eredményét, mielőtt feltételezné, hogy a jelszó rossz.
4. Csak most írja be újra a hitelesítő adatokat abban a formátumban, amelyet a kiszolgáló vár, mert a tartomány-előtag megváltoztatja a fiókot.
5. Ha továbbra is meghiúsul, rögzítse mindkét végét összehangolt időbélyegekkel, és hasonlítsa össze szakaszról szakaszra.

A második lépésnél megállni útvonal- vagy beágyazási problémát jelent, és semmilyen jelszómódosítás nem mozdítja el. A harmadik lépésnél megállni azt jelenti, hogy a napló már megnevezi a javítandó módszert vagy címkészletet. Mindkét esetben a következő változtatás olyan, amelyet meg tud indokolni, és abbahagyja az olyan beállítások körbejárását, amelyek soha nem játszottak szerepet.