Vanha .ovpn-profiili epäonnistuu Ubuntu 24.04:ssa: mitkä rivit poistetaan

Profiili latautuu, tuodaan ja pysähtyy sitten tiedoston riville 12 viestillä Unrecognized option, joka nimeää keysize. Tiliin ei ole tullut mitään muutosta, ja palvelin hyväksyy edelleen muita asiakkaita. Muuttunut on asiakasohjelma itse: Ubuntu 24.04 asentaa OpenVPN 2.6:n, kun taas vienti kirjoitettiin 2.4:lle. Korjaus on lyhyt poistojen sarja, ja järjestyksellä on väliä, koska jokainen vanhentunut asetus keskeyttää jäsennyksen ennen kuin seuraavaa edes luetaan.

Lue virherivi ennen kuin kosket tiedostoon

OpenVPN nimeää tiedoston ja rivin, johon jäsennys pysähtyi, joten voit korjata vain yhden ongelman kerrallaan. Käynnistä profiili päätteestä etkä työpöytäsovelmasta, koska sovelma nielee yleensä stderr-virran ja rivinumero on ainoa luotettava vihje, jonka saat: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Korjaa tuo rivi, aja uudelleen ja odota, että seuraava virhe nimeää toisen asetuksen.

Jäsennysvirhe näkyy aina ennen mitään TLS-kättelyä, joten sertifikaatin mainitseva viesti on jo ohittanut syntaksivaiheen. Tämä ero estää sinua muokkaamasta tiedostoa, joka epäonnistuu vain tunnistautumisessa. Lue viestin ensimmäinen sana, älä sen keskikohtaa.

Kolme virheluokkaa, kolme erilaista korjausta

Vanhat viennit epäonnistuvat kolmella erottuvalla tavalla, ja juuri niiden yhdistäminen yhdeksi ongelmaksi saa ihmiset asentamaan uudelleen paketteja, jotka eivät koskaan olleet rikki. Viestin sanamuoto kertoo, missä luokassa olet, ennen kuin avaat tiedoston.

• Jäsennysvirheet nimeävät tiedoston ja rivin ja pysähtyvät ennen kuin liikennettä on lainkaan.
• Neuvotteluvirheet yhdistävät ja kertovat sitten, etteivät kaksi päätä päässeet sopuun yhteisestä salauksesta tai hyväksyttävästä datakanavasta.
• Tunnistautumisvirheet menevät pisimmälle ja nimeävät sertifikaatin, käyttäjän tai hylätyn tunnistetiedon.

Profiilin muokkaus korjaa vain ensimmäisen luokan. Neuvottelu vaatii päätöksen tunnelin molemmissa päissä, eikä hylätty tunnistetieto ole lainkaan syntaksiongelma. Jos viestisi mainitsee yhteisen salauksen tai datakanavan, alla olevat poistot eivät muuta mitään.

Poista asetukset, jotka 2.6 poisti, tässä järjestyksessä

Jokainen näistä riveistä pysäyttää jäsennyksen itsestään, joten asiakasohjelma ilmoittaa ne yksi kerrallaan. Käy lista alaspäin ja aja uudelleen jokaisen poiston jälkeen.

Poista ensin keysize, koska sillä ei ole nykyaikaista vastinetta ja sen läsnäolo merkitsee yleensä salausta, jonka nykyinen asiakasohjelma hylkää joka tapauksessa. Poista sitten ncp-disable, joka ohjasi salausten neuvottelua, vanheni versiossa 2.5 ja puuttuu versiosta 2.6. Korvaa ns-cert-type server asetuksella remote-cert-tls server, joka ilmaisee saman aikomuksen tuetun tarkistuksen kautta. 2.6:n muutoshistoria luettelee loput poistot niiden korvaajien vieressä, joten kaikella, minkä jäsennin yhä hylkää, on dokumentoitu vastaus.

Ota kopio alkuperäisestä profiilista ennen ensimmäistä muokkausta. Palveluntarjoajat luovat vientejä uudelleen, ja diff koskemattomaan tiedostoon on nopein tapa erottaa omat muutoksesi heidän muutoksistaan. Jos poisto antaa asiakasohjelman käynnistyä mutta tunneli epäonnistuu yhä, olet siirtynyt neuvotteluluokkaan eivätkä jäljellä olevat rivit ole syynä. Laita asiakasohjelman versio tiedostonimeen, jotta seuraava henkilö tietää, mihin julkaisuun muokkaukset kohdistuvat.

Pidä BF-CBC käynnissä vain rajattuna varavaihtoehtona

Jotkin palveluntarjoajat lopettavat yhä BF-CBC:hen, josta OpenVPN 2.6 ei neuvottele ilman apua, koska salauksella on 64-bittinen lohko. Kapea korjaus on varalista ja vanha OpenSSL-tarjoaja, ei koko asiakasohjelman laskeminen.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

Ensimmäinen rivi lataa vanhan tarjoajan, jotta OpenSSL voi yhä luoda kyseisen salauksen, toinen säilyttää nykyaikaisen neuvottelun sitä tukeville vertaisille ja kolmas koskee vain silloin, kun palvelin ei tarjoa mitään parempaa. Kyse on tunnelin tarkoituksellisesta heikentämisestä, joten kirjaa tiedoston viereen, miksi se on olemassa. Pyydä palveluntarjoajalta samalla uudelleen luotu vienti, koska varavaihtoehto on silta eikä määränpää.

Älä tartu --compat-mode:aan yleisratkaisuna. Se muuttaa useita käyttäytymisiä kerralla, mukaan lukien neuvottelun ja uudelleenneuvottelun oletukset, joten et koskaan opi, mikä muutos ratkaisi. Suosi kolmea yllä olevaa täsmällistä riviä, koska jokainen ilmoittaa oman vaikutuksensa.

Varmista profiililla, jonka asiakasohjelma todella lataa

Tuodut yhteydet kopioidaan usein järjestelmähakemistoon, joten latauskansiossa olevan tiedoston muokkaaminen ei välttämättä muuta yhtään mitään. Etsi kopio, joka on käytössä: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Käynnistä sitten tunneli ja lue lokirivi, joka kertoo, mikä datakanavan salaus todella valittiin. Yhteys, joka suorittaa kättelyn varavaihtoehdolla, kertoo, ettei palvelin koskaan tarjonnut mitään nykyaikaista.

Testaa verkosta, joka ei ole se, jota palveluntarjoaja odottaa, jotta captive-portaali tai suodatettu vierasverkko ei esiinny profiilin vikana. Kirjaa asiakasohjelman versio kaikkien tukipyyntöjen yhteyteen.

Kun tunneli on pystyssä, lähetä yksi pyyntö, jonka on kuljettava sen läpi, ja yksi, jonka ei pidä, ja varmista sitten, että ratkaisijan vastaus muuttui odottamallasi tavalla. Jos profiili nyt jäsennetään mutta yhteys epäonnistuu yhä, olet jättänyt syntaksiongelman taaksesi ja virheteksti nimeää uuden luokan. Pidä muokattu tiedosto versionhallinnassa ja sen vieressä merkintä, joka nimeää tavoitellun OpenVPN-julkaisun.