Miksi OpenVPN lakkasi yhdistämästä Ubuntun päivityksen jälkeen?

Viime viikolla toimineet VPN-profiilit hajoavat Ubuntun versiopäivityksen jälkeen, eikä loki juuri mainitse päivitystä. Se nimeää kerroksen, joka epäonnistui: TLS-kättelyn, datakanavalle neuvotellun salauksen, asennetun paketin tai OpenSSL-kopion, jonka binaari lataa käynnistyksessä. Jokaisella kerroksella on oma virhemuotonsa ja oma korjauksensa, joten luokittelu on ensimmäinen työ ja muokkaus toinen. Pidä profiilia syyttömänä, kunnes loki nimeää sen.

Mikä kerros epäonnistui: kättely, salaus, paketti vai kirjasto

Lue asiakkaan loki ennen kuin kosket profiiliin. varhaisin virhe tulosteessa on se, joka tunnistaa kerroksen; kaikki sen jälkeen tulostettu on yleensä seurausta ensimmäisestä epäonnistumisesta. Kun asiakas ei käynnisty lainkaan, VPN-loki on väärä tiedosto avattavaksi.

Valitukset varmenteista ja allekirjoituksista tai viesti avaimen pituudesta tulevat ohjauskanavasta ja sitä hallitsevasta kirjastokäytännöstä. Varoitus, joka alkaa DEPRECATED OPTION, kuuluu sen sijaan datakanavan neuvotteluun.

Rivi Unrecognized option on kolmas luokka: uusi binaari ei enää hyväksy direktiiviä, jonka vanha sieti, joten profiili on kirjoitettava uudelleen eikä kirjastoa löysättävä. Pakettivirheet näyttävät taas erilaisilta, koska ne tapahtuvat ennen kuin mikään tunnelikoodi ehtii käynnistyä. Puuttuva binaari, lataamaton liitännäinen tai väärään koodinimeen osoittava repo tuottavat kaikki saman muodon. Neljä oiretta, neljä katsottavaa paikkaa ja lähes ei lainkaan päällekkäisyyttä korjausten välillä.

Kun kättely epäonnistuu, TLS-käytäntö hylkää varmenteen

Ubuntu 22.04 siirsi järjestelmän OpenSSL 3:een, ja tuon haaran oletusturvataso on tiukempi varmenteiden allekirjoituksille ja avainten kokoille kuin 20.04 oli. Vanhemmalla tiivisteellä allekirjoitettu CA-varmente tai nykyisen kynnyksen alittava avain epäonnistuu nyt kättelyn aikana. Koska mitään ei ole vielä todennettu, virhe näyttää väärältä salasanalta tai kuolleelta palvelimelta.

Kapea korjaus kiinnittää salausmerkkijonon vain tähän yhteyteen. Työpöytäeditorissa avaa profiili, siirry lisäasetuksiin ja aseta DEFAULT:@SECLEVEL=0 TLS-salauskenttään. NetworkManagerin avaintiedosto ottaa saman arvon kohdassa [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Käynnistä NetworkManager uudelleen ja yhdistä, koska taustapalvelu välimuistittaa jäsennetyt profiilit ja käyttäisi muuten jo hallussaan olevaa kopiota. Tiedä, mitä rivi tekee, ennen kuin pidät sen: asetus on kynnys useiden varmenteen ja avaimen parametrien yli, ei salauksen nimi, joten sen laskeminen laajentaa sitä, mitä yksittäinen profiili hyväksyy. Kirjaa, mikä palvelin sen vaati, ja poista asetus, kun ylläpitäjä julkaisee ajan tasalla olevan materiaalin uudelleen. /etc/ssl/openssl.cnf muuttaminen taas saavuttaa saman kynnyksen jokaiselle ohjelmalle, joka lukee tiedoston, mikä menee paljon VPN:ää pidemmälle.

OpenVPN 2.6 vaatii salauksen lueteltuna neuvotteluun

Ubuntu 22.10 toi OpenVPN 2.6:n, ja siinä julkaisussa --cipher lakkaa valitsemasta datakanavaa itse. Salauksen on oltava myös neuvotellussa data-ciphers luettelossa, tai asiakas tulostaa vanhentumisvaroituksen eikä sitten saa tunnelia nousemaan.

Saman aikakauden NetworkManager-liitännäinen kirjoitti edelleen vain vanhan direktiivin. Tämä yksityiskohta jakaa diagnoosin, sillä käsin korjattu profiili voi yhdistää kuoresta ja epäonnistua silti työpöytäsoveluksesta. Lisää luettelo yhteystiedostoon kohdassa [vpn]:

data-ciphers=AES-256-CBC

Käytä arvoa, jonka palvelin ilmoittaa, älä muistamaasi; AES-256-GCM:ää tarjoava palvelin ei neuvottele asiakasluettelon kanssa, joka nimeää vain CBC:n. Käynnistä hallinta uudelleen ja yhdistä, toista sitten yritys kuoresta antamalla salaus nimenomaisesti sekä neuvotteluun että varalle:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Jos komento nostaa tunnelin, palvelin, varmenteet ja tunnukset ovat kunnossa, ja ainoa jäljellä oleva vika on hallinnan tallentama asetus. Varoitus direktiivistä keysize kuuluu samaan siivoukseen: kommentoi se pois ja pidä alkuperäinen tiedosto profiilin vieressä.

Paketti- ja liitännäisviat näyttävät VPN-vioilta

Jokainen päivityksen jälkeinen epäonnistuminen ei ole salakirjoituksellinen. OpenVPN-repo, joka on lisätty koodinimellä, jota julkaisu ei käytä, tuottaa paketin, jota ei koskaan asenneta, joten vertaa, mitä lsb_release -a raportoi, lisäämääsi luettelotiedostoon. Puuttuva universe komponentti tai turvavarasto tuottaa paketin, jota ei löydy lainkaan. Molemmat tapaukset jättävät profiilin koskemattomaksi ja tunnelin mahdottomaksi.

Lue paketinhallinnan virhe ennen VPN-lokia. Jos asiakasta ei koskaan asennettu, mikään määrä profiilin muokkausta ei tuota kättelyä.

Kaksivaiheiset profiilit, jotka lakkaavat kysymästä, ovat saman tarinan liitännäisversio. Haaste tulee todennusliitännäisestä, ja päivitys, joka pudotti tai korvasi sen, jättää profiilin ehyeksi kehotteen kadotessa. Asenna tuettu liitännäinen uudelleen sen sijaan, että poistaisit toisen vaiheen, jotta yhteys toimisi.

Valmistajan kirjasto voi piiloutua käytäntövirheen taakse

Yksi kuvio ansaitsee tunnistamisen, koska se voittaa jokaisen käytäntökorjauksen. Laitteistovalmistajan asetustyökalu voi asentaa omat OpenSSL-kirjastonsa ja sijoittaa ne lataajan hakupolulla järjestelmän kopioiden eteen. Silloin asiakas käynnistyy kirjastoa vasten, jota kukaan ei päivittänyt, ja käynnistysvirhe näyttää täsmälleen hylätyltä varmenteelta.

VPN-paketin uudelleenasennus ei muuta sitä, mikä kirjasto löytyy ensimmäisenä, eikä TLS-tason laskeminen tavoita kirjastoa, joka ei koskaan tullut järjestelmästä. Kysy lataajalta, mitkä salausobjektit binaari todella ratkaisee:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Poista valmistajan kopio tai ohjaa se uudelleen ja aja sama tarkistus uudelleen. Odotetun version on oltava käytössä oleva, ennen kuin palaat profiiliin.

Vanhemman asiakkaan kiinnittäminen ostaa aikaa, ei ratkaisua

Edellisen asiakasversion pitäminen palauttaa tunnelin niin kauan kuin pito kestää. Se myös jäädyttää paketin tietoturvapäivitykset ja aikatauluttaa saman rikkoutumisen seuraavaan päivitykseen, joten pidä sitä päivättynä väliaikaisratkaisuna, ei korjauksena.

Jos silti kiinnität sen, pidä paketti nimenomaisesti, jotta valvomaton päivitys ei voi kumota kiinnitystä, kirjaa syy ja tarkistuspäivä ja aseta muistutus palveluntarjoajan seuraavasta profiilijulkaisusta. Seurattava ehto on palvelinprofiili, joka neuvottelee ajantasaisen salauksen; kun sellainen on, kiinnityksellä ei ole enää perustelua. Kirjaamaton kiinnitys taas muuttuu katkokseksi, jota kukaan ei osaa selittää puolen vuoden päästä, koska sen tehnyt henkilö on siirtynyt eikä tiedosto tallenna mitään.

Kun VPN seuraavan kerran kuolee versiopäivityksen jälkeen, esitä viisi kysymystä järjestyksessä: mikä kerros tuotti ensimmäisen virheen, hylkäsikö TLS-käytäntö varmenteen, onko salaus neuvoteltavissa molempiin suuntiin, asentuivatko paketti ja sen liitännäinen todella, ja minkä kirjaston prosessi lataa. Vasta kun kaikki viisi palaavat puhtaina, alennus on mielekäs.