Gick Ubuntu-uppgraderingen sönder L2TP/IPsec? Jämför IKEv1-förslagen

Anslutningen fungerade i torsdags, uppgraderingen kördes i fredags, och på måndagen snurrar klienten på “connecting” och ger upp. Samma laptop, samma server, samma konto, samma i förväg delade nyckel. Ingenting i profilen redigerades, och därför slösar de uppenbara misstänkta, lösenordet och brandväggen, bort din tid.

Det som ändrades är listan över transformationer som din maskin är villig att erbjuda. Båda IPsec-stackarna som används på Ubuntu, strongSwan och Libreswan, rensar bort algoritmer som de inte längre anser säkra, och NetworkManager-pluginen framför dem har sin egen lista, som rör sig enligt ett annat schema. En server låst till 3DES, SHA1 och en 1024-bitars Diffie-Hellman-grupp kan till slut inte höra något den accepterar.

Vad uppgraderingen faktiskt ändrade

Två lager matar IKEv1-förslaget. Daemonen levererar en inbyggd standarduppsättning förslag, och L2TP-pluginen antingen förlitar sig på den eller levererar sin egen lista. Före NetworkManager-l2tp 1.2.16 förlitade sig pluginen på den, så ditt förslag var vad den installerade daemonen ansåg rimligt. Från 1.2.16 skickar pluginen en dokumenterad lista modellerad efter Windows- och Apple-klienter, och den listan är bredare än den gamla standarden men innehåller inte längre varje äldre kombination först i kön.

Den uppdelningen förklarar ett felläge som folk finner förvirrande: två maskiner på samma Ubuntu-utgåva kan bete sig olika eftersom den ena har distributionspaketet och den andra har en backport, och daemonversionen på båda ser identisk ut i en felrapport. Kontrollera pluginversionen, inte bara daemonversionen, innan du drar slutsatsen att uppgraderingen inte ändrade något relevant.

Det finns en mindre fälla i samma område. De två daemonerna skriver de elliptiska-kurva Diffie-Hellman-grupperna olika, den ena skriver ecp384 och den andra ecp_384. Klistra in den felaktiga stavningen i Advanced-dialogen och daemonen avvisar inställningen som oparsbar, vilket i loggen framstår som ett förhandlingsproblem och inte som ett skrivfel i konfigurationen.

Läs felet innan du ändrar något

Börja med vilken backend du kör, eftersom svaret avgör både syntaxen och loggens placering.

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

Läs sedan själva utbytet. På strongSwan skriver daemonen till journalen på en aktuell utgåva och till /var/log/syslog på en äldre, och det intressanta är förslaget den skickar, inte sista raden. Du letar efter formuleringar om inget matchande förslag, vilket är ett algoritmproblem; ett autentiseringsfel, som pekar på nyckeln eller kontot; eller en vanlig timeout, som pekar på nåbarhet.

Dessa tre utfall behandlas alldeles för ofta som ett enda symptom. En timeout med tom daemonlogg betyder att paketen inte anländer. En avvisning av förslaget betyder att de anlände och avvisades. Om din logg är tyst, höj pluginens felsökningsnivå för ett försök och sänk den efteråt, eftersom den detaljerade utskriften snabbt fyller en journal.

Fas 1 och fas 2 är separata vad

IKEv1 förhandlar två gånger. Huvudläget bygger IKE-säkerhetsassociationen från en krypteringsalgoritm, en integritetsalgoritm, en Diffie-Hellman-grupp och en autentiseringsmetod. Snabbläget bygger sedan ESP-associationen som ska bära L2TP. En server står fri att acceptera den första och avvisa den andra, så en halvkorrekt profil misslyckas senare än du väntar och ser ut som en annan bugg.

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

Utropstecknet är strongSwan-syntax för en strikt post: erbjud just denna kombination och inget annat. Utan det ansluter posten till en reservlista, vilket är bra när motparten är modern och kontraproduktivt när den är en enhet med en enda hårdkodad policy. Betrakta paret ovan som en illustration av formen, inte som en rekommendation för något du bygger i dag.

Ändra ett fält och upprepa sedan testet

På en aktuell plugin är det snabbaste första testet att tömma båda förslagsfälten helt och ansluta igen, eftersom den medföljande standardlistan redan innehåller de vanliga Windows- och Apple-kombinationerna. På en äldre plugin ger tömningen kontrollen tillbaka till en daemon som kanske har tappat algoritmen som din server insisterar på, och felet blir värre.

Om tömningen inte hjälper, ställ in det strikta paret som din server dokumenterar, en fas i taget. Ändra fas 1, anslut igen och läs loggen innan du rör fas 2. När en kombination äntligen fungerar, skriv ner den bredvid servermodellen och pluginversionen, eftersom standarderna kommer att flytta sig igen och den anteckningen är det som gör nästa uppgradering till en femminuterskontroll.