L2TP: dödligt signal 15, NO_PROPOSAL_CHOSEN och saknad modp1024

Anslutningen hänger sig, klienten avslutas och den sista raden på skärmen är death_handler: Fatal signal 15 received. Den raden rapporterar ett avbrott, inte en orsak. En rad högre upp i IPsec-loggen finns nästan alltid NO_PROPOSAL_CHOSEN, och paret pekar mot fas 2 i utbytet, där parterna jämför val av kryptering och hash och stannar när de inte har något gemensamt. Inloggningsuppgifterna har inte skickats i det läget, så att skriva lösenordet igen kan inte ändra resultatet.

Vanligtvis tömmer två saker den skärningen på en Linux-klient. Den lokala daemonen kanske inte längre implementerar den Diffie-Hellman-grupp som profilen begär, eller så bär profilen ett fas 1-förslag i ett fas 2-fält. Båda lämnar spår i loggen, och ingen av dem är ett kontoproblem.

Vad de två meddelandena egentligen säger

IKE förhandlar i omgångar. Fas 1 bygger en skyddad kanal och väljer egna algoritmer; fas 2, barn-SA, bär trafik under en separat uppsättning. NO_PROPOSAL_CHOSEN är det meddelande som en svarare returnerar när ingen av de erbjudna kombinationerna är acceptabel, och det visas som [ HASH N(NO_PROP) ] inuti ett INFORMATIONAL-utbyte.

Signal 15 är en annan händelse: något bad den lokala processen att stoppa och hanteraren loggade det. När båda raderna visas tillsammans är ordningen kausal, först avvisning och sedan avstängning.

Läs förhandlingen innan du rör inloggningsuppgifterna

Höj loggnivån där daemonen skriver och återanslut sedan medan du följer utdata. På en NetworkManager-värd skickar L2TP-insticksmodulen vidare den nivån till backend, och meddelandena hamnar i journalen eller i den klassiska syslog-filen beroende på distribution. Vilken som helst av dessa visar utbytet: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' eller tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

En rad som nämner pluto kommer från libreswan, charon från strongSwan, och båda beskriver samma tillstånd med olika ord. Den form som är värd att leta efter är den som namnger den saknade gruppen, till exempel algorithm 'modp1024' is not supported, eftersom den gör ett vagt fel till ett konkret.

Vart modp1024 tog vägen

Diffie-Hellman-grupp 2 är svag nog för att flera distributioner slutade kompilera in den i libreswan från 3.30 och framåt. Då ber en profil som skrevs för år sedan, eller hämtades från en gateway-guide som bara listar aes128-sha1-modp1024, den lokala daemonen om något den inte alls klarar av. Nyare NetworkManager-l2tp-byggen gör det utfallet mer sannolikt: från 1.2.16 ersätter de uppsättningen med förslag i Windows 10- och iOS-stil och släpper modp1024 så snart libreswan upptäcks. Den andra sidan är ofta oskyldig och erbjuder fortfarande exakt den grupp du konfigurerade.

Det är den asymmetrin som får felet att kännas slumpmässigt. En äldre klient ansluter, samma profil på en uppdaterad bärbar dator gör det inte, och serverkonfigurationen har aldrig flyttats. Skadan görs av versionsdrift.

Två reparationer med olika omfattning

Den billiga reparationen är att sluta hårdkoda algoritmer. Töm båda förslagsfälten i redigeraren och låt insticksmodulen välja en uppsättning som den andra sidan accepterar; om gatewayen stöder moderna grupper slutförs förhandlingen utan mer arbete.

Den andra reparationen håller en gammal gateway nåbar genom att installera strongSwan, vars paket fortfarande implementerar grupp 2 på de flesta distributioner. Det är ett daemonbyte, så det kostar något: kontrollera om andra tunnlar på värden är beroende av libreswan-konfigurationen innan du tar bort den, och räkna med SELinux-avslag mellan NetworkManager och strongSwan-insticksmodulen på Fedora. De avslagen dyker upp i granskningsloggen och inte i IKE-spåret, vilket är varför en tunnel kan se trasig ut direkt efter en lyckad installation. Den ordning som fungerar är först dnf install strongswan, sedan rpm -e libreswan.

Förslagssträngar som passar, och fällorna runt dem

När fälten måste fyllas i för hand tar fas 1 och fas 2 olika värden. Ett par som är känt för att fungera mot en motpart i Meraki-stil erbjuder aes128-sha1-modp1024 i fas 1 med 3des-sha1-modp1024 bakom, båda stängda av ett utropstecken som gör uppsättningen strikt, så att bara dessa förslag skickas.

Fas 2 snävas sedan in till aes128-sha1 och 3des-sha1 med samma strikta markering och utan något Diffie-Hellman-suffix alls. En fas 2-rad med -modp1024 är ett fas 1-värde i fel fält, och svararen avvisar den vid varje nytt försök. Kopiera den raden till en andra profil och den andra profilen misslyckas på samma sätt, och så blir ett skrivfel en incident för hela flottan.

Andra fel bär samma popup utan att vara förslagsmissmatchningar. I KDE kan L2TP-typen listas med insticksmodulen installerad medan varje anslutning dör direkt, eftersom anslutningsredigeraren och körtidshjälparna levereras som separata paket. Huvudlösa värdar kan återanvända en profil från ett fungerande skrivbord: kopiera den från /etc/NetworkManager/system-connections/, sätt läget till 600 och kör sedan nmcli con reload. Ta upp den med nmcli con up id work-l2tp, eftersom den nakna formen vill ha ett UUID, och ta bort varje inaktuell ifname-post, annars svarar hanteraren Could not find source connection medan allt annat är korrekt.

En i förväg delad nyckel kan lagras som klartext eller som 0s följt av base64; båda formerna fungerar, men värdet måste stämma med gatewayen byte för byte, inklusive de avslutande blanksteg du kopierade med den.