Miért állnak meg a PPTP és az L2TP/IPsec a felhasználónév kérése előtt?

A hiányzó felhasználónév-kérés diagnosztikai ajándék: a PPP még nem indult el, tehát a fiókot, a jelszót és a tartományi házirendet még nem kérdezte meg. PPTP- vagy L2TP/IPsec-kapcsolatban az ügyfél csak akkor kér hitelesítő adatokat, amikor az alagút már létezik, és a kiszolgáló elindított egy PPP-munkamenetet. Minden, ami e pillanat előtt meghiúsulhat, szállítás, kulcscsere vagy alagútépítés, ami sokkal kisebb felület, mint hogy „a VPN elromlott”.

A hiányzó kérés három szakaszra szűkíti a hibát

Jegyezze fel az utolsó láthatóan sikeres szakaszt, mert mindegyiknek más a gazdája és más a javítása. A fiókbeállításokon találgatni, miközben két szakasszal korábban elakadt, így tűnik el egy délután.

Az a kliens, amely kérés nélkül fut ki, soha nem kapott IPsec-társulást, tehát a hiba az IKE-ben van, vagy abban, hogy a csomagjai egyáltalán elérik-e az átjárót. Amelyik azt jelzi, hogy hitelesítő adatokat ellenőriz, majd leesik, tovább jutott, mint amit az üzenet sugall. A kérést követő elutasítás PPP-hitelesítés, és az a fiókról szóló cikkbe tartozik, nem ebbe.

Első szakasz: a protokoll, amelyet a tűzfal csendben eldob

A PPTP vezérlőcsatornájához TCP 1723 kell, az adatútvonalhoz pedig IP-protokoll 47, és a kettő külön utazik. Sok hálózat továbbítja az 1723-at és eldobja a 47-es protokollt, ami olyan alagutat eredményez, amely tárgyal, majd semmit sem szállít. A NAT-ot végző útválasztónak GRE-képes átjárásra is szüksége van, és a csak IPv6-os hozzáférési útvonal semmilyen konfigurációban nem tud PPTP-t szállítani.

Az IPsec feletti L2TP az 500-as portot használja az IKE-hez és a 4500-as portot a NAT átjárásához, majd magát az L2TP-forgalmat az 1701-es portba csomagolja, míg az ESP a védett terhet szállítja, amint a társulás létrejön. Engedélyezze a két vezérlőportot, de az ESP-t ne, és pontosan a címbeli tünetet kapja: látható előrehaladás, majd halott kliens minden hitelesítő adat párbeszéd előtt. A tesztelés telefonos hotspotról olcsó módja annak, hogy elválassza az ügyfélproblémát az útvonalproblémától.

Második szakasz: kulcs, amely nem a kulcs, ajánlat, amelyet nem ajánlanak fel

A nem egyező előre megosztott kulcs gyorsan és csendben meghiúsul, és a szokásos változat egy olyan kulcs, amely a képernyőn helyesnek látszik, de beillesztett sortörést vagy a végén szóközt hordoz. Linux-kliensen a párbeszéd nem feltétlenül az igazság forrása: a NetworkManager L2TP-bővítménye a titkokat a /etc/ipsec.d/ alatti fájlokban tartja, és egy régebbi, kapcsolatonkénti fájlt, amelyet a /etc/ipsec.secrets még mindig tartalmaz, az imént beírt fájl helyett fog használni. Másolja azt a fájlt biztonságos helyre, vegye ki a tartalmazási útvonalból, majd írja be újra a kulcsot kézzel.

Ennek a szakasznak a másik fele az ajánlat. Mindkét végnek meg kell egyeznie ugyanabban az 1-es fázisú algoritmuskészletben — titkosítás, integritás és Diffie-Hellman-csoport —, valamint a 2-es fázishoz illő ESP-transzformációkban, különben a társulás egyáltalán nem jön létre. Az az átjáró, amely csak 3DES-t, SHA1-et és MODP1024-et kínál, elutasítja az erősebb algoritmusokra beállított klienst, és a naplója megnevezi az elutasított transzformációt. A napló megnevezi az eltérést, ha elolvassa, ahelyett hogy újraindítaná a szolgáltatást. Ahelyett, hogy algoritmusláncot másolna egy fórumtémából, kérdezze meg az átjárót, mely transzformációkról fog valóban tárgyalni: a címére irányított ike-scan visszaadja azokat a transzformációkat, amelyekről tárgyalni fog. Ha az egyetlen ajánlat olyan kriptográfia, amelyet a házirendje már nem engedélyez, a javítás az átjáróhoz tartozik, nem az ügyfél lefokozásához.

Windows alatt a kulcs és a hitelesítési módszer a VPN-profilban él, és az eltérés a hitelesítő adatok kérése előtt jelentkezik, nem utána. Ahol a fogadó Windows Server, ellenőrizze, hogy a távoli hozzáférés szerepkör telepítve van, hogy a tanúsítvány megfelel annak a névnek, amelyhez a kliensek kapcsolódnak, és hogy egyetlen portszűrő sem szűkebb a fenti protokolloknál.

Harmadik szakasz: az alagút létezik, és a PPP nem indul el

Amikor az IKE befejeződött és a kérés mégsem jelenik meg, nézze az alagút démont, ne a tűzfalat. Az L2TP-nek kell valami, ami az UDP 1701-en figyel — xl2tpd vagy kl2tpd Linuxon, a távoli hozzáférési szolgáltatás Windowson —, és a telepített, de leállított szolgáltatás az ügyfél felől pontosan úgy néz ki, mint egy eldobott csomag. Ellenőrizze a figyelőt, mielőtt újra megnyitná a már ellenőrzött szabályokat. Utána a PPP-nek tárgyalnia kell, és az első LCP-csere az a hely, ahol a csendes meghiúsulás általában landol.

Ennek a szakasznak az egyik csapdája egyáltalán nem hálózati hiba: a Windows egyszerre csak egy kapcsolatot engedélyez egy adott VPN-típusból, ezért a második kísérlet a 937-es hibát adja vissza, „egy másik ilyen típusú kapcsolat használatban van”. Ez helyi szabály, és a megkerülése másik eszköz, másik alagúttípus vagy a már létező egyetlen kapcsolat megosztása.

Olvassa a naplót szakaszsorrendben a találgatás helyett

Állítsa le az ügyfelet, indítsa újra, és olvassa az összetevőket abban a sorrendben, ahogy naplót írnak. Azaz először az IPsec-démon — strongSwan vagy Libreswan, és a ipsec --version megmondja, melyik —, majd az L2TP-démon, majd a pppd. Amelyik összetevő a hiba előtt utoljára írt, az jelöli a vizsgálandó szakaszt, mert minden, ami utána jön a sorrendben, egyáltalán nem futott.

Friss kapcsolattal ellenőrizze, ne mentett munkamenettel, mert a gyorsítótárból újracsatlakozó ügyfél kihagyhatja a csere részeit, és elavult eredményt reprodukálhat. Erősítse meg az elérhetőséget, a kulcscserét, az alagutat és a PPP-t egyenként, ebben a sorrendben. Ekkor a hiányzó kérés megszűnik rejtélynek lenni, és egy ténylegesen végigdolgozható lista második sorává válik. Ez a lista az is, amit a hálózati csapatnak átad, akiktől egyébként azt kérnék, hogy vizsgálják meg a tűzfalat egy olyan hiba miatt, amely egy el nem indított démonban él.