L2TP NO_PROPOSAL_CHOSEN: milline faas tegelikult ebaõnnestus?
Teade ütleb, et pakkumine lükati tagasi, mitte milline. Lugege faasi jaoks backend'i logi ja võrrelge seejärel komplekte sellega, kes lüüsi haldab.
NO_PROPOSAL_CHOSEN saabub enne, kui kontrollitakse ükskõik millist PPP kasutajanime, mis on kasulik fakt ja ühtlasi põhjus, miks teade eksitab. See teatab, et üks pool lükkas pakkumise tagasi; see ei teatata, milline parameeter erines, ega ütle midagi selle kohta, kas tagasilükkamine toimus IKE assotsiatsiooni loomise ajal või hiljem liikluskaitse üle läbirääkimise ajal. Nende kahe võimaluse taga on kaks erinevat parandust ja ainult üks neist puudutab PFS märkeruutu, mille poole inimesed esimesena sirutuvad.
Üks teade, kaks pakkumiste komplekti
IKEv1 L2TP/IPsec korralduses on kaks järjestikust läbirääkimist. Faas 1 ehitab IKE turvaassotsiatsiooni krüpteerimisalgoritmist, terviklikkuse algoritmist ja Diffie-Hellmani grupist. Seejärel räägib faas 2 läbi, kuidas liiklust kaitstakse, ja PFS nõue kuulub sellesse teise vestlusesse.
| 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 |
Kuna faasid on järjestikused, ütleb tõrke asukoht, millist nimekirja võrrelda. Selles ongi kogu teate diagnostiline väärtus ja see tasub välja võtta enne, kui puudutate ükskõik millist seadet.
Miks PFS märkeruut ei saa faasi 1 parandada
PFS-i väljalülitamine muudab faasi 2 omadust. Kui pooled ei jõudnud kunagi faasis 1 kokkuleppele, ei toimu ESP vestlust üldse, seega ei mõjuta märkeruut tagasilükkamist üldse ja seetõttu annab selle lülitamine sama vea teise ajatempliga.
Vastupidine viga on sama tavaline. Õnnestunud IKE assotsiatsioon ei tõesta, et ESP pakkumine on vastuvõetav, ja kindlasti ei tõesta see, et faasi 2 grupp kattub. Käsitlege loodud haldustunnelit tõendina ainult faasi 1 kohta. Inimesed loevad rohelist rida kui «tunnel töötab» ja veedavad siis tund aega vale faasiga, sest miski ei öelnud neile, et teine läbirääkimine polnud alanud.
Lugege logi enne, kui valite algoritme
Koguge tagasilükkamisele vahetult eelnevad teated backend'ist, mis seda ühendust tegelikult teenindab, ja seostage need sama katsega. Ilma selle seosteta loete teise ühenduse ajalugu ja teete sellest järeldusi.
journalctl -b -u NetworkManager --since "10 min ago"
ipsec statusall # strongSwan
ipsec whack --status # LibreswanNendest ridadest vastake kahele küsimusele: kas faasi 1 assotsiatsioon loodi ja milline vahetus ebaõnnestus. Need kaks vastust kitsendavad otsingu ühele atribuutide nimekirjale. Paljas teade ilma ümbritseva kontekstita ei suuda seda, ükskõik kui ahvatlev on proovida pakkumist foorumiteemast. Töötava stringi kopeerimine masinast, kus on teine backend, asendab tavaliselt ühe tagasilükkamise teisega, pisut hiljem.
Backend'i süntaks ei rända
Pange kirja NetworkManager-l2tp versioon ja IPsec backend'i versioon enne, kui midagi võrdlete. Libreswan ja strongSwan ei jaga pakkumiste süntaksit ega identseid algoritmikomplekte, seega ühes töötav string on teises süntaksiviga. Paigaldatud backend võib poliitika järgi IKEv1-i samuti keelduda ja siis ei võeta kunagi ühtegi pakkumist vastu.
Projekti README dokumenteerib need backend'ide erinevused ja hoiab faasi 1 ja faasi 2 väljad eraldi. Lugege seda kui struktuuri dokumentatsiooni, mitte kui kutset lubada iga ajalooline šiffer ja nõrk grupp, sest ühendus, mis õnnestub ainult nii, ei ole ühendus, mida teil paluti ehitada.
Leppige komplektis kokku ja seejärel kontrollige etappe
Küsige lüüsi operaatorilt, millised IKE ja ESP komplektid on toetatud ja kinnitatud, seejärel võrrelge seda vastust kliendi tegelike pakkumistega, mitte selle konfiguratsioonifailiga. Kui lahkarvamus puudutab konkreetselt faasi 2 PFS-i, leppige kokku toetatud grupis või selgesõnaliselt kinnitatud PFS-ita poliitikas. Ärge tuletage poliitikat vea nimest.
Kui ainus kattuvus nõuab krüptograafiat, mida organisatsioon enam ei aktsepteeri, kuulub otsus lüüsile või protokolli migratsioonile. Kliendi stringi laiendamine seni, kuni miski läbi räägib, on viis tarnida teadaolev nõrkus, mille kõrval on roheline linnuke.
Pärast tegeliku lahknevuse parandamist kinnitage IPsec-i loomine enne L2TP ja PPP uurimist ning käsitlege kõiki hilisemaid autentimise tagasilükkamisi järgmise etapi osana. Seejärel katsetage uuendamist kinnitatud testiprotsessis, sest esimese assotsiatsiooni loomine ei ütle midagi selle ülejäänud eluea kohta.