L2TP NO_PROPOSAL_CHOSEN: zein fasek huts egin zuen benetan?
Jakinarazpenak proposamen bat baztertu zela dio, ez zein. Irakurri backendaren egunkaria faseari buruz, eta gero alderatu multzoak atebidea kudeatzen duenarekin.
NO_PROPOSAL_CHOSEN PPP erabiltzaile-izen oro aztertu aurretik iristen da, eta hori datu baliotsua da, eta, aldi berean, mezua engainagarria izatearen arrazoia. Alde batek proposamen bat baztertu zuela jakinarazten du; ez du zein parametrok huts egin zuen jakinarazten, eta ez du ezer esaten bazterketa IKE elkartzearen eraikuntzan gertatu zen ala geroago trafikoaren babesaz negoziatzean. Bi aukera horien atzean bi konponketa desberdin daude, eta horietako batek soilik du zerikusia jendeak lehenik jotzen duen PFS kontrol-laukiarekin.
Mezu bat, bi proposamen multzo
IKEv1 L2TP/IPsec antolamenduak bi negoziazio ditu segidan. 1. faseak IKE segurtasun-elkartzea eraikitzen du zifratze-algoritmo batetik, osotasun-algoritmo batetik eta Diffie-Hellman talde batetik. Gero 2. faseak trafikoa nola babestuko den negoziatzen du, eta PFS baldintza bigarren elkarrizketa horri dagokio.
| 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 |
Faseak segidakoak direnez, hutsegitearen kokapenak esaten dizu zein zerrenda alderatu. Hor dago mezuaren balio diagnostiko osoa, eta merezi du edozein ezarpen ukitu aurretik ateratzea.
Zergatik ezin duen PFS kontrol-lauki batek 1. fasea konpondu
PFS desgaitzeak 2. fasearen propietate bat aldatzen du. Aldeek inoiz 1. fasean ados jarri ez badira, ESP elkarrizketa ez da inoiz gertatzen, beraz kontrol-laukiak ez du eraginik bazterketan, eta horregatik aldatzek errore bera ematen du beste denbora-marka batekin.
Alderantzizko akatsa bezain ohikoa da. IKE elkartze arrakastatsu batek ez du frogatzen ESP proposamena onargarria denik, eta inola ere ez du frogatzen 2. faseko taldea bat datorrenik. Ezarritako kudeaketa-tunela 1. faseari buruzko ebidentzia gisa soilik hartu. Jendeak lerro berdea «tunela martxan dago» bezala irakurtzen du, eta gero ordu bat ematen du fase okerrean, ezerk ez zielako esan bigarren negoziazioa hasi ez zela.
Irakurri egunkaria algoritmoak aukeratu aurretik
Bildu bazterketa baino lehenagoko mezuak konexioa benetan kudeatzen duen backendatik, eta lotu saiakera berarekin. Lotura hori gabe beste konexio baten historia irakurtzen ari zara eta hortik ondorioak ateratzen.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanLerro horietatik, erantzun bi galdera: 1. faseko elkartzea ezarri zen, eta zein trukek huts egin zuen. Bi erantzun horiek bilaketa atributu-zerrenda bakar batera murrizten dute. Inguruko testuingururik gabeko jakinarazpen biluzi batek ezin du hori egin, foro baten haritik proposamen bat probatzea oso tentagarria izan arren. Backend desberdina duen makinatik funtzionatzen duen kate bat kopiatzeak bazterketa bat beste batekin ordezkatu ohi du, pixka bat geroago.
Backendaren sintaxia ez da bidaiatzen
Idatzi NetworkManager-l2tp bertsioa eta IPsec backendaren bertsioa ezer alderatu aurretik. Libreswanek eta strongSwanek ez dute proposamen-sintaxirik ez algoritmo-multzo berdinik partekatzen, beraz batean funtzionatzen duen katea sintaxi-errore bat da bestean. Instalatutako backendak IKEv1 ere uka dezake politikaren arabera, eta orduan proposamen bat ere ez da inoiz onartuko.
Proiektuaren READMEak backend arteko desberdintasun horiek dokumentatzen ditu eta 1. faseko eta 2. faseko eremuak bereizita mantentzen ditu. Irakurri egituraren dokumentazio gisa, ez historia guztiko zifratze oro eta talde ahul bat gaitzeko gonbidapen gisa, zeren horrela soilik lortzen den konexioa ez baita eraikitzeko eskatu zizuten konexioa.
Adostu multzoa, gero egiaztatu etapak
Galdetu atebidearen operadoreari zein IKE eta ESP multzo onartzen eta onartuta dauden, eta gero alderatu erantzun hori bezeroaren benetako proposamenekin, ez bere konfigurazio-fitxategiarekin. Desadostasuna 2. faseko PFSari buruzkoa bada zehazki, erabaki talde onartu bat edo PFSrik gabeko politika esplizituki onartua. Ez ondoriozta politika errorearen izenetik.
Elkargune bakarra erakundeak jada onartzen ez duen kriptografia eskatzen duenean, erabakia atebidearena edo protokolo-migrazio batena da. Bezeroaren katea zerbait negoziatu arte zabaltzea ezagutzen den ahulezia alboan marka berde bat duela bidaltzeko modu bat da.
Benetako desadostasuna zuzendu ondoren, berretsi IPsec ezarpena L2TP eta PPP ikertu aurretik, eta har ezazu geroagoko autentifikazio-bazterketa edozein hurrengo etapari dagokion bezala. Gero probatu berritzea onartutako proba-prozesuan, zeren lehen elkartzea ezartzeak ez baitu ezer esaten bere bizitzaren gainerakoari buruz.