L2TP NO_PROPOSAL_CHOSEN: hvilken fase feilet egentlig?

NO_PROPOSAL_CHOSEN kommer før noe PPP-brukernavn undersøkes, noe som er et nyttig faktum og også grunnen til at meldingen villeder. Den rapporterer at én side avviste et forslag; den rapporterer ikke hvilken parameter som ikke stemte, og den sier ingenting om hvorvidt avvisningen skjedde under byggingen av IKE-tilknytningen eller senere under forhandlingen om trafikkbeskyttelsen. Bak de to mulighetene ligger to ulike rettelser, og bare én av dem gjelder PFS-avkrysningsruten som folk griper til først.

Én melding, to sett med forslag

IKEv1 L2TP/IPsec-oppsettet har to forhandlinger etter hverandre. Fase 1 bygger IKE-sikkerhetstilknytningen fra en krypteringsalgoritme, en integritetsalgoritme og en Diffie-Hellman-gruppe. Fase 2 forhandler deretter om hvordan trafikken beskyttes, og PFS-kravet hører til den andre samtalen.

Fordi fasene er sekvensielle, forteller feilposisjonen deg hvilken liste du skal sammenligne. Det er hele den diagnostiske verdien i meldingen, og den er verdt å hente ut før du rører en innstilling.

Hvorfor en PFS-avkrysningsrute ikke kan reparere fase 1

Å slå av PFS endrer en egenskap ved fase 2. Hvis partene aldri ble enige om fase 1, finner ESP-samtalen aldri sted, så avkrysningsruten har ingen som helst virkning på avvisningen, og derfor gir det samme feilen med et annet tidsstempel når den endres.

Den motsatte feilen er like vanlig. En vellykket IKE-tilknytning beviser ikke at ESP-forslaget er akseptabelt, og den beviser absolutt ikke at gruppen i fase 2 stemmer. Behandle en etablert administrasjonstunnel som bevis bare om fase 1. Folk leser den grønne linjen som «tunnelen er oppe» og bruker deretter en time på feil fase fordi ingenting fortalte dem at den andre forhandlingen ikke var begynt.

Les loggen før du velger algoritmer

Samle meldingene rett før avvisningen fra backend-en som faktisk håndterer tilkoblingen, og korreler dem med det samme forsøket. Uten den korrelasjonen leser du historikken til en annen tilkobling og trekker slutninger fra den.

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

Ut fra disse linjene skal du svare på to spørsmål: ble det etablert en tilknytning i fase 1, og hvilken utveksling feilet. De to svarene snevrer søket inn til én attributtliste. Et nakent varsel uten kontekst rundt seg kan ikke gjøre det, hvor fristende det enn er å prøve et forslag fra en forumtråd. Å kopiere en fungerende streng fra en maskin med en annen backend erstatter vanligvis én avvisning med en annen, litt senere.

Backend-syntaks reiser ikke

Noter versjonen av NetworkManager-l2tp og versjonen av IPsec-backenden før du sammenligner noe. Libreswan og strongSwan deler verken forslagssyntaks eller identiske algoritmesett, så en streng som virker i den ene, er en syntaksfeil i den andre. Den installerte backenden kan også avvise IKEv1 etter policy, og da blir ingen forslag noensinne akseptert.

Prosjektets README dokumenterer disse backend-forskjellene og holder feltene for fase 1 og fase 2 atskilt. Les den som dokumentasjon av strukturen, ikke som en invitasjon til å slå på hver historisk chiffer og en svak gruppe, for en tilkobling som bare lykkes ved å gjøre det, er ikke tilkoblingen du ble bedt om å bygge.

Bli enige om suiten, og verifiser deretter trinnene

Spør gateway-operatøren hvilke IKE- og ESP-suiter som støttes og er godkjent, og sammenlign deretter svaret med klientens faktiske forslag i stedet for med konfigurasjonsfilen. Hvis uenigheten gjelder spesielt PFS i fase 2, velg en støttet gruppe eller en uttrykkelig godkjent policy uten PFS. Ikke utled policyen fra feilnavnet.

Når den eneste overlappingen krever kryptografi som organisasjonen ikke lenger godtar, hører beslutningen til gatewayen eller til en protokollmigrering. Å utvide klientstrengen til noe forhandler er en måte å levere en kjent svakhet med en grønn hake ved siden av.

Etter å ha rettet den reelle uoverensstemmelsen, bekreft IPsec-etableringen før du undersøker L2TP og PPP, og behandle enhver senere autentiseringsavvisning som tilhørende neste trinn. Deretter prøv fornyelse i den godkjente testprosessen, fordi etableringen av den første tilknytningen ikke sier noe om resten av levetiden.