L2TP NO_PROPOSAL_CHOSEN: kva fase svikta eigentleg?

NO_PROPOSAL_CHOSEN kjem før noko PPP-brukarnamn vert undersøkt, noko som er eit nyttig faktum og òg grunnen til at meldinga villeder. Ho melder at éi side avviste eit framlegg; ho melder ikkje kva parameter som ikkje stemde, og ho seier ingenting om avvisinga skjedde under bygginga av IKE-samankoplinga eller seinare under forhandlinga om trafikkvernet. Bak dei to mogleikane ligg to ulike rettingar, og berre éi av dei gjeld PFS-avkryssingsruta som folk grip til først.

Éi melding, to sett med framlegg

IKEv1 L2TP/IPsec-oppsettet har to forhandlingar etter kvarandre. Fase 1 byggjer IKE-tryggleikssamankoplinga frå ein krypteringsalgoritme, ein integritetsalgoritme og ei Diffie-Hellman-gruppe. Fase 2 forhandlar deretter om korleis trafikken vert verna, og PFS-kravet høyrer til den andre samtalen.

Fordi fasane er sekvensielle, fortel feilplasseringa deg kva liste du skal samanlikne. Det er heile den diagnostiske verdien i meldinga, og han er verd å hente ut før du rører ei innstilling.

Kvifor ei PFS-avkryssingsrute ikkje kan reparere fase 1

Å slå av PFS endrar ein eigenskap ved fase 2. Viss partane aldri vart samde om fase 1, finn ESP-samtalen aldri stad, så avkryssingsruta har inga som helst verknad på avvisinga, og difor gjev det same feilen med eit anna tidsstempel når ho vert endra.

Den motsette feilen er like vanleg. Ei vellukka IKE-samankopling provar ikkje at ESP-framlegget er akseptabelt, og ho provar absolutt ikkje at gruppa i fase 2 stemmer. Handsame ein etablert administrasjonstunnel som prov berre om fase 1. Folk les den grøne lina som «tunnelen er oppe» og brukar deretter ein time på feil fase fordi ingenting fortalde dei at den andre forhandlinga ikkje var byrja.

Les loggen før du vel algoritmar

Samle meldingane rett før avvisinga frå backend-en som faktisk handsamar sambandet, og korreler dei med det same forsøket. Utan den korrelasjonen les du historia til eit anna samband og dreg slutningar frå henne.

journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall          # strongSwan
ipsec whack --status     # Libreswan

Ut frå desse linene skal du svare på to spørsmål: vart det etablert ei samankopling i fase 1, og kva utveksling svikta. Dei to svara snevrar søket inn til éi attributtliste. Eit nake varsel utan kontekst rundt seg kan ikkje gjere det, kor freistande det enn er å prøve eit framlegg frå ein forumtråd. Å kopiere ein fungerande streng frå ein maskin med ein annan backend byter vanlegvis éi avvising mot ei anna, litt seinare.

Backend-syntaks reiser ikkje

Noter versjonen av NetworkManager-l2tp og versjonen av IPsec-backenden før du samanliknar noko. Libreswan og strongSwan deler korkje framleggssyntaks eller identiske algoritmesett, så ein streng som verkar i den eine, er ein syntaksfeil i den andre. Den installerte backenden kan òg avvise IKEv1 etter policy, og då vert ingen framlegg nokosinne aksepterte.

README-en til prosjektet dokumenterer desse backend-skilnadene og held felta for fase 1 og fase 2 åtskilde. Les han som dokumentasjon av strukturen, ikkje som ei innbyding til å slå på kvar historisk chiffer og ei svak gruppe, for eit samband som berre lukkast ved å gjere det, er ikkje sambandet du vart beden om å byggje.

Bli samde om suiten, og verifiser deretter trinna

Spør gateway-operatøren kva IKE- og ESP-suitar som vert støtta og godkjende, og samanlikn deretter svaret med dei faktiske framlegga til klienten i staden for med konfigurasjonsfila. Viss usemja gjeld spesielt PFS i fase 2, vel ei støtta gruppe eller ein uttrykkeleg godkjend policy utan PFS. Ikkje utleie policyen frå feilnamnet.

Når den einaste overlappinga krev kryptografi som organisasjonen ikkje lenger godtek, høyrer avgjerda til gatewayen eller til ein protokollmigrasjon. Å utvide klientstrengen til noko forhandlar er ein måte å levere ei kjend svakheit med ein grøn hake ved sida av.

Etter å ha retta den reelle usemja, stadfest IPsec-etableringa før du undersøkjer L2TP og PPP, og handsame kvar seinare autentiseringsavvising som høyrande til neste trinn. Prøv deretter fornying i den godkjende testprosessen, fordi etableringa av den første samankoplinga seier ingenting om resten av levetida.