L2TP: fatalt signal 15, NO_PROPOSAL_CHOSEN og manglende modp1024

Tilkoblingen din henger, klienten avslutter, og den siste linjen på skjermen er death_handler: Fatal signal 15 received. Den linjen melder en avbrytelse, ikke en årsak. En linje lenger opp i IPsec-loggen står det nesten alltid NO_PROPOSAL_CHOSEN, og paret peker på fase 2 av utvekslingen, der partene sammenligner valg av kryptering og hash og stopper når de ikke har noe felles. Påloggingsinformasjonen er ikke sendt på det stadiet, så å skrive passordet på nytt kan ikke endre resultatet.

To ting tømmer vanligvis det snittet på en Linux-klient. Den lokale daemonen implementerer kanskje ikke lenger Diffie-Hellman-gruppen profilen ber om, eller profilen bærer et fase 1-forslag i et fase 2-felt. Begge etterlater spor i loggen, og ingen av dem er et kontoproblem.

Hva de to meldingene egentlig sier

IKE forhandler i runder. Fase 1 bygger en beskyttet kanal og velger sine egne algoritmer; fase 2, barn-SA-en, bærer trafikk under et eget sett. NO_PROPOSAL_CHOSEN er varselet en svarer returnerer når ingen av de tilbudte kombinasjonene er akseptable, og det vises som [ HASH N(NO_PROP) ] inne i en INFORMATIONAL-utveksling.

Signal 15 er en annen hendelse: noe ba den lokale prosessen stoppe, og behandleren logget det. Når begge linjene vises sammen, er rekkefølgen kausal, først avvisning og deretter nedstenging.

Les forhandlingen før du rører påloggingsinformasjonen

Skru opp loggnivået der daemonen skriver, og koble til på nytt mens du ser på utdataene. På en NetworkManager-vert sender L2TP-pluginen det nivået videre til backenden, og meldingene havner i journalen eller i den klassiske syslog-filen avhengig av distribusjonen. En av disse viser utvekslingen: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' eller tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

En linje som nevner pluto kommer fra libreswan, charon fra strongSwan, og de to beskriver samme tilstand med ulike ord. Formen det er verdt å lete etter, er den som navngir den manglende gruppen, for eksempel algorithm 'modp1024' is not supported, fordi den gjør en vag feil til en konkret.

Hvor modp1024 ble av

Diffie-Hellman-gruppe 2 er svak nok til at flere distribusjoner sluttet å kompilere den inn i libreswan fra 3.30 og utover. Da ber en profil skrevet for år siden, eller hentet fra en gateway-veiledning som bare lister aes128-sha1-modp1024, den lokale daemonen om noe den slett ikke kan utføre. Nyere NetworkManager-l2tp-bygg gjør det utfallet mer sannsynlig: fra 1.2.16 erstatter de settet med forslag i Windows 10- og iOS-stil og dropper modp1024 så snart libreswan oppdages. Den andre enden er ofte uskyldig og tilbyr fortsatt nøyaktig gruppen du konfigurerte.

Det er denne asymmetrien som får feilen til å virke tilfeldig. En eldre klient kobler til, den samme profilen på en oppdatert bærbar gjør det ikke, og serverkonfigurasjonen har aldri flyttet seg. Skaden gjøres av versjonsdrift.

To reparasjoner med ulik rekkevidde

Den billige reparasjonen er å slutte å hardkode algoritmer. Tøm begge forslagsfeltene i editoren og la pluginen velge et sett den fjerne enden godtar; hvis gatewayen støtter moderne grupper, fullføres forhandlingen uten mer arbeid.

Den andre reparasjonen holder en gammel gateway tilgjengelig ved å installere strongSwan, hvis pakker fortsatt implementerer gruppe 2 på de fleste distribusjoner. Det er et daemonskifte, så det koster noe: bekreft om andre tunneler på verten avhenger av libreswan-konfigurasjonen før du fjerner den, og forvent SELinux-avvisninger mellom NetworkManager og strongSwan-pluginen på Fedora. De avvisningene dukker opp i revisjonsloggen og ikke i IKE-sporet, og derfor kan en tunnel se ødelagt ut rett etter en vellykket installasjon. Rekkefølgen som virker, er først dnf install strongswan, deretter rpm -e libreswan.

Forslagsstrenger som passer, og fellene rundt dem

Når feltene må fylles ut for hånd, tar fase 1 og fase 2 ulike verdier. Et par som er kjent for å virke mot en motpart i Meraki-stil, tilbyr aes128-sha1-modp1024 i fase 1 med 3des-sha1-modp1024 bak, begge lukket av et utropstegn som gjør settet strengt, slik at bare disse forslagene sendes.

Fase 2 snevres deretter inn til aes128-sha1 og 3des-sha1 med samme strenge markør og uten noe Diffie-Hellman-suffiks i det hele tatt. En fase 2-linje med -modp1024 er en fase 1-verdi i feil felt, og svareren avviser den ved hvert forsøk. Kopier den linjen til en andre profil, og den andre profilen feiler på samme måte, og slik blir en skrivefeil en hendelse for hele flåten.

Andre feil bærer samme popup uten å være forslagsuoverensstemmelser. På KDE kan L2TP-typen listes opp med pluginen installert mens hver tilkobling dør med en gang, fordi tilkoblingseditoren og kjøretidshjelperne leveres som separate pakker. Hodeløse verter kan gjenbruke en profil fra en fungerende skrivebord: kopier den fra /etc/NetworkManager/system-connections/, sett modusen til 600, og kjør deretter nmcli con reload. Ta den opp med nmcli con up id work-l2tp, siden den nakne formen vil ha en UUID, og fjern enhver utdatert ifname-oppføring, ellers svarer administratoren Could not find source connection mens alt annet er riktig.

En forhåndsdelt nøkkel kan lagres som klartekst eller som 0s etterfulgt av base64; begge former virker, men verdien må stemme med gatewayen byte for byte, inkludert mellomrommene på slutten du kopierte med.