L2TP NO_PROPOSAL_CHOSEN: kiu fazo vere malsukcesis?
La sciigo diras, ke propono estis rifuzita, ne kiu. Legu la protokolon de la malantaŭa servo por la fazo, poste komparu la arojn kun tiu, kiu administras la enirejon.
NO_PROPOSAL_CHOSEN alvenas antaŭ ol iu ajn PPP-uzantnomo estas ekzamenita, kio estas utila fakto kaj ankaŭ la kialo, ke la mesaĝo trompas. Ĝi raportas, ke unu flanko rifuzis proponon; ĝi ne raportas, kiu parametro malkongruis, kaj ĝi diras nenion pri tio, ĉu la rifuzo okazis dum la konstruado de la IKE-asocio aŭ poste dum la intertraktado pri la trafika protekto. Malantaŭ tiuj du eblecoj staras du malsamaj riparoj, kaj nur unu el ili temas pri la PFS-markobutono, al kiu homoj unue sin turnas.
Unu mesaĝo, du aroj da proponoj
La IKEv1 L2TP/IPsec-aranĝo havas du intertraktadojn sinsekve. Fazo 1 konstruas la sekurecan asocion IKE el ĉifrada algoritmo, integreca algoritmo kaj Diffie-Hellman-grupo. Fazo 2 poste intertraktas, kiel la trafiko estas protektata, kaj la PFS-postulo apartenas al tiu dua konversacio.
| 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 |
Ĉar la fazoj estas sinsekvaj, la pozicio de la malsukceso diras al vi, kiun liston kompari. En tio kuŝas la tuta diagnoza valoro de la mesaĝo, kaj indas eltiri ĝin antaŭ ol tuŝi ajnan agordon.
Kial PFS-markobutono ne povas ripari la fazon 1
Malŝalti PFS ŝanĝas econ de fazo 2. Se la du flankoj neniam interkonsentis pri fazo 1, la ESP-konversacio neniam okazas, do la markobutono tute ne influas la rifuzon, kaj tial ĝia ŝaltado produktas la saman eraron kun alia tempomarko.
La kontraŭa eraro estas same ofta. Sukcesa IKE-asocio ne pruvas, ke la ESP-propono estas akceptebla, kaj ĝi certe ne pruvas, ke la grupo de fazo 2 kongruas. Traktu establitan administran tunelon kiel pruvon nur pri fazo 1. Homoj legas la verdan linion kiel «la tunelo funkcias», poste pasigas horon en la malĝusta fazo, ĉar nenio diris al ili, ke la dua intertraktado ne komenciĝis.
Legu la protokolon antaŭ ol elekti algoritmojn
Kolektu la mesaĝojn tuj antaŭ la rifuzo el la malantaŭa servo, kiu fakte pritraktas la konekton, kaj kunligu ilin kun la sama provo. Sen tiu kunligo vi legas la historion de alia konekto kaj tiras konkludojn el ĝi.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanEl tiuj linioj respondu du demandojn: ĉu fazo-1-asocio establiĝis, kaj kiu interŝanĝo malsukcesis. Tiuj du respondoj mallarĝigas la serĉon al unu listo de atributoj. Nuda sciigo sen ĉirkaŭa kunteksto ne povas tion fari, kiel ajn alloge estas provi proponon el forumfadeno. Kopii funkcian ĉenon de maŝino kun alia malantaŭa servo kutime anstataŭigas unu rifuzon per alia, iom pli malfrue.
Sintakso de la malantaŭa servo ne vojaĝas
Notu la version de NetworkManager-l2tp kaj la version de la IPsec-malantaŭa servo antaŭ ol kompari ion ajn. Libreswan kaj strongSwan ne kunhavas proponan sintakson nek identajn algoritmoarojn, do ĉeno, kiu funkcias en unu, estas sintaksa eraro en la alia. La instalita malantaŭa servo povas ankaŭ rifuzi IKEv1 laŭ politiko, kaj tiam neniu propono iam estos akceptita.
La README de la projekto dokumentas tiujn diferencojn inter malantaŭaj servoj kaj tenas la kampojn de fazo 1 kaj fazo 2 apartaj. Legu ĝin kiel dokumentaron de la strukturo, ne kiel inviton ebligi ĉiun historian ĉifron kaj malfortan grupon, ĉar konekto, kiu sukcesas nur tiel, ne estas la konekto, kiun oni petis vin konstrui.
Interkonsentu la aron, poste kontrolu la etapojn
Demandu la administranton de la enirejo, kiuj IKE- kaj ESP-aroj estas subtenataj kaj aprobitaj, poste komparu tiun respondon kun la efektivaj proponoj de la kliento anstataŭ kun ĝia agorda dosiero. Se la malkonsento temas specife pri PFS de fazo 2, decidiĝu pri subtenata grupo aŭ pri eksplicite aprobita politiko sen PFS. Ne deduktu la politikon el la nomo de la eraro.
Kiam la sola koincido postulas kriptografion, kiun la organizo ne plu akceptas, la decido apartenas al la enirejo aŭ al protokola migrado. Larĝigi la klientan ĉenon ĝis io intertraktos estas maniero liveri konatan malfortecon kun verda marko apude.
Post kiam vi korektos la realan malkongruon, konfirmu la IPsec-establon antaŭ ol esplori L2TP kaj PPP, kaj traktu ajnan postan aŭtentigan rifuzon kiel apartenantan al la sekva etapo. Poste provu la renovigon en la aprobita testa procezo, ĉar establi la unuan asocion diras nenion pri la resto de ĝia vivo.