L2TP: fatal signal 15, NO_PROPOSAL_CHOSEN og manglende modp1024

Din forbindelse hænger, klienten afslutter, og den sidste linje på skærmen er death_handler: Fatal signal 15 received. Den linje melder en afbrydelse, ikke en årsag. En linje tidligere i IPsec-loggen står der næsten altid NO_PROPOSAL_CHOSEN, og parret peger på fase 2 af udvekslingen, hvor parterne sammenligner valg af kryptering og hash og stopper, når de ikke deler nogen. Loginoplysningerne er ikke sendt på det tidspunkt, så en ny indtastning af adgangskoden kan ikke ændre resultatet.

To ting tømmer normalt det snit på en Linux-klient. Den lokale daemon implementerer måske ikke længere den Diffie-Hellman-gruppe, som profilen beder om, eller profilen bærer et fase 1-forslag i et fase 2-felt. Begge efterlader spor i loggen, og ingen af dem er et kontoproblem.

Hvad de to beskeder egentlig siger

IKE forhandler i gennemløb. Fase 1 bygger en beskyttet kanal og vælger sine egne algoritmer; fase 2, child-SA'en, bærer trafik under et separat sæt. NO_PROPOSAL_CHOSEN er den notifikation, som en responder returnerer, når ingen af de tilbudte kombinationer er acceptable, og den optræder som [ HASH N(NO_PROP) ] inde i en INFORMATIONAL-udveksling.

Signal 15 er en anden hændelse: noget bad den lokale proces om at stoppe, og handleren loggede det. Når begge linjer vises sammen, er rækkefølgen kausal, først afvisning og derefter nedlukning.

Læs forhandlingen, før du rører loginoplysningerne

Skru logniveauet op der, hvor daemonen skriver, og genopret derefter forbindelsen, mens du ser på outputtet. På en NetworkManager-vært sender L2TP-pluginet det niveau videre til backenden, og beskederne havner i journalen eller i den klassiske syslog-fil afhængigt af distributionen. Enhver af disse viser udvekslingen: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' eller tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

En linje, der nævner pluto, kommer fra libreswan, charon fra strongSwan, og de to beskriver samme tilstand med forskellige ord. Den form, der er værd at lede efter, er den, der navngiver den manglende gruppe, for eksempel algorithm 'modp1024' is not supported, fordi den gør en vag fejl til en konkret.

Hvor modp1024 blev af

Diffie-Hellman-gruppe 2 er svag nok til, at flere distributioner stoppede med at kompilere den ind i libreswan fra 3.30 og frem. Så beder en profil, der blev skrevet for år tilbage, eller hentet fra en gateway-guide, der kun lister aes128-sha1-modp1024, den lokale daemon om noget, den slet ikke kan udføre. Nyere NetworkManager-l2tp-builds gør det udfald mere sandsynligt: fra 1.2.16 erstatter de sættet med forslag i Windows 10- og iOS-stil og dropper modp1024, når libreswan registreres. Den anden ende er ofte uskyldig og tilbyder stadig netop den gruppe, du konfigurerede.

Den asymmetri er det, der får fejlen til at føles tilfældig. En ældre klient opretter forbindelse, den samme profil på en opdateret bærbar gør ikke, og serverkonfigurationen har aldrig flyttet sig. Versionsdrift gør skaden.

To reparationer med forskellig rækkevidde

Den billige reparation er at holde op med at hardkode algoritmer. Ryd begge forslagsfelter i editoren, og lad pluginet vælge et sæt, som den fjerne ende accepterer; hvis gatewayen understøtter moderne grupper, afsluttes forhandlingen uden yderligere arbejde.

Den anden reparation holder en gammel gateway tilgængelig ved at installere strongSwan, hvis pakker stadig implementerer gruppe 2 på de fleste distributioner. Det er et daemonskifte, så det koster noget: bekræft, om andre tunneler på værten afhænger af libreswan-konfiguration, før du fjerner den, og forvent SELinux-afvisninger mellem NetworkManager og strongSwan-pluginet på Fedora. De afvisninger dukker op i audit-loggen i stedet for i IKE-sporet, og derfor kan en tunnel se brudt ud lige efter en vellykket installation. Den rækkefølge, der virker, er først dnf install strongswan, derefter rpm -e libreswan.

Forslagsstrenge, der passer, og fælderne omkring dem

Når felterne skal udfyldes i hånden, tager fase 1 og fase 2 forskellige værdier. Et par, der vides at virke mod en Meraki-lignende modpart, tilbyder aes128-sha1-modp1024 i fase 1 med 3des-sha1-modp1024 bag det, begge lukket af et udråbstegn, der gør sættet strengt, så kun disse forslag sendes.

Fase 2 indsnævres derefter til aes128-sha1 og 3des-sha1 med samme strenge markør og slet ingen Diffie-Hellman-suffiks. En fase 2-linje med -modp1024 er en fase 1-værdi i det forkerte felt, og responder afviser den ved hvert forsøg. Kopier den linje til en anden profil, og den anden profil fejler på samme måde, og det er sådan en tastefejl bliver en hændelse for hele flåden.

Andre fejl bærer samme popup uden at være forslagsuoverensstemmelser. På KDE kan L2TP-typen være listet med pluginet installeret, mens hver forbindelse dør med det samme, fordi forbindelseseditoren og køretidshjælperne leveres som separate pakker. Hovedløse værter kan genbruge en profil fra en fungerende computer: kopier den fra /etc/NetworkManager/system-connections/, sæt tilstanden til 600, og kør derefter nmcli con reload. Bring den op med nmcli con up id work-l2tp, da den nøgne form kræver en UUID, og fjern enhver forældet ifname-post, ellers svarer manageren Could not find source connection, mens alt andet er korrekt.

En forudelt nøgle kan gemmes som klartekst eller som 0s efterfulgt af base64; begge former virker, men værdien skal matche gatewayen byte for byte, inklusive efterfølgende mellemrum, du kopierede med.