Jūsų ryšys užstringa, klientas išeina, o paskutinė eilutė ekrane yra death_handler: Fatal signal 15 received. Ta eilutė praneša apie nutraukimą, o ne priežastį. Viena eilute aukščiau IPsec žurnale beveik visada yra NO_PROPOSAL_CHOSEN, o pora rodo į 2 fazę, kurioje abi pusės lygina šifravimo ir maišos pasirinkimus ir sustoja, kai neturi nieko bendro. Šiame etape prisijungimo duomenys dar neišsiųsti, todėl pakartotinis slaptažodžio įvedimas rezultato nepakeis.

Paprastai Linux kliente tą sankirtą ištuština du dalykai. Vietinis diegimas gali nebeįgyvendinti profilio reikalaujamos Diffie-Hellman grupės, arba profilis gali turėti 1 fazės pasiūlymą 2 fazės lauke. Abu palieka pėdsaką žurnale, ir nė vienas nėra paskyros problema.

Ką iš tikrųjų sako abu pranešimai

IKE derasi etapais. 1 fazė sukuria apsaugotą kanalą ir pasirenka savo algoritmus; 2 fazė, antrinė SA, perduoda srautą pagal atskirą rinkinį. NO_PROPOSAL_CHOSEN yra pranešimas, kurį atsakantysis grąžina, kai nė vienas pasiūlytas derinys nepriimtinas, ir jis pasirodo kaip [ HASH N(NO_PROP) ] INFORMATIONAL mainų viduje.

Signalas 15 yra kitas įvykis: kažkas liepė vietiniam procesui sustoti, ir apdorotojas tai užregistravo. Kai abi eilutės pasirodo kartu, tvarka yra priežastinė: pirma atmetimas, paskui išjungimas.

Perskaitykite derybas prieš liesdami prisijungimo duomenis

Padidinkite žurnalo lygį ten, kur rašo diegimas, tada prisijunkite iš naujo stebėdami išvestį. NetworkManager serveryje L2TP papildinys perduoda tą lygį backend'ui, o pranešimai patenka į journal arba klasikinį syslog failą priklausomai nuo distribucijos. Bet kuris iš jų parodys mainus: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' arba tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

Eilutė, kurioje minimas pluto, ateina iš libreswan, charon iš strongSwan, ir abi aprašo tą pačią būseną skirtingais žodžiais. Forma, kurios verta ieškoti, yra ta, kuri įvardija trūkstamą grupę, pavyzdžiui algorithm 'modp1024' is not supported, nes ji neaiškią klaidą paverčia konkrečia.

Kur dingo modp1024

Diffie-Hellman 2 grupė yra pakankamai silpna, kad kelios distribucijos nustojo ją kompiliuoti į libreswan nuo 3.30. Tada prieš metus parašytas profilis arba iš šliuzo vadovo, kuriame išvardytas tik aes128-sha1-modp1024, paimtas profilis prašo vietinio diegimo padaryti tai, ko jis visiškai negali. Naujesni NetworkManager-l2tp rinkiniai tą baigtį padaro labiau tikėtiną: nuo 1.2.16 jie pakeičia rinkinį Windows 10 ir iOS stiliaus pasiūlymais ir atmeta modp1024, kai tik aptinkamas libreswan. Priešinga pusė dažnai yra nekalta ir vis dar siūlo būtent tą grupę, kurią sukonfigūravote.

Būtent ši asimetrija daro gedimą atrodantį atsitiktinį. Senesnis klientas prisijungia, tas pats profilis atnaujintame nešiojamajame – ne, o serverio konfigūracija niekada nejudėjo. Žalą daro versijų skirtumas.

Du taisymai su skirtingu poveikiu

Pigus taisymas yra nustoti standžiai įrašinėti algoritmus. Išvalykite abu pasiūlymų laukus redaktoriuje ir leiskite papildiniui pasirinkti rinkinį, kurį priima tolimoji pusė; jei šliuzas palaiko šiuolaikines grupes, derybos baigiasi be papildomo darbo.

Antrasis taisymas išlaiko seną šliuzą pasiekiamą įdiegiant strongSwan, kurio paketai daugumoje distribucijų vis dar įgyvendina 2 grupę. Tai diegimo pakeitimas, todėl tai turi kainą: patikrinkite, ar kiti serverio tuneliai priklauso nuo libreswan konfigūracijos, prieš jį šalindami, ir Fedora tikėkitės SELinux atmetimų tarp NetworkManager ir strongSwan papildinio. Tie atmetimai pasirodo audito žurnale, o ne IKE pėdsake, todėl tunelis gali atrodyti sugedęs iškart po sėkmingo įdiegimo. Veikianti tvarka: pirma dnf install strongswan, paskui rpm -e libreswan.

Sutampančios pasiūlymų eilutės ir spąstai aplink jas

Kai laukus reikia pildyti ranka, 1 fazė ir 2 fazė įgyja skirtingas reikšmes. Pora, kuri žinoma kaip veikianti prieš Meraki stiliaus priešininką, 1 fazėje siūlo aes128-sha1-modp1024, o už jo – 3des-sha1-modp1024, abu uždaryti šauktuku, kuris rinkinį padaro griežtą, todėl siunčiami tik tie pasiūlymai.

Tada 2 fazė susiaurėja iki aes128-sha1 ir 3des-sha1 su tuo pačiu griežtu žymekliu ir visai be Diffie-Hellman priesagos. 2 fazės eilutė su -modp1024 yra 1 fazės reikšmė netinkamame lauke, ir atsakantysis ją atmeta kiekvieno bandymo metu. Nukopijuokite tą eilutę į antrą profilį ir antrasis profilis nepavyks taip pat, ir taip viena rašybos klaida tampa viso laivyno incidentu.

Kiti gedimai nešioja tą patį iššokantį langą, nors nėra pasiūlymų nesutapimas. KDE L2TP tipas gali būti sąraše su įdiegtu papildiniu, o kiekvienas ryšys miršta iš karto, nes ryšių redaktorius ir vykdymo laiko pagalbinės programos tiekiamos kaip atskiri paketai. Ekrano neturintys serveriai gali pakartotinai naudoti profilį iš veikiančio darbalaukio: nukopijuokite jį iš /etc/NetworkManager/system-connections/, nustatykite režimą į 600, tada paleiskite nmcli con reload. Pakelkite jį su nmcli con up id work-l2tp, nes plika forma reikalauja UUID, ir pašalinkite bet kurį pasenusį ifname įrašą, kitaip valdytojas atsako Could not find source connection, nors visa kita teisinga.

Iš anksto bendrinamas raktas gali būti saugomas kaip atvirasis tekstas arba kaip 0s ir po jo base64; abi formos veikia, bet reikšmė turi atitikti šliuzą baitas po baito, įskaitant pabaigos tarpus, kuriuos nukopijavote kartu su juo.

Susiję straipsniai