Az L2TP/IPsec az egyik hálózaton csatlakozik, a másikon időtúllépést kap
Ugyanaz a laptop, ugyanaz a profil, másik hálózat. Hasonlítsa össze az IPsec-szakaszt, a NAT mélységét és a segéd viselkedését, mielőtt a hitelesítő adatokhoz nyúlna.
Ugyanaz a laptop, ugyanaz a profil és ugyanaz a jelszó működik az egyik épületben, és elbukik a másikban. Ez az összehasonlítás a jegy legfontosabb bizonyítéka, és általában ez az első dolog, amit eldobnak. Két hozzáférési hálózat között a csere más címfordításon, más szűrőkön és más router-segédeken megy keresztül. A kliens változatlanul hagyása és csak a hálózat cseréje az a mód, ahogy kiderítheti, melyik számít ezek közül.
Rögzítse a klienst, mielőtt hálózatokat hasonlít össze
Ne változtasson semmit az eszközön, amíg nincs feljegyzése a működő esetről: kliensverzió, profil tartalma, szerver neve és a sikeres kapcsolat ideje. Ezután reprodukálja a hibát a második hálózaton ugyanabban a munkamenetben, hogy a kliens állapota a lehető leginkább azonos legyen. A két kísérlet között szerkesztett profil érvényteleníti az egész összehasonlítást. A cél egyetlen változó, és ez a változó a hálózat.
Először igazolja a szokásos internetelérést a hibás hálózaton, beleértve a vendégportált is, ha van. Egy soha nem teljesített portál olyan időtúllépést eredményez, amely pontosan úgy néz ki, mint egy szűrt alagút, és ez az ellenőrzés egy percet vesz igénybe.
Négy szakasz, négy különböző hibaüzenet
Egy L2TP/IPsec kapcsolat négy szakaszon megy keresztül, és RFC 3193 írja le azt az elrendezést, amely az első kettőt összeköti. Az IKE-tárgyalás az a hely, ahol egy szűrt útvonal csendes időtúllépést okoz. Az IPsec-hitelesítés az a hely, ahol a tanúsítvány vagy az előre megosztott kulcs eltérése helyette kifejezett elutasítást okoz. Az L2TP-alagút beállítása az a hely, ahol egy már létrehozott biztonsági társulás mégis zsákutcába futhat, a PPP-bejelentkezés pedig az a hely, ahol egy rossz hitelesítő adat végül látható hibát okoz. A naplót a megállt szakaszhoz olvassa, ne az utolsó kiírt sorhoz.
journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10
A strongSwan naplója megmutatja, hogy az IKE-csere elért-e egy javaslatot, és hogy a partner egyáltalán válaszolt-e, ami elválasztja az elérhetőséget a szabályzattól. Az xl2tpd naplója ott folytatódik, ahol az IPsec véget ér, így egy létrehozott biztonsági társulás, amelyről semmi sincs ebben a naplóban, az L2TP-szakaszra mutat. Az útvonal-lekérdezés megerősíti, hogy a kliens arra a szervercímre küld, amelyet Ön feltételez, és ezzel elkap egy korábbi hálózatból örökölt elavult DNS-választ. Együtt a három kimenet szakaszt nevez meg, nem tünetet.
Hasonlítsa össze a NAT mélységét és a segéd viselkedését
A NAT-átjárás a védett forgalmat UDP-burkolásba helyezi amikor a fordítást észleli, ezért a működő munkamenetet hordozó portszámok eltérhetnek a statikus ábrán szereplőktől. Egyetlen beállítási csomag engedélyezése semmit sem bizonyít a csere többi részéről, és egy külső portvizsgálat nem tudja megmondani, hogyan kezeli a partner az érvényes hitelesített forgalmat. Egy második fordítási réteg ismét megváltoztatja a képet, mert a leképezés most kétszer létezik, és két különböző ütemezés szerint jár le. Az operátori szintű fordítás mobilkapcsolaton a szokásos oka annak, hogy egy működő irodai profil elbukik egy telefonos hotspoton.
A router-segédek ugyanannyira különböznek, mint a hálózatok. Egyes firmware-ek elfogják és átírják a cserét, mások csak abbahagyják annak eldobását, és megint mások csak egy régebbi módban alkalmazzák a beállítást. Olvassa el a firmware saját leírását a jelölőnégyzetről, és ahol létezik kompatibilitási mód, egyetlen szándékos változtatásként tesztelje, ne háromként egyszerre.
Kimenő kliens, bejövő szerver: két különböző probléma
A kimenő kliensnek és a bejövő szervernek más felső irányú elérhetőségre van szüksége, és az átjárófunkció, amely az elsőnek segít, semmit sem tesz a másodikért. Az otthoni router, amely engedi a laptopot egy távoli átjáró eléréséhez, ezáltal nem fogad bejövő kapcsolatokat a mögötte lévő szerverhez. A kettő összekeverése olyan porttovábbítás keresésére küldi, amely soha nem volt a probléma. Mielőtt bármit összehasonlít, mondja meg, milyen szerepe van a hibás eszköznek.
Egy támogatott módosítás után ismételje meg ugyanazt a kapcsolatot, és jegyezze fel az elért szakaszt. Tartsa együtt a működő profilt és a hibás hálózatról szóló feljegyzést, és ne állítsa vissza a hitelesítő adatokat, és ne telepítse újra a klienst, mert az eldobja a bizonyítékot, amelyre az összehasonlítás épült.