L2TP NO_PROPOSAL_CHOSEN: vilken fas misslyckades egentligen?

NO_PROPOSAL_CHOSEN kommer innan något PPP-användarnamn undersöks, vilket är ett användbart faktum och också skälet till att meddelandet vilseleder. Det rapporterar att en sida avvisade ett förslag; det rapporterar inte vilken parameter som inte stämde, och det säger ingenting om huruvida avvisningen skedde under uppbyggnaden av IKE-associationen eller senare under förhandlingen om trafikskyddet. Bakom de två möjligheterna ligger två olika åtgärder, och bara en av dem gäller PFS-rutan som folk griper efter först.

Ett meddelande, två uppsättningar förslag

IKEv1 L2TP/IPsec-uppställningen har två förhandlingar efter varandra. Fas 1 bygger IKE-säkerhetsassociationen från en krypteringsalgoritm, en integritetsalgoritm och en Diffie-Hellman-grupp. Fas 2 förhandlar sedan om hur trafiken skyddas, och PFS-kravet hör till det andra samtalet.

Eftersom faserna är sekventiella säger felplatsen vilken lista du ska jämföra. Det är hela det diagnostiska värdet i meddelandet, och det är värt att plocka fram innan du rör en inställning.

Varför en PFS-ruta inte kan reparera fas 1

Att stänga av PFS ändrar en egenskap hos fas 2. Om parterna aldrig enades om fas 1 sker ESP-samtalet aldrig, så rutan har ingen som helst inverkan på avvisningen, och därför ger det samma fel med en annan tidsstämpel när den ändras.

Det omvända felet är lika vanligt. En lyckad IKE-association bevisar inte att ESP-förslaget är godtagbart, och den bevisar absolut inte att gruppen i fas 2 stämmer. Behandla en etablerad hanteringstunnel som bevis enbart om fas 1. Folk läser den gröna raden som ”tunneln är uppe” och lägger sedan en timme på fel fas eftersom ingenting berättade för dem att den andra förhandlingen inte hade börjat.

Läs loggen innan du väljer algoritmer

Samla meddelandena strax före avvisningen från den backend som faktiskt hanterar anslutningen, och korrelera dem med samma försök. Utan den korrelationen läser du historiken för en annan anslutning och drar slutsatser från den.

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

Utifrån de raderna ska du svara på två frågor: etablerades en association i fas 1, och vilket utbyte misslyckades. De två svaren snävar in sökningen till en enda attributlista. En naken avisering utan sammanhang runt sig kan inte göra det, hur frestande det än är att prova ett förslag från en forumtråd. Att kopiera en fungerande sträng från en maskin med en annan backend ersätter vanligtvis en avvisning med en annan, lite senare.

Backend-syntax reser inte

Notera versionen av NetworkManager-l2tp och versionen av IPsec-backenden innan du jämför något. Libreswan och strongSwan delar varken förslagssyntax eller identiska algoritmuppsättningar, så en sträng som fungerar i den ena är ett syntaxfel i den andra. Den installerade backenden kan också avvisa IKEv1 enligt policy, och då kommer inget förslag någonsin att accepteras.

Projektets README dokumenterar dessa backend-skillnader och håller fälten för fas 1 och fas 2 åtskilda. Läs den som dokumentation av strukturen, inte som en inbjudan att slå på varje historisk chiffer och en svag grupp, för en anslutning som bara lyckas genom det är inte anslutningen du blev ombedd att bygga.

Enas om suiten och verifiera sedan stegen

Fråga gateway-operatören vilka IKE- och ESP-suiter som stöds och är godkända, och jämför sedan svaret med klientens faktiska förslag i stället för med dess konfigurationsfil. Om oenigheten gäller specifikt PFS i fas 2, välj en stödd grupp eller en uttryckligen godkänd policy utan PFS. Härled inte policyn från felets namn.

När den enda överlappningen kräver kryptografi som organisationen inte längre accepterar hör beslutet till gatewayen eller till en protokollmigrering. Att bredda klientsträngen tills något förhandlar är ett sätt att leverera en känd svaghet med en grön bock bredvid.

När du har rättat den verkliga avvikelsen bekräftar du IPsec-uppkopplingen innan du undersöker L2TP och PPP, och behandlar varje senare autentiseringsavvisning som tillhörande nästa steg. Testa sedan förnyelsen i den godkända testprocessen, för att upprätta den första associationen säger ingenting om resten av dess livstid.