Heeft de Ubuntu-upgrade L2TP/IPsec kapotgemaakt? Vergelijk de IKEv1-voorstellen

De verbinding werkte op donderdag, de upgrade liep op vrijdag, en op maandag draait de client op “connecting” en geeft het op. Dezelfde laptop, dezelfde server, hetzelfde account, dezelfde vooraf gedeelde sleutel. Er is niets in het profiel bewerkt, daarom verspillen de voor de hand liggende verdachten, het wachtwoord en de firewall, je tijd.

Wat is veranderd, is de lijst met transformaties die je machine bereid is aan te bieden. Beide IPsec-stacks die op Ubuntu worden gebruikt, strongSwan en Libreswan, schrappen algoritmen die ze niet langer veilig achten, en de NetworkManager-plug-in ervoor heeft zijn eigen lijst, die volgens een ander schema beweegt. Een server die vastzit op 3DES, SHA1 en een 1024-bits Diffie-Hellman-groep kan uiteindelijk niets horen wat hij accepteert.

Wat de upgrade werkelijk veranderde

Twee lagen voeden het IKEv1-voorstel. De daemon levert een ingebouwde standaardset voorstellen, en de L2TP-plug-in vertrouwt daarop of levert zijn eigen lijst. Vóór NetworkManager-l2tp 1.2.16 vertrouwde de plug-in daarop, dus je voorstel was wat de geïnstalleerde daemon redelijk vond. Vanaf 1.2.16 stuurt de plug-in een gedocumenteerde lijst die op Windows- en Apple-clients is gemodelleerd, en die lijst is breder dan de oude standaard maar bevat niet langer elke oude combinatie vooraan in de wachtrij.

Die splitsing verklaart een faalmodus die mensen verwarrend vinden: twee machines op dezelfde Ubuntu-versie kunnen zich anders gedragen omdat de ene het distributiepakket heeft en de andere een backport, en de daemonversie op beide ziet er in een bugrapport identiek uit. Controleer de plug-inversie, niet alleen de daemonversie, voordat je concludeert dat de upgrade niets relevants heeft veranderd.

Er is een kleinere valkuil in hetzelfde gebied. De twee daemons schrijven de Diffie-Hellman-groepen van de elliptische kromme anders, de ene schrijft ecp384 en de andere ecp_384. Plak de verkeerde spelling in de Advanced-dialoog en de daemon weigert de instelling als niet-parseerbaar, wat in de log verschijnt als een onderhandelingsprobleem en niet als een typefout in de configuratie.

Lees de fout voordat je iets verandert

Begin met welke backend je draait, want het antwoord bepaalt zowel de syntaxis als de locatie van de log.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Lees daarna de uitwisseling zelf. Op strongSwan schrijft de daemon naar de journal op een huidige release en naar /var/log/syslog op een oudere, en het interessante deel is het voorstel dat hij stuurt, niet de laatste regel. Je zoekt naar formuleringen over geen passend voorstel, wat een algoritmeprobleem is; een authenticatiefout, die op de sleutel of het account wijst; of een gewone timeout, die op bereikbaarheid wijst.

Deze drie uitkomsten worden veel te vaak als één symptoom behandeld. Een timeout met een lege daemonlog betekent dat de pakketten niet aankomen. Een afwijzing van het voorstel betekent dat ze aankwamen en werden geweigerd. Als je log stil is, verhoog dan het debugniveau van de plug-in voor één poging en verlaag het daarna, want de uitgebreide uitvoer vult een journal snel.

Fase 1 en fase 2 zijn aparte weddenschappen

IKEv1 onderhandelt twee keer. De hoofdmodus bouwt de IKE-beveiligingsassociatie op uit een versleutelingsalgoritme, een integriteitsalgoritme, een Diffie-Hellman-groep en een authenticatiemethode. De snelle modus bouwt daarna de ESP-associatie die L2TP gaat dragen. Een server mag de eerste accepteren en de tweede weigeren, dus een half correct profiel faalt later dan je verwacht en lijkt op een andere bug.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

Het uitroepteken is strongSwan-syntaxis voor een strikte vermelding: bied deze ene combinatie aan en niets anders. Zonder dat sluit de vermelding zich aan bij een terugvallijst, wat goed is wanneer de peer modern is en contraproductief wanneer het een apparaat met één hardgecodeerd beleid is. Beschouw het paar hierboven als een illustratie van de vorm, niet als een aanbeveling voor iets wat je vandaag bouwt.

Wijzig één veld en herhaal dan de test

Op een huidige plug-in is de snelste eerste test beide voorstelvelden volledig leegmaken en opnieuw verbinden, want de meegeleverde standaardlijst bevat al de gangbare Windows- en Apple-combinaties. Op een oudere plug-in geeft het leegmaken de controle terug aan een daemon die het algoritme waarop je server aandringt misschien heeft laten vallen, en de fout wordt erger.

Als leegmaken niet helpt, stel dan het strikte paar in dat je server documenteert, één fase per keer. Wijzig fase 1, verbind opnieuw en lees de log voordat je fase 2 aanraakt. Als een combinatie eindelijk werkt, schrijf die dan op naast het servermodel en de plug-inversie, want de standaarden zullen weer verschuiven en die notitie is wat de volgende upgrade een controle van vijf minuten maakt.