Hvorfor stopper PPTP og L2TP/IPsec før spørsmålet om brukernavn?

Manglende spørsmål om brukernavn er en diagnostisk gave: PPP har ikke startet ennå, så kontoen, passordet og domenepolicyen er ikke spurt ennå. I en PPTP- eller L2TP/IPsec-forbindelse ber klienten om påloggingsinformasjon først når tunnelen finnes og serveren har startet en PPP-økt. Alt som kan svikte før det øyeblikket, er transport, nøkkelutveksling eller tunneloppsett, som er et langt mindre område enn «VPN-en er ødelagt».

Et manglende spørsmål begrenser feilen til tre trinn

Skriv ned det siste trinnet som synlig lyktes, for hvert av dem har en annen eier og en annen løsning. Å gjette på kontoinnstillingene mens du sitter fast to trinn tidligere, er hvordan en ettermiddag forsvinner.

En klient som timer ut uten spørsmål, fikk aldri en IPsec-tilknytning, så feilen ligger i IKE eller i om pakkene dine når frem til gatewayen i det hele tatt. Den som melder at den verifiserer påloggingsinformasjon og deretter faller, kom lenger enn meldingen antyder. Et spørsmål som følges av en avvisning, er PPP-autentisering, og det hører hjemme i en kontoartikkel, ikke i denne.

Trinn én: protokollen en brannmur lydløst dropper

PPTP trenger TCP 1723 for kontrollkanalen og IP-protokoll 47 for databanen, og de to reiser hver for seg. Mange nett videresender 1723 og dropper protokoll 47, noe som gir en tunnel som forhandler og deretter ikke bærer noe som helst. En ruter som gjør NAT trenger også en GRE-kapabel gjennomføring, og en tilgangsvei kun over IPv6 kan ikke bære PPTP under noen konfigurasjon.

L2TP over IPsec bruker port 500 til IKE og port 4500 til NAT-gjennomgang, pakker deretter selve L2TP-trafikken inn i 1701, mens ESP bærer den beskyttede lasten når tilknytningen finnes. Tillat de to kontrollportene, men ikke ESP, og du får nøyaktig symptomet i tittelen: synlig fremgang, deretter en død klient før noen påloggingsdialog. Å teste fra et telefonhotspot er en billig måte å skille et klientproblem fra et veiproblem.

Trinn to: en nøkkel som ikke er nøkkelen, et forslag som ikke tilbys

En forhåndsdelt nøkkel som ikke stemmer, feiler raskt og lydløst, og den vanlige versjonen er en nøkkel som ser riktig ut på skjermen, men bærer et innlimt linjeskift eller et mellomrom på slutten. På en Linux-klient er ikke dialogen nødvendigvis kilden til sannhet: NetworkManager sin L2TP-plugin oppbevarer hemmeligheter i filer under /etc/ipsec.d/, og en eldre fil per tilkobling som /etc/ipsec.secrets fortsatt inkluderer, brukes i stedet for den du nettopp skrev inn. Kopier den filen til et trygt sted, ta den ut av inkluderingsstien, og skriv deretter nøkkelen på nytt for hånd.

Den andre halvdelen av dette trinnet er forslaget. Begge ender må bli enige om det samme algoritmesettet for fase 1 — kryptering, integritet og Diffie-Hellman-gruppe — og om samsvarende ESP-transformasjoner for fase 2, ellers dannes ikke tilknytningen i det hele tatt. En gateway som bare tilbyr 3DES, SHA1 og MODP1024, vil avvise en klient satt opp for sterkere algoritmer, og loggen navngir transformasjonen som ble avvist. Loggen navngir misforholdet hvis du leser den i stedet for å starte tjenesten på nytt igjen. I stedet for å kopiere en algoritmestreng fra en forumtråd, spør gatewayen hvilke transformasjoner den faktisk vil forhandle om: ike-scan rettet mot adressen returnerer transformasjonene den vil forhandle om. Hvis det eneste tilbudet er kryptografi som retningslinjene dine ikke lenger tillater, hører rettelsen hjemme på gatewayen, ikke i en nedgradering av klienten.

I Windows ligger nøkkelen og autentiseringsmetoden i VPN-profilen, og et misforhold viser seg før påloggingsspørsmålet snarere enn etter. Der mottakeren er en Windows Server, må du bekrefte at fjernaksessrollen er installert, at sertifikatet samsvarer med navnet klientene kobler til, og at ingen portfilter er smalere enn protokollene ovenfor.

Trinn tre: tunnelen finnes og PPP starter aldri

Når IKE er fullført og spørsmålet fortsatt aldri dukker opp, se på tunneldaemonen i stedet for brannmuren. L2TP trenger noe som lytter på UDP 1701 — xl2tpd eller kl2tpd på Linux, fjernaksesstjenesten på Windows — og en tjeneste som er installert men stoppet, ser fra klientsiden ut som en droppet pakke. Sjekk lytteren før du åpner regler du allerede har verifisert på nytt. Deretter må PPP forhandle, og den første LCP-utvekslingen er der en stille feil vanligvis lander.

En felle i dette trinnet er ikke en nettverksfeil i det hele tatt: Windows tillater bare én tilkobling av en gitt VPN-type om gangen, så et andre forsøk returnerer feil 937, «en annen tilkobling av denne typen er i bruk». Det er en lokal regel, og veien utenom er en annen enhet, en annen tunneltype eller å dele den ene tilkoblingen som allerede finnes.

Les loggen i trinnrekkefølge i stedet for å gjette

Stopp klienten, start den på nytt, og les komponentene i den rekkefølgen de logger. Det betyr først IPsec-daemonen — strongSwan eller Libreswan, og ipsec --version forteller deg hvilken — deretter L2TP-daemonen, deretter pppd. Hvilken komponent som helst som skrev sist før feilen, markerer trinnet som skal undersøkes, for alt som kommer etter den i sekvensen kjørte ikke i det hele tatt.

Verifiser med en fersk tilkobling i stedet for en lagret økt, fordi en klient som kobler til på nytt fra hurtigbufferen, kan hoppe over deler av utvekslingen og gjenskape et utdatert resultat. Bekreft rekkevidde, nøkkelutveksling, tunnel og PPP ett om gangen, i den rekkefølgen. Da slutter det manglende spørsmålet å være et mysterium og blir den andre linjen i en liste du faktisk kan arbeide deg gjennom. Den listen er også det du gir til nettverksteamet, som ellers ville bli bedt om å sjekke brannmuren for en feil som bor i en daemon som ikke er startet.