L2TP: kuolettava signaali 15, NO_PROPOSAL_CHOSEN ja puuttuva modp1024

Yhteytesi jumittuu, asiakas sulkeutuu ja näytön viimeinen rivi on death_handler: Fatal signal 15 received. Se rivi kertoo keskeytyksestä, ei syystä. Riviä ylempänä IPsec-lokissa on lähes aina NO_PROPOSAL_CHOSEN, ja pari osoittaa vaihtotapahtuman vaiheeseen 2, jossa osapuolet vertaavat salaus- ja hajautusvalintojaan ja lopettavat, kun yhteisiä ei ole. Tunnistetietoja ei ole siinä vaiheessa vielä lähetetty, joten salasanan uudelleen kirjoittaminen ei voi muuttaa tulosta.

Kaksi asiaa tyhjentää tuon leikkauksen Linux-asiakkaassa yleensä. Paikallinen daemon ei ehkä enää toteuta profiilin pyytämää Diffie-Hellman-ryhmää, tai profiili kantaa vaiheen 1 ehdotusta vaiheen 2 kentässä. Molemmat jättävät jäljen lokiin, eikä kumpikaan ole tiliin liittyvä ongelma.

Mitä ne kaksi viestiä oikeastaan sanovat

IKE neuvottelee kierroksittain. Vaihe 1 rakentaa suojatun kanavan ja valitsee omat algoritminsa; vaihe 2, lapsi-SA, kuljettaa liikennettä erillisellä joukolla. NO_PROPOSAL_CHOSEN on ilmoitus, jonka vastaaja palauttaa, kun mikään tarjotuista yhdistelmistä ei ole hyväksyttävä, ja se näkyy muodossa [ HASH N(NO_PROP) ] INFORMATIONAL-vaihdon sisällä.

Signaali 15 on eri tapahtuma: jokin käski paikallista prosessia pysähtymään ja käsittelijä kirjasi sen. Kun molemmat rivit näkyvät yhdessä, järjestys on kausaalinen, ensin hylkäys ja sitten sammutus.

Lue neuvottelu ennen kuin kosket tunnistetietoihin

Nosta lokitasoa siellä, mihin daemon kirjoittaa, ja yhdistä sitten uudelleen tulostetta seuraten. NetworkManager-isännässä L2TP-liitännäinen välittää tason taustapalvelulle, ja viestit päätyvät journaliin tai klassiseen syslog-tiedostoon jakelusta riippuen. Kumpi tahansa näistä näyttää vaihdon: journalctl -f -u NetworkManager | grep -Ei 'pluto|charon|no_prop|proposal' tai tail -f /var/log/syslog | grep -Ei 'pluto|charon|ike'.

pluton nimeävä rivi tulee libreswanista, charon strongSwanista, ja molemmat kuvaavat saman tilan eri sanoin. Muoto, jota kannattaa etsiä, on se, joka nimeää puuttuvan ryhmän, esimerkiksi algorithm 'modp1024' is not supported, koska se muuttaa epämääräisen virheen konkreettiseksi.

Minne modp1024 katosi

Diffie-Hellman-ryhmä 2 on niin heikko, että useat jakelut lopettivat sen kääntämisen libreswaniin versiosta 3.30 alkaen. Silloin vuosia sitten kirjoitettu profiili tai yhdyskäytäväoppaasta kopioitu, joka luettelee vain aes128-sha1-modp1024, pyytää paikalliselta daemonilta jotain, mitä se ei lainkaan pysty tekemään. Uudemmat NetworkManager-l2tp-koonnokset tekevät tuosta tuloksesta todennäköisemmän: versiosta 1.2.16 lähtien ne korvaavat joukon Windows 10- ja iOS-tyylisillä ehdotuksilla ja pudottavat modp1024:n heti, kun libreswan havaitaan. Vastapuoli on usein syytön ja tarjoaa edelleen täsmälleen sen ryhmän, jonka määritit.

Juuri tämä epäsymmetria saa vian tuntumaan satunnaiselta. Vanhempi asiakas yhdistää, sama profiili päivitetyssä kannettavassa ei, eikä palvelimen kokoonpano ole koskaan liikkunut. Vahingon tekee versioiden ajautuminen.

Kaksi korjausta, joilla on eri laajuus

Halpa korjaus on lopettaa algoritmien kovakoodaaminen. Tyhjennä molemmat ehdotuskentät editorissa ja anna liitännäisen valita joukko, jonka kaukopää hyväksyy; jos yhdyskäytävä tukee nykyaikaisia ryhmiä, neuvottelu päättyy ilman lisätyötä.

Toinen korjaus pitää vanhan yhdyskäytävän tavoitettavana asentamalla strongSwanin, jonka paketit yhä toteuttavat ryhmän 2 useimmissa jakeluissa. Se on daemonin vaihto, joten se maksaa jotain: varmista, riippuvatko isännän muut tunnelit libreswanin kokoonpanosta, ennen kuin poistat sen, ja odota SELinuxin kieltäytymisiä NetworkManagerin ja strongSwan-liitännäisen välillä Fedorassa. Ne kieltäytymiset näkyvät audit-lokissa eivätkä IKE-jäljessä, siksi tunneli voi näyttää rikkinäiseltä heti onnistuneen asennuksen jälkeen. Toimiva järjestys on ensin dnf install strongswan, sitten rpm -e libreswan.

Sopivat ehdotusjonot ja niiden ympärillä olevat ansat

Kun kentät on täytettävä käsin, vaihe 1 ja vaihe 2 saavat eri arvot. Meraki-tyylistä vastapuolta vastaan toimivaksi tiedetty pari tarjoaa vaiheessa 1 aes128-sha1-modp1024 ja sen takana 3des-sha1-modp1024, molemmat suljetaan huutomerkillä, joka tekee joukosta tiukan, joten vain ne ehdotukset lähetetään.

Sitten vaihe 2 kaventuu arvoihin aes128-sha1 ja 3des-sha1 samalla tiukalla merkinnällä ja ilman minkäänlaista Diffie-Hellman-liitettä. Vaiheen 2 rivi, joka kantaa -modp1024, on vaiheen 1 arvo väärässä kentässä, ja vastaaja hylkää sen joka yrityksellä. Kopioi rivi toiseen profiiliin, niin toinen profiili epäonnistuu samalla tavalla, ja näin yhdestä kirjoitusvirheestä tulee koko laivaston tapaus.

Muut viat kantavat saman ponnahdusikkunan olematta ehdotusten yhteensopimattomuutta. KDE:ssä L2TP-tyyppi voi näkyä listattuna liitännäisen ollessa asennettu, vaikka jokainen yhteys kuolee heti, koska yhteyseditori ja ajonaikaiset apurit toimitetaan erillisinä paketteina. Näytöttömät isännät voivat käyttää uudelleen toimivan työpöydän profiilia: kopioi se kohteesta /etc/NetworkManager/system-connections/, aseta tilaksi 600 ja suorita sitten nmcli con reload. Nosta se komennolla nmcli con up id work-l2tp, koska paljas muoto vaatii UUID:n, ja poista kaikki vanhentuneet ifname-merkinnät, muuten hallinta vastaa Could not find source connection, vaikka kaikki muu on oikein.

Ennalta jaettu avain voidaan tallentaa selväkielisenä tai muodossa 0s ja sen perässä base64; molemmat muodot toimivat, mutta arvon on vastattava yhdyskäytävää tavu tavulta, mukaan lukien perässä olevat välilyönnit, jotka kopioit sen mukana.