L2TP/IPsec kobler til på ett nettverk og går i timeout på et annet
Samme laptop, samme profil, annet nettverk. Sammenlign IPsec-trinnet, NAT-dybden og hjelperens oppførsel før du tar i påloggingsinformasjonen.
Samme laptop, samme profil og samme passord fungerer i én bygning og feiler i en annen. Den sammenligningen er det mest nyttige beviset i saken, og den er vanligvis det første som blir kastet. Mellom to tilgangsnettverk går utvekslingen gjennom en annen adresseoversettelse, andre filtre og andre ruterhjelpere. Å holde klienten fast og bare bytte nettverk er måten å finne ut hvilke av disse som betyr noe.
Lås klienten før du sammenligner nettverk
Ikke endre noe på enheten før du har en registrering av det fungerende tilfellet: klientversjon, profilinnhold, servernavn og tidspunktet for den vellykkede tilkoblingen. Gjenskap deretter feilen på det andre nettverket i samme økt, slik at klienttilstanden er så identisk som mulig. En profil som redigeres mellom de to forsøkene, ugyldiggjør hele sammenligningen. Målet er én variabel, og den variabelen er nettverket.
Bekreft først vanlig internettilgang på nettverket som feiler, inkludert en gjesteportal hvis det finnes en. En portal som aldri ble oppfylt, gir en timeout som ser nøyaktig ut som en filtrert tunnel, og den kontrollen tar ett minutt.
Fire trinn, fire forskjellige feilmeldinger
En L2TP/IPsec-tilkobling går gjennom fire trinn, og RFC 3193 beskriver ordningen som binder de to første. IKE-forhandlingen er der en filtrert vei gir en stille timeout. IPsec-autentiseringen er der et avvik i sertifikat eller forhåndsdelt nøkkel i stedet gir en eksplisitt avvisning. L2TP-tunneloppsettet er der en allerede etablert sikkerhetsassosiasjon likevel kan føre ingensteds, og PPP-innloggingen er der en feil påloggingsinformasjon til slutt gir en synlig feil. Les loggen for trinnet som stoppet, ikke for den siste linjen som ble skrevet ut.
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-utvekslingen nådde et forslag og om motparten svarte i det hele tatt, noe som skiller tilgjengelighet fra policy. xl2tpd-loggen tar over der IPsec slutter, så en etablert sikkerhetsassosiasjon uten noe i den loggen peker på L2TP-trinnet. Rutespørringen bekrefter at klienten sender mot serveradressen du tror, og fanger opp et utdatert DNS-svar som er arvet fra det forrige nettverket. Til sammen navngir de tre utskriftene et trinn i stedet for et symptom.
Sammenlign NAT-dybde og hjelperens oppførsel
NAT-gjennomtrengning flytter beskyttet trafikk over til UDP-innkapsling når oversettelse oppdages, så portnumrene som bærer en fungerende økt kan avvike fra dem i et statisk diagram. Å tillate én oppsettspakke beviser ingenting om resten av utvekslingen, og en ekstern portskanning kan ikke fortelle deg hvordan motparten behandler gyldig autentisert trafikk. Et andre oversettelseslag endrer bildet igjen, fordi mappingen nå finnes to ganger og utløper etter to forskjellige tidsplaner. Oversettelse på operatørnivå på en mobiltilkobling er den vanlige grunnen til at en fungerende kontorprofil feiler på et telefonhotspot.
Ruterhjelpere varierer like mye som nettverkene. Noe fastvare fanger opp og skriver om utvekslingen, noe slutter bare å forkaste den, og noe bruker bare innstillingen i en eldre modus. Les fastvarens egen beskrivelse av avkrysningsboksen, og der en kompatibilitetsmodus finnes, test den som én bevisst endring i stedet for tre på én gang.
Utgående klient, innkommende server: to forskjellige problemer
En utgående klient og en innkommende server trenger ulik oppstrøms tilgjengelighet, og en gjennomgangsfunksjon som hjelper den første, gjør ingenting for den andre. En hjemmeruter som lar laptopen nå en ekstern gateway, godtar ikke dermed innkommende tilkoblinger til en server bak seg. Å blande de to sender deg på jakt etter portvideresending som aldri var problemet. Oppgi hvilken rolle den feilende enheten har før du sammenligner noe.
Etter en støttet endring, gjenta den samme tilkoblingen og registrer trinnet den nådde. Oppbevar den fungerende profilen og notatet om det feilende nettverket sammen, og ikke tilbakestill påloggingsinformasjon eller installer klienten på nytt, for det kaster beviset sammenligningen var bygget på.