L2TP: dødelig signal 15, NO_PROPOSAL_CHOSEN og modp1024 som mangler

Forbindelsen din henger seg opp, klienten avsluttes, og den siste linjen på skjermen er death_handler: Fatal signal 15 received. Den linjen varsler om en avbrytelse, ikke om en årsak. Én linje høyere oppe i IPsec-loggen finnes nesten alltid NO_PROPOSAL_CHOSEN, og paret peker mot fase 2 i utvekslingen, der partene sammenligner krypterings- og hashvalg og stopper når de ikke har noe til felles. Innloggingsdetaljene er ikke sendt på dette stadiet, så å taste passordet på nytt kan ikke endre utfallet.

Vanligvis er det to ting som tømmer dette snittet på en Linux-klient. Den lokale daemonen implementerer kanskje ikke lenger Diffie-Hellman-gruppen profilen ber om, eller profilen inneholder et fase 1-forslag i et fase 2-felt. Begge setter spor i loggen, og ingen av dem er et kontoproblem.

Hva de to meldingene faktisk sier

IKE forhandler i runder. Fase 1 bygger en beskyttet kanal og velger sine egne algoritmer; fase 2, barn-SA, frakter trafikk under et separat sett. NO_PROPOSAL_CHOSEN er varselet en responder returnerer når ingen av kombinasjonene som tilbys er akseptable, og det dukker opp som [ HASH N(NO_PROP) ] inne i en INFORMATIONAL-utveksling.

Signal 15 er en helt annen hendelse: noe ba den lokale prosessen om å stoppe, og behandleren loggførte det. Når begge linjene dukker opp samtidig, er rekkefølgen kausal, først avvisningen og så nedstengingen.

Les forhandlingen før du tar i innloggingsdetaljene

Øk loggnivået der daemonen skriver, og koble til på nytt mens du følger med på utskriften. På en vert med NetworkManager sender L2TP-utvidelsen nivået videre til backend, og meldingene havner i journalen eller i den klassiske syslog-filen etter hvilken distribusjon det er. Én 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 begge beskriver den samme tilstanden med forskjellige ord. Det er formen som navngir den manglende gruppen som er verdt å lete etter, for eksempel algorithm 'modp1024' is not supported, fordi den gjør en vag feil om til en presis.

Hvor det ble av modp1024

Diffie-Hellman-gruppe 2 er så svak at flere distribusjoner sluttet å kompilere den inn i libreswan fra 3.30 og fremover. Da ber en profil som ble skrevet for mange år siden, eller hentet fra en gateway-veiledning som bare lister opp aes128-sha1-modp1024, den lokale daemonen om noe den ikke makter å utføre i det hele tatt. Nyere NetworkManager-l2tp-bygg gjør dette utfallet mer trolig: fra 1.2.16 bytter de ut settet med forslag i Windows 10- og iOS-stil og dropper modp1024 straks libreswan oppdages. Den andre siden er ofte uskyldig og tilbyr fortsatt nøyaktig den gruppen du satte opp.

Det er denne asymmetrien som gjør at feilen føles tilfeldig. En eldre klient kobler til, den samme profilen på en oppdatert maskin gjør det ikke, og serveroppsettet har aldri flyttet på seg. Skaden kommer fra versjonsavvik.

To reparasjoner med ulikt omfang

Den rimelige reparasjonen er å slutte med hardkoding av algoritmer. Tøm begge forslagsfeltene i redigeringsprogrammet og la utvidelsen velge et sett som mottakeren godtar; hvis gatewayen støtter moderne grupper, fullføres forhandlingen uten mer arbeid.

Den andre reparasjonen holder en gammel gateway tilgjengelig ved å installere strongSwan, der pakkene fortsatt implementerer gruppe 2 på de fleste distribusjoner. Det er en daemonutskiftning, og den har en pris: bekreft om andre tunneler på verten er avhengige av libreswan-oppsettet før du fjerner det, og regn med SELinux-avvisninger mellom NetworkManager og strongSwan-utvidelsen på Fedora. Disse 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 fungerer er først dnf install strongswan, deretter rpm -e libreswan.

Forslagsstrenger som passer sammen, og fellene rundt dem

Når feltene må fylles ut manuelt, har fase 1 og fase 2 forskjellige verdier. Et par som er kjent for å fungere mot en motpart i Meraki-stil tilbyr aes128-sha1-modp1024 i fase 1 med 3des-sha1-modp1024 bak, begge avsluttet med et utropstegn som gjør settet strengt, slik at bare disse forslagene noen gang sendes.

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

Andre feil kler seg i den samme popupen uten å være forslagsavvik. På KDE kan L2TP-typen stå oppført med utvidelsen installert mens hver tilkobling dør umiddelbart, fordi tilkoblingsredigereren og kjøretidshjelperne leveres som egne pakker. Hodeløse verter kan gjenbruke en profil fra en fungerende stasjonær maskin: 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 bare formen krever en UUID, og fjern alle utdaterte ifname-oppføringer, ellers svarer behandleren Could not find source connection mens alt annet er riktig.

En forhåndsdelt nøkkel kan lagres som ren tekst eller som 0s etterfulgt av base64; begge formene fungerer, men verdien må stemme med gatewayen byte for byte, inkludert mellomrommene til slutt som du kopierte med.