L2TP/IPsec virker på ét netværk og går i stå på et andet
Samme laptop, samme profil, forskelligt netværk. Sammenlign IPsec-fasen, NAT-dybden og hjælperens opførsel, før du rører ved logindoplysningerne.
Den samme laptop, den samme profil og den samme adgangskode virker i én bygning og fejler i en anden. Den sammenligning er det mest nyttige bevis i sagen, og det er normalt det første, der bliver smidt væk. Mellem to adgangsnetværk går udvekslingen gennem forskellig adresseoversættelse, forskellige filtre og forskellige routerhjælpere. At holde klienten fast og kun skifte netværk er måden at finde ud af, hvilke af dem der betyder noget.
Fastlæg klienten, før du sammenligner netværk
Ret ikke noget på enheden, før du har en registrering af det fungerende tilfælde: klientversion, profilindhold, servernavn og tidspunktet for den vellykkede forbindelse. Genskab derefter fejlen på det andet netværk i samme session, så klienttilstanden er så identisk som muligt. En profil, der redigeres mellem de to forsøg, gør hele sammenligningen ugyldig. Målet er én variabel, og den variabel er netværket.
Bekræft først almindelig internetadgang på det fejlende netværk, inklusive en gæsteportal, hvis der er en. En portal, der aldrig blev opfyldt, giver en timeout, der ligner en filtreret tunnel præcis, og den kontrol tager et minut.
Fire faser, fire forskellige fejlmeddelelser
En L2TP/IPsec-forbindelse gennemgår fire faser, og RFC 3193 beskriver den ordning, der binder de to første. IKE-forhandlingen er der, hvor en filtreret vej giver en stille timeout. IPsec-godkendelsen er der, hvor en uoverensstemmelse i certifikat eller forudelt nøgle i stedet giver en eksplicit afvisning. L2TP-tunnelopsætningen er der, hvor en etableret sikkerhedsassociation stadig kan føre ingen steder hen, og PPP-logind er der, hvor en forkert adgangskode endelig giver en synlig fejl. Læs loggen for den fase, der stoppede, ikke for den sidste linje, den udskrev.
journalctl -u strongswan --since '-5 min' | tail -20
journalctl -u xl2tpd --since '-5 min' | tail -20
ip -4 route get 198.51.100.10
strongSwan-loggen viser, om IKE-udvekslingen nåede et forslag, og om peeren overhovedet svarede, hvilket adskiller tilgængelighed fra politik. xl2tpd-loggen tager over, hvor IPsec slutter, så en etableret sikkerhedsassociation uden noget i den log peger på L2TP-fasen. Ruteudførselen bekræfter, at klienten sender mod den serveradresse, du tror, det er, hvilket fanger et forældet DNS-svar arvet fra det forrige netværk. Tilsammen navngiver de tre uddata en fase i stedet for et symptom.
Sammenlign NAT-dybde og hjælperens opførsel
NAT-gennemføring flytter beskyttet trafik over på UDP-indkapsling, når oversættelse registreres, så de portnumre, der bærer en fungerende session, kan afvige fra dem i et statisk diagram. At tillade én opsætningspakke beviser intet om resten af udvekslingen, og en ekstern portscanning kan ikke fortælle dig, hvordan peeren behandler gyldig godkendt trafik. Et andet lag oversættelse ændrer billedet igen, fordi tilknytningen nu findes to gange og udløber efter to forskellige tidsplaner. Oversættelse på operatørniveau på en mobilforbindelse er den sædvanlige grund til, at en fungerende kontorprofil fejler på et telefonhotspot.
Routerhjælpere varierer lige så meget som netværkene. Nogle firmwareversioner opsnapper og omskriver udvekslingen, nogle holder blot op med at droppe den, og nogle anvender kun indstillingen i en ældre tilstand. Læs firmwarens egen beskrivelse af afkrydsningsfeltet, og hvor en kompatibilitetstilstand findes, test den som én bevidst ændring i stedet for tre på én gang.
Udgående klient, indgående server: to forskellige problemer
En udgående klient og en indgående server har brug for forskellig opstrøms tilgængelighed, og en gennemløbsfunktion, der hjælper den første, gør intet for den anden. En hjemmerouter, der lader laptops nå en fjern gateway, accepterer ikke derved indgående forbindelser til en server bag den. At forveksle de to sender dig på jagt efter portvideresendelse, som aldrig var problemet. Angiv, hvilken rolle den fejlende enhed har, før du sammenligner noget.
Gentag efter en understøttet ændring den samme forbindelse, og registrer den fase, den nåede. Opbevar den fungerende profil og noten om det fejlende netværk sammen, og nulstil ikke logindoplysninger og geninstaller ikke klienten, for det kasserer det bevis, sammenligningen var bygget på.