Waarom stoppen PPTP en L2TP/IPsec voordat om de gebruikersnaam wordt gevraagd?

Geen vraag om de gebruikersnaam is een diagnostisch geschenk: PPP is nog niet gestart, dus het account, het wachtwoord en het domeinbeleid zijn nog niet geraadpleegd. Bij een PPTP- of L2TP/IPsec-verbinding vraagt de client pas om inloggegevens nadat de tunnel bestaat en de server een PPP-sessie is begonnen. Alles wat vóór dat moment kan mislukken, is transport, sleuteluitwisseling of tunnelopbouw, een veel kleiner oppervlak dan „de VPN is stuk”.

Een ontbrekende vraag beperkt de fout tot drie fasen

Noteer de laatste fase die zichtbaar is geslaagd, want elke fase heeft een andere eigenaar en een andere oplossing. Gokken op de accountinstellingen terwijl u twee fasen eerder vastzit, is hoe een middag verdwijnt.

Een client die zonder vraag een time-out krijgt, heeft nooit een IPsec-associatie gekregen, dus de fout zit in IKE of in de vraag of uw pakketten de gateway überhaupt bereiken. Een client die meldt dat hij inloggegevens verifieert en daarna wegvalt, kwam verder dan het bericht suggereert. Een vraag gevolgd door een afwijzing is PPP-authenticatie, en dat hoort in een accountartikel, niet in dit artikel.

Fase één: het protocol dat een firewall stil laat vallen

PPTP heeft TCP 1723 nodig voor zijn controlekanaal en IP-protocol 47 voor het datapad, en die twee reizen apart. Veel netwerken sturen 1723 door en laten protocol 47 vallen, wat een tunnel oplevert die onderhandelt en daarna helemaal niets vervoert. Een router die NAT doet, heeft ook een GRE-geschikte doorvoer nodig, en een toegangsweg met alleen IPv6 kan PPTP in geen enkele configuratie vervoeren.

L2TP over IPsec verbruikt poort 500 voor IKE en poort 4500 voor NAT-traversal, verpakt daarna het L2TP-verkeer zelf in 1701, terwijl ESP de beschermde lading draagt zodra de associatie bestaat. Sta de twee controlepoorten toe maar niet ESP, en u krijgt precies het symptoom uit de titel: zichtbare voortgang, dan een dode client vóór enige inlogdialoog. Testen vanaf een telefoonhotspot is een goedkope manier om een clientprobleem van een wegprobleem te scheiden.

Fase twee: een sleutel die niet de sleutel is, een voorstel dat niet wordt aangeboden

Een niet-overeenkomende vooraf gedeelde sleutel mislukt snel en stil, en de gebruikelijke versie is een sleutel die er op het scherm goed uitziet maar een geplakte regelafbreking of een spatie aan het eind bevat. Op een Linux-client is de dialoog niet per se de bron van waarheid: de L2TP-plugin van NetworkManager bewaart geheimen in bestanden onder /etc/ipsec.d/, en een ouder bestand per verbinding dat /etc/ipsec.secrets nog steeds opneemt, wordt gebruikt in plaats van het bestand dat u zojuist hebt getypt. Kopieer dat bestand naar een veilige plek, haal het uit het inclusiepad en typ de sleutel daarna opnieuw met de hand.

De andere helft van deze fase is het voorstel. Beide kanten moeten het eens worden over dezelfde fase 1-algoritmeset — versleuteling, integriteit en Diffie-Hellman-groep — en over passende ESP-transformaties voor fase 2, anders komt de associatie helemaal niet tot stand. Een gateway die alleen 3DES, SHA1 en MODP1024 aanbiedt, weigert een client die voor sterkere algoritmen is ingesteld, en zijn log noemt de geweigerde transformatie. Het log noemt de mismatch als u het leest in plaats van de dienst opnieuw te starten. In plaats van een algoritmereeks uit een forumtopic te kopiëren, vraagt u de gateway welke transformaties hij werkelijk zal onderhandelen: ike-scan gericht op zijn adres geeft de transformaties terug die hij zal onderhandelen. Als het enige aanbod cryptografie is die uw beleid niet meer toestaat, hoort de oplossing bij de gateway en niet bij een downgrade van de client.

Op Windows staan de sleutel en de authenticatiemethode in het VPN-profiel, en een mismatch komt vóór de inlogvraag naar boven in plaats van erna. Waar de ontvanger een Windows Server is, controleert u of de rol voor externe toegang is geïnstalleerd, of het certificaat overeenkomt met de naam waarmee clients verbinden, en of geen enkel poortfilter smaller is dan de protocollen hierboven.

Fase drie: de tunnel bestaat en PPP start nooit

Wanneer IKE is voltooid en de vraag toch nooit verschijnt, kijk dan naar de tunneldaemon in plaats van de firewall. L2TP heeft iets nodig dat op UDP 1701 luistert — xl2tpd of kl2tpd op Linux, de dienst voor externe toegang op Windows — en een dienst die is geïnstalleerd maar gestopt, ziet er vanaf de clientkant precies zo uit als een weggevallen pakket. Controleer de listener voordat u regels opnieuw opent die u al hebt geverifieerd. Daarna moet PPP onderhandelen, en de eerste LCP-uitwisseling is waar een stille fout meestal landt.

Een valkuil in deze fase is helemaal geen netwerkfout: Windows staat maar één verbinding van een bepaald VPN-type tegelijk toe, dus een tweede poging geeft fout 937, „een andere verbinding van dit type is in gebruik”. Dat is een lokale regel, en de manier eromheen is een ander apparaat, een ander tunneltype of het delen van de ene verbinding die al bestaat.

Lees het log in fasevolgorde in plaats van te gokken

Stop de client, start hem opnieuw en lees de componenten in de volgorde waarin ze loggen. Dat betekent eerst de IPsec-daemon — strongSwan of Libreswan, en ipsec --version vertelt u welke — dan de L2TP-daemon, dan pppd. Welk component het laatst schreef vóór de fout, markeert de fase die moet worden onderzocht, want alles wat daarna in de reeks komt, draaide helemaal niet.

Verifieer met een verse verbinding in plaats van een opgeslagen sessie, want een client die opnieuw verbindt vanuit de cache kan delen van de uitwisseling overslaan en een verouderd resultaat reproduceren. Bevestig bereik, sleuteluitwisseling, tunnel en PPP één voor één, in die volgorde. Dan houdt de ontbrekende vraag op een raadsel te zijn en wordt het de tweede regel van een lijst die u echt kunt doorwerken. Die lijst is ook wat u aan het netwerkteam geeft, dat anders zou worden gevraagd de firewall te controleren op een fout die in een niet-gestarte daemon zit.