L2TP: fatalt signal 15, NO_PROPOSAL_CHOSEN og manglande modp1024

Tilkoplinga di heng, klienten avsluttar, og den siste linja på skjermen er death_handler: Fatal signal 15 received. Den linja melder om ein avbrot, ikkje ei årsak. Ei linje lenger opp i IPsec-loggen står det nesten alltid NO_PROPOSAL_CHOSEN, og paret peikar mot fase 2 av utvekslinga, der partane samanliknar val av kryptering og hash og stoppar når dei ikkje har noko felles. Påloggingsinformasjonen er ikkje send på det stadiet, så å skrive passordet på nytt kan ikkje endre resultatet.

To ting tømer vanlegvis det snittet på ein Linux-klient. Den lokale daemonen implementerer kanskje ikkje lenger Diffie-Hellman-gruppa profilen ber om, eller profilen ber eit fase 1-framlegg i eit fase 2-felt. Begge lèt spor etter seg i loggen, og ingen av dei er eit kontoproblem.

Kva dei to meldingane eigentleg seier

IKE forhandlar i rundar. Fase 1 byggjer ein verna kanal og vel sine eigne algoritmar; fase 2, barn-SA-en, ber trafikk under eit eige sett. NO_PROPOSAL_CHOSEN er varselet ein svarar returnerer når ingen av dei tilbodne kombinasjonane er akseptable, og det viser seg som [ HASH N(NO_PROP) ] inne i ei INFORMATIONAL-utveksling.

Signal 15 er ein annan hending: noko ba den lokale prosessen stoppe, og handteraren logga det. Når begge linjene viser seg saman, er rekkjefølgja kausal, først avvising og deretter nedstenging.

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

Skru opp loggnivået der daemonen skriv, og kople til på nytt medan du ser på utdata. På ein NetworkManager-vert sender L2TP-pluginen det nivået vidare til backenden, og meldingane hamnar i journalen eller i den klassiske syslog-fila avhengig av distribusjonen. Ein av desse viser utvekslinga: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' eller tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Ei linje som nemner pluto kjem frå libreswan, charon frå strongSwan, og dei to skildrar same tilstand med ulike ord. Forma det er verdt å leite etter, er den som namngjev den manglande gruppa, til dømes algorithm 'modp1024' is not supported, fordi ho gjer ein vag feil til ein konkret.

Kvar modp1024 vart av

Diffie-Hellman-gruppe 2 er svak nok til at fleire distribusjonar slutta å kompilere ho inn i libreswan frå 3.30 og utover. Då ber ein profil skriven for år sidan, eller henta frå ein gateway-rettleiar som berre listar aes128-sha1-modp1024, den lokale daemonen om noko han slett ikkje kan utføre. Nyare NetworkManager-l2tp-byggjer gjer det utfallet meir sannsynleg: frå 1.2.16 byter dei ut settet med framlegg i Windows 10- og iOS-stil og droppar modp1024 så snart libreswan blir oppdaga. Den andre enden er ofte uskuldig og tilbyr framleis nøyaktig gruppa du konfigurerte.

Det er denne asymmetrien som får feilen til å verke tilfeldig. Ein eldre klient koplar til, den same profilen på ein oppdatert berbar gjer det ikkje, og serverkonfigurasjonen har aldri flytta seg. Skaden blir gjord av versjonsdrift.

To reparasjonar med ulik rekkjevidd

Den billege reparasjonen er å slutte å hardkode algoritmar. Tøm begge framleggsfelta i editoren og lat pluginen velje eit sett den fjerne enden godtek; viss gatewayen støttar moderne grupper, blir forhandlinga fullførd utan meir arbeid.

Den andre reparasjonen held ein gamal gateway tilgjengeleg ved å installere strongSwan, som pakkane framleis implementerer gruppe 2 på dei fleste distribusjonar. Det er eit daemonskifte, så det kostar noko: stadfest om andre tunnelar på verten er avhengige av libreswan-konfigurasjonen før du fjernar han, og vent SELinux-avvisingar mellom NetworkManager og strongSwan-pluginen på Fedora. Dei avvisingane dukkar opp i revisjonsloggen og ikkje i IKE-sporet, og difor kan ein tunnel sjå øydelagd ut rett etter ein vellukka installasjon. Rekkjefølgja som verkar, er først dnf install strongswan, deretter rpm -e libreswan.

Framleggsstrengjer som passar, og fellene rundt dei

Når felta må fyllast ut for hand, tek fase 1 og fase 2 ulike verdiar. Eit par som er kjent for å verke mot ein motpart i Meraki-stil, tilbyr aes128-sha1-modp1024 i fase 1 med 3des-sha1-modp1024 bak, begge lukka av eit utropsteikn som gjer settet strengt, slik at berre dei framlegga blir sende.

Fase 2 blir deretter snevra inn til aes128-sha1 og 3des-sha1 med same strenge merke og utan noko Diffie-Hellman-suffiks i det heile. Ei fase 2-linje med -modp1024 er ein fase 1-verdi i feil felt, og svararen avviser ho ved kvar freistnad. Kopier den linja til ein andre profil, og den andre profilen feilar på same måte, og slik blir ein skrivefeil ei hending for heile flåten.

Andre feil ber same popup utan å vere framleggsusemje. På KDE kan L2TP-typen listast opp med pluginen installert medan kvar tilkopling døyr med ein gong, fordi tilkoplingseditoren og køyretidshjelparane blir leverte som separate pakkar. Hovudlause vertar kan bruke om att ein profil frå ein fungerande skrivebord: kopier han frå /etc/NetworkManager/system-connections/, set modusen til 600, og køyr deretter nmcli con reload. Ta han opp med nmcli con up id work-l2tp, sidan den nakne forma vil ha ein UUID, og fjern kvar utdatert ifname-oppføring, elles svarar administratoren Could not find source connection medan alt anna er rett.

Ein førehandsdelt nøkkel kan lagrast som klartekst eller som 0s etterfylgd av base64; begge former verkar, men verdien må stemme med gatewayen byte for byte, inkludert mellomromma på slutten du kopierte med.