L2TP NO_PROPOSAL_CHOSEN: watter fase het werklik gefaal?
Die kennisgewing sê dat 'n voorstel verwerp is, maar nie watter een nie. Lees die backend-log vir die fase en vergelyk dan die suites met diegene wat die gateway bestuur.
NO_PROPOSAL_CHOSEN kom voordat enige PPP-gebruikersnaam ondersoek word, wat 'n nuttige feit is en ook die rede waarom die boodskap misleidend is. Dit rapporteer dat een kant 'n voorstel verwerp het; dit rapporteer nie watter parameter verskil het nie, en dit sê niks daaroor of die verwerping plaasgevind het terwyl die IKE-assosiasie gebou is of later tydens die onderhandeling oor die verkeersbeskerming nie. Twee verskillende regstellings lê agter daardie twee moontlikhede, en net een van hulle behels die PFS-kontroleblokkie waarna mense eerste gryp.
Een boodskap, twee stelle voorstelle
Die IKEv1 L2TP/IPsec-reëling het twee onderhandelinge in volgorde. Fase 1 bou die IKE-sekuriteitsassosiasie uit 'n enkripsie-algoritme, 'n integriteitsalgoritme en 'n Diffie-Hellman-groep. Fase 2 onderhandel dan hoe verkeer beskerm word, en die PFS-vereiste hoort by daardie tweede gesprek.
| Phase | What is agreed | What a rejection here means |
|---|---|---|
| Phase 1 | Encryption, integrity, DH group for the IKE SA | No management tunnel exists, so nothing later can run |
| Phase 2 | ESP transforms plus the PFS group policy | The IKE SA negotiates, then child negotiation fails |
Omdat die fases opeenvolgend is, sê die plek van die mislukking vir jou watter lys om te vergelyk. Dit is die hele diagnostiese waarde in die boodskap, en dit is die moeite werd om dit te onttrek voordat jy aan 'n instelling raak.
Hoekom 'n PFS-kontroleblokkie fase 1 nie kan herstel nie
Om PFS af te skakel verander 'n eienskap van fase 2. As die eweknieë nooit oor fase 1 ooreengekom het nie, vind die ESP-gesprek nooit plaas nie, so die kontroleblokkie het glad geen effek op die verwerping nie, en daarom lewer dit dieselfde fout met 'n ander tydstempel.
Die omgekeerde fout is ewe algemeen. 'n Suksesvolle IKE-assosiasie bewys nie dat die ESP-voorstel aanvaarbaar is nie, en dit bewys beslis nie dat die fase-2-groep ooreenstem nie. Behandel 'n gevestigde bestuurstunnel as bewyse oor fase 1 alleen. Mense lees die groen lyn as "die tunnel is op", en spandeer dan 'n uur op die verkeerde fase omdat niks vir hulle gesê het die tweede onderhandeling het nie begin nie.
Lees die log voordat jy algoritmes kies
Versamel die boodskappe onmiddellik voor die verwerping by die backend wat werklik die verbinding hanteer, en korreleer dit met dieselfde poging. Sonder daardie korrelasie lees jy 'n ander verbinding se geskiedenis en trek jy gevolgtrekkings daaruit.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanBeantwoord twee vrae uit daardie reëls: het 'n fase-1-assosiasie tot stand gekom, en watter uitruiling het gefaal. Daardie twee antwoorde vernou die soektog tot een lys kenmerke. 'n Kaal kennisgewing sonder enige konteks kan dit nie doen nie, hoe aanloklik dit ook is om 'n voorstel uit 'n forumdraad te probeer. Om 'n werkende string van 'n masjien met 'n ander backend te kopieer, vervang gewoonlik een verwerping met 'n ander een, effens later.
Backend-sintaks reis nie saam nie
Teken die NetworkManager-l2tp-weergawe en die IPsec-backend-weergawe op voordat jy enigiets vergelyk. Libreswan en strongSwan deel nie voorstel-sintaks of identiese algoritmesstelle nie, so 'n string wat in die een werk, is 'n sintaksfout in die ander. Die geïnstalleerde backend kan ook IKEv1 per beleid weier, in welke geval geen voorstel ooit aanvaar sal word nie.
Die README van die projek dokumenteer daardie backend-verskille en hou die fase-1- en fase-2-velde apart. Lees dit as dokumentasie van die struktuur, nie as 'n uitnodiging om elke historiese syfer en 'n swak groep te aktiveer nie, want 'n verbinding wat net deur dit te doen slaag, is nie die verbinding wat jy gevra is om te bou nie.
Kom oor die suite ooreen, verifieer dan die fases
Vra die gateway-operateur watter IKE- en ESP-suites ondersteun en goedgekeur word, en vergelyk dan daardie antwoord met die kliënt se effektiewe voorstelle eerder as met sy konfigurasielêer. As die verskil spesifiek oor fase-2-PFS gaan, besluit op 'n ondersteunde groep of op 'n uitdruklik goedgekeurde beleid sonder PFS. Moenie die beleid uit die fout se naam aflei nie.
Wanneer die enigste oorvleueling kriptografie vereis wat die organisasie nie meer aanvaar nie, hoort die besluit by die gateway of by 'n protokolmigrasie. Om die kliëntstring te verbreed tot iets onderhandel, is 'n manier om 'n bekende swakheid te lewer met 'n groen regmerkie daarby.
Nadat jy die werklike wanverhouding reggemaak het, bevestig IPsec-vestiging voordat jy L2TP en PPP ondersoek, en behandel enige latere verwerping van verifikasie as een wat by die volgende stadium hoort. Toets dan hernuwing in die goedgekeurde toetsproses, want die vestiging van die eerste assosiasie sê niks oor die res van sy leeftyd nie.