Rikkesikö Ubuntu-päivitys L2TP/IPsecin? Vertaa IKEv1-ehdotuksia

Yhteys toimi torstaina, päivitys ajettiin perjantaina, ja maanantaina asiakas pyörii “connecting”-tilassa ja luovuttaa. Sama kannettava, sama palvelin, sama tili, sama jaettu avain. Profiilista ei muokattu mitään, ja siksi ilmeiset epäillyt, salasana ja palomuuri, tuhlaavat aikasi.

Muuttunut asia on luettelo muunnoksista, joita koneesi on valmis tarjoamaan. Molemmat Ubuntussa käytetyt IPsec-pinot, strongSwan ja Libreswan, karsivat algoritmeja, joita ne eivät enää pidä turvallisina, ja niiden edessä olevalla NetworkManager-liitännäisellä on oma luettelonsa, joka liikkuu eri aikataululla. Palvelin, joka on kiinnitetty 3DESiin, SHA1:een ja 1024-bittiseen Diffie-Hellman-ryhmään, voi lopulta kuulla mitään hyväksymäänsä.

Mitä päivitys todella muutti

IKEv1-ehdotusta ruokkii kaksi kerrosta. Taustapalvelu toimittaa käännetyn oletusehdotusjoukon, ja L2TP-liitännäinen joko luottaa siihen tai toimittaa oman luettelonsa. Ennen NetworkManager-l2tp 1.2.16 -versiota liitännäinen luotti siihen, joten ehdotuksesi oli se, mitä asennettu taustapalvelu piti järkevänä. Versiosta 1.2.16 alkaen liitännäinen lähettää dokumentoidun luettelon, joka on mallinnettu Windows- ja Apple-asiakkaiden mukaan, ja tämä luettelo on laajempi kuin vanha oletus mutta ei enää sisällä jokaista perittyä yhdistelmää jonon kärjessä.

Tämä jakautuminen selittää vikatilan, jota ihmiset pitävät hämmentävänä: kaksi konetta samassa Ubuntu-julkaisussa voivat käyttäytyä eri tavoin, koska toisessa on jakelupaketti ja toisessa backport, ja taustapalvelun versio näyttää molemmissa samalta virheraportissa. Tarkista liitännäisen versio, älä vain taustapalvelun versiota, ennen kuin päättelet, ettei päivitys muuttanut mitään olennaista.

Samalla alueella on pienempi ansa. Kaksi taustapalvelua kirjoittaa elliptisen käyrän Diffie-Hellman-ryhmät eri tavalla, toinen kirjoittaa ecp384 ja toinen ecp_384. Liitä väärä kirjoitusasu Advanced-valintaikkunaan, niin taustapalvelu hylkää asetuksen jäsentämättömänä, mikä näkyy lokissa neuvotteluongelmana eikä kirjoitusvirheenä määrityksessä.

Lue vika ennen kuin muutat mitään

Aloita siitä, mitä taustajärjestelmää ajat, koska vastaus ratkaisee sekä syntaksin että lokin sijainnin.

ipsec --version
nmcli connection show "Your VPN name" | grep -i ipsec

Lue sitten itse vaihto. strongSwanissa taustapalvelu kirjoittaa journaliin nykyisessä julkaisussa ja vanhemmassa /var/log/syslog -tiedostoon, ja kiinnostava osa on ehdotus, jonka se lähettää, ei viimeinen rivi. Etsit sanamuotoa siitä, ettei vastaavaa ehdotusta ole, mikä on algoritmiongelma; todennusvirhettä, joka viittaa avaimeen tai tiliin; tai tavallista aikakatkaisua, joka viittaa tavoitettavuuteen.

Näitä kolmea tulosta kohdellaan aivan liian usein yhtenä oireena. Aikakatkaisu tyhjällä taustapalvelun lokilla tarkoittaa, etteivät paketit saavu. Ehdotuksen hylkäys tarkoittaa, että ne saapuivat ja hylättiin. Jos lokisi on hiljainen, nosta liitännäisen virheenkorjaustasoa yhden yrityksen ajaksi ja laske sitä sen jälkeen, koska yksityiskohtainen tuloste täyttää journalin nopeasti.

Vaihe 1 ja vaihe 2 ovat erillisiä panoksia

IKEv1 neuvottelee kahdesti. Päämoodi rakentaa IKE-turva-assosiaation salausalgoritmista, eheysalgoritmista, Diffie-Hellman-ryhmästä ja todennusmenetelmästä. Nopea moodi rakentaa sitten ESP-assosiaation, joka kuljettaa L2TP:n. Palvelin voi vapaasti hyväksyä ensimmäisen ja hylätä toisen, joten puoliksi oikea profiili epäonnistuu myöhemmin kuin odotat ja näyttää eri vialta.

Phase 1: 3des-sha1-modp1024!
Phase 2: 3des-sha1!

Huutomerkki on strongSwanin syntaksia tiukalle merkinnälle: tarjoa tämä yksi yhdistelmä eikä mitään muuta. Ilman sitä merkintä liittyy varaluetteloon, mikä on hyvä, kun vastapuoli on nykyaikainen, ja haitallista, kun se on laite, jossa on yksi kovakoodattu käytäntö. Pidä yllä olevaa paria muodon havainnollistuksena, älä suosituksena millekään, mitä rakennat tänään.

Muuta yhtä kenttää ja toista testi

Nykyisessä liitännäisessä nopein ensimmäinen testi on tyhjentää molemmat ehdotuskentät kokonaan ja yhdistää uudelleen, koska toimitettu oletusluettelo sisältää jo tavalliset Windows- ja Apple-yhdistelmät. Vanhemmassa liitännäisessä niiden tyhjentäminen palauttaa hallinnan taustapalvelulle, joka on ehkä pudottanut algoritmin, jota palvelimesi vaatii, ja vika pahenee.

Jos tyhjentäminen ei auta, aseta tiukka pari, jonka palvelimesi dokumentoi, yksi vaihe kerrallaan. Muuta vaihetta 1, yhdistä uudelleen ja lue loki ennen kuin kosket vaiheeseen 2. Kun yhdistelmä lopulta toimii, kirjoita se palvelinmallin ja liitännäisen version viereen, koska oletukset siirtyvät taas ja juuri se muistiinpano tekee seuraavasta päivityksestä viiden minuutin tarkistuksen.