L2TP NO_PROPOSAL_CHOSEN: welke fase is nu echt mislukt?

NO_PROPOSAL_CHOSEN komt voordat er ook maar een PPP-gebruikersnaam wordt bekeken, wat een nuttig feit is en meteen de reden waarom het bericht misleidt. Het meldt dat één kant een voorstel heeft afgewezen; het meldt niet welke parameter niet overeenkwam, en het zegt niets over de vraag of de afwijzing plaatsvond tijdens het opbouwen van de IKE-associatie of later tijdens het onderhandelen over de verkeersbeveiliging. Achter die twee mogelijkheden zitten twee verschillende oplossingen, en slechts één daarvan raakt het PFS-vakje waar mensen als eerste naar grijpen.

Eén bericht, twee sets voorstellen

De IKEv1 L2TP/IPsec-opzet kent twee onderhandelingen na elkaar. Fase 1 bouwt de IKE-beveiligingsassociatie op uit een versleutelingsalgoritme, een integriteitsalgoritme en een Diffie-Hellman-groep. Fase 2 onderhandelt daarna over hoe het verkeer wordt beschermd, en de PFS-eis hoort bij dat tweede gesprek.

Omdat de fasen opeenvolgend zijn, vertelt de plaats van de fout u welke lijst u moet vergelijken. Daarin zit de hele diagnostische waarde van het bericht, en het loont die eruit te halen voordat u een instelling aanraakt.

Waarom een PFS-vakje fase 1 niet kan repareren

PFS uitschakelen verandert een eigenschap van fase 2. Als de partijen het nooit eens zijn geworden over fase 1, vindt het ESP-gesprek helemaal niet plaats, dus het vakje heeft geen enkel effect op de afwijzing, en daarom levert het omzetten ervan dezelfde fout op met een andere tijdstempel.

De omgekeerde fout komt net zo vaak voor. Een geslaagde IKE-associatie bewijst niet dat het ESP-voorstel aanvaardbaar is, en bewijst zeker niet dat de groep van fase 2 klopt. Behandel een opgezette beheertunnel als bewijs over fase 1 alleen. Mensen lezen de groene regel als «de tunnel staat» en besteden vervolgens een uur aan de verkeerde fase omdat niets hun had verteld dat de tweede onderhandeling nog niet begonnen was.

Lees de log voordat u algoritmen kiest

Verzamel de berichten vlak vóór de afwijzing uit de backend die de verbinding daadwerkelijk afhandelt, en correleer ze met dezelfde poging. Zonder die correlatie leest u de geschiedenis van een andere verbinding en trekt u daar conclusies uit.

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

Beantwoord uit die regels twee vragen: kwam er een associatie in fase 1 tot stand, en welke uitwisseling mislukte. Die twee antwoorden beperken de zoektocht tot één attributenlijst. Een kale melding zonder context eromheen kan dat niet, hoe verleidelijk het ook is om een voorstel uit een forumbericht te proberen. Het kopiëren van een werkende tekenreeks van een machine met een andere backend vervangt meestal de ene afwijzing door een andere, iets later.

Backend-syntaxis reist niet mee

Noteer de versie van NetworkManager-l2tp en die van de IPsec-backend voordat u iets vergelijkt. Libreswan en strongSwan delen geen voorstelsyntaxis of identieke algoritmesets, dus een tekenreeks die in de ene werkt, is een syntaxis fout in de andere. De geïnstalleerde backend kan IKEv1 ook op grond van beleid weigeren, en dan wordt geen enkel voorstel ooit geaccepteerd.

De README van het project documenteert die backend-verschillen en houdt de velden voor fase 1 en fase 2 gescheiden. Lees hem als documentatie van de structuur, niet als een uitnodiging om elke historische cipher en een zwakke groep aan te zetten, want een verbinding die alleen daardoor slaagt is niet de verbinding die u gevraagd is te bouwen.

Spreek de suite af en verifieer daarna de fasen

Vraag de gateway-beheerder welke IKE- en ESP-suites worden ondersteund en goedgekeurd, en vergelijk dat antwoord vervolgens met de effectieve voorstellen van de client in plaats van met zijn configuratiebestand. Als het meningsverschil specifiek over PFS in fase 2 gaat, kies dan een ondersteunde groep of een uitdrukkelijk goedgekeurd beleid zonder PFS. Leid het beleid niet af uit de naam van de fout.

Wanneer de enige overlap cryptografie vereist die de organisatie niet langer accepteert, hoort de beslissing bij de gateway of bij een protocolmigratie. De clienttekenreeks oprekken tot er iets onderhandelt is een manier om een bekende zwakte te leveren met een groen vinkje ernaast.

Nadat u de echte afwijking hebt gecorrigeerd, bevestigt u de IPsec-opzet voordat u L2TP en PPP onderzoekt, en behandelt u elke latere authenticatie-afwijzing als behorend bij de volgende fase. Test daarna de vernieuwing in het goedgekeurde testproces, want het opzetten van de eerste associatie zegt niets over de rest van de levensduur.