L2TP NO_PROPOSAL_CHOSEN: hvilken fase fejlede egentlig?

NO_PROPOSAL_CHOSEN kommer, før nogen PPP-brugernavn undersøges, hvilket er et nyttigt faktum og også grunden til, at meddelelsen vildleder. Den rapporterer, at den ene side afviste et forslag; den rapporterer ikke, hvilken parameter der var uenig, og den siger intet om, hvorvidt afvisningen skete under opbygningen af IKE-forbindelsen eller senere under forhandlingen af trafikbeskyttelsen. Bag de to muligheder ligger to forskellige rettelser, og kun én af dem involverer PFS-afkrydsningsfeltet, som folk griber efter først.

Én meddelelse, to sæt forslag

IKEv1 L2TP/IPsec-opstillingen har to forhandlinger efter hinanden. Fase 1 opbygger IKE-sikkerhedsforbindelsen ud fra en krypteringsalgoritme, en integritetsalgoritme og en Diffie-Hellman-gruppe. Fase 2 forhandler derefter, hvordan trafikken beskyttes, og PFS-kravet hører til den anden samtale.

Fordi faserne er sekventielle, fortæller fejlpositionen dig, hvilken liste du skal sammenligne. Det er hele den diagnostiske værdi i meddelelsen, og den er værd at trække ud, før du rører en indstilling.

Hvorfor et PFS-afkrydsningsfelt ikke kan reparere fase 1

Deaktivering af PFS ændrer en egenskab ved fase 2. Hvis parterne aldrig blev enige om fase 1, finder ESP-samtalen aldrig sted, så afkrydsningsfeltet har slet ingen effekt på afvisningen, og derfor giver det samme fejl med et andet tidsstempel, når man skifter det.

Den omvendte fejl er lige så almindelig. En vellykket IKE-forbindelse beviser ikke, at ESP-forslaget er acceptabelt, og den beviser bestemt ikke, at fase-2-gruppen stemmer. Behandl en etableret administrationstunnel som bevis for fase 1 alene. Folk læser den grønne linje som »tunnelen er oppe« og bruger derefter en time på den forkerte fase, fordi intet fortalte dem, at den anden forhandling ikke var begyndt.

Læs loggen, før du vælger algoritmer

Indsaml meddelelserne umiddelbart før afvisningen fra den backend, der faktisk håndterer forbindelsen, og korrelér dem med det samme forsøg. Uden den korrelation læser du en anden forbindelses historie og drager konklusioner ud fra den.

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

Ud fra de linjer skal du besvare to spørgsmål: blev der etableret en fase-1-forbindelse, og hvilken udveksling fejlede. De to svar indsnævrer søgningen til én attributliste. En nøgen meddelelse uden kontekst omkring sig kan ikke gøre det, hvor fristende det end er at prøve et forslag fra en forumtråd. Kopiering af en fungerende streng fra en maskine med en anden backend erstatter normalt én afvisning med en anden, lidt senere.

Backend-syntaks rejser ikke

Notér NetworkManager-l2tp-versionen og IPsec-backendens version, før du sammenligner noget. Libreswan og strongSwan deler ikke forslagssyntaks eller identiske algoritmesæt, så en streng, der virker i den ene, er en syntaksfejl i den anden. Den installerede backend kan også afvise IKEv1 efter politik, og så vil intet forslag nogensinde blive accepteret.

Projektets README dokumenterer disse backend-forskelle og holder felterne for fase 1 og fase 2 adskilt. Læs den som dokumentation af strukturen, ikke som en opfordring til at aktivere hver historisk cipher og en svag gruppe, fordi en forbindelse, der kun lykkes ved det, ikke er den forbindelse, du blev bedt om at bygge.

Bliv enige om sættet, og verificér derefter faserne

Spørg gateway-operatøren, hvilke IKE- og ESP-sæt der understøttes og er godkendt, og sammenlign derefter det svar med klientens faktiske forslag i stedet for med dens konfigurationsfil. Hvis uenigheden specifikt handler om fase-2-PFS, så vælg en understøttet gruppe eller en udtrykkeligt godkendt politik uden PFS. Udled ikke politikken af fejlens navn.

Når det eneste overlap kræver kryptografi, som organisationen ikke længere accepterer, tilhører beslutningen gatewayen eller en protokolmigrering. At udvide klientstrengen, indtil noget forhandler, er en måde at levere en kendt svaghed med et grønt hak ved siden af.

Når du har rettet den reelle uoverensstemmelse, skal du bekræfte IPsec-etableringen, før du undersøger L2TP og PPP, og behandle enhver senere godkendelsesafvisning som hørende til næste trin. Afprøv derefter fornyelse i den godkendte testproces, fordi etableringen af den første forbindelse intet siger om resten af dens levetid.