Miten OpenVPN data-ciphers valitsee datakanavan salauksen

Tunneli nousee, loki näyttää salauksen ja profiilin tarkistus jatkuu. Sitten vastapuolelle saapuu päivitys ja sama profiili epäonnistuu viestiin yhteisen salauksen puuttumisesta, mikä lähettää ihmiset etsimään poistettavaa direktiiviä. Hyödyllistä on ymmärtää, että data-ciphers kuvaa neuvottelua, ei asetusta. Toinen osapuoli tarjoaa luettelon, toinen valitsee siitä, ja tuloksena on yksi algoritmi, jota molemmat tukevat. Tuon vaihdon lukeminen selittää useimmat näistä epäonnistumisista ennen kuin muutat riviäkään.

Kaksi kanavaa, kaksi kokoonpanoa

Yhdellä OpenVPN-istunnolla on ohjauskanava ja datakanava. Ohjauskanava ajaa TLS-kättelyn, joka todentaa vastapuolet ja neuvottelee avaimet. Datakanava salaa paketit, jotka kuljettavat liikennettäsi.

data-ciphers määrittää toisen. Ohjauskanavalla on omat valintansa, ja profiilin identiteettitarkistukset ovat kolmas, erillinen asia. Toisen muuttaminen ei korjaa toista, minkä vuoksi profiili voi näyttää oikealta ja silti epäonnistua tietyssä vaiheessa.

Pidä kolme omissa laatikoissaan, kun luet kokoonpanotiedostoa.

Lue neuvottelu lokista

Asiakkaan loki nimeää molemmat tulokset, kun yhteys onnistuu. Yksi rivi kertoo ohjauskanavasta ja sen TLS-tiedoista, ja toinen kertoo valitusta datakanavan salauksesta.

Lue molemmat, koska ne vastaavat eri kysymyksiin. Ohjauskanavan vika pysäyttää yhteyden ennen kuin mikään datasalaus on merkityksellinen. Datakanavan ristiriita ilmenee onnistuneen kättelyn jälkeen, viestillä yhteisen salauksen puuttumisesta.

Vertaa sitten tarjottuja luetteloita molemmilla puolilla. Nimeä, jota toisen vastapuolen versio tai sen salauskerros ei tarjoa, ei voi valita, riippumatta siitä, miten varhain se esiintyy toisen vastapuolen luettelossa.

Miten valinta oikeastaan tapahtuu

Palvelin työntää data-ciphers-luettelonsa asiakkaalle kättelyn aikana, ja asiakas valitsee luettelon ensimmäisen merkinnän, jota se myös tukee. Järjestys kuuluu siis palvelimen kokoonpanoon, ei asiakkaan.

Tämä yksityiskohta selittää yhden hämmentävien tulosten luokan. Asiakkaan luettelon uudelleenjärjestäminen ei muuta mitään, kun palvelimen luettelo päättää. Myöskään sellaisen salauksen lisääminen, jota asiakas ei voi tarjota, ei muuta mitään, koska asiakkaan on pystyttävä käyttämään valitsemaansa merkintää.

Uudemmat versiot muuttivat oletusluetteloa ja nimesivät uudelleen valinnan, joka ennen sisälsi sen, joten eri versioilla olevat vastapuolet voivat olla eri mieltä kenenkään muokkaamatta profiilia. Tarkista versio kummallakin puolella ennen kuin oletat kirjoitusvirheen.

Luettelo ei ole voimakkuuden järjestys abstraktissa mielessä. Se on joukko ehdokkaita, ja valittu on ensimmäinen molemminpuolisesti tuettu merkintä palvelimen järjestyksessä. Siksi kaksi erilaiselta näyttävää luetteloa voi neuvotella saman salauksen. Siksi myös kaksi identtiseltä näyttävää luetteloa voi epäonnistua.

Vanhemmat vastapuolet tarvitsevat tarkoituksellisen varavaihtoehdon

Vastapuoli, joka ei voi neuvotella lainkaan, koska on mekanismia vanhempi tai on poistanut sen käytöstä, tarvitsee dokumentoidun yhteensopivuusjärjestelyn. Varavaihtoehto on olemassa juuri tuota tapausta varten ja koskee vastapuolia, jotka eivät osallistu neuvotteluun.

Se ei ole sama kuin kaikkien perintösalausten ottaminen käyttöön, jotta viesti katoaisi. Laaja luettelo heikentää istuntoa jokaisen vastapuolen kannalta, myös niiden, jotka olisivat neuvotelleet jotain vahvaa.

Sovita kaksi puolta yhteen sen sijaan, että muokkaisit liittymättömiä algoritminimiä. Jos palvelimen päivitys poisti vanhan valinnan, korjaus kuuluu versiosuunnitelmaan, ei asiakkaan hätäiseen räpellykseen.

Säilytä vahvistus ehjänä

Datakanavan ristiriita ei ole syy hyväksyä vahvistamatonta palvelinta. Varmenteen vahvistus, odotettu palvelinnimi ja ohjauskanavan suojausasetukset ovat erillisiä salauksen valinnasta ja niiden tulisi kestää mikä tahansa yhteensopivuusmuutos.

Kirjaa neuvoteltu datasalaus, asiakasversio ja palvelinversio yhdessä, jotta seuraava vertailu alkaa tosiasioista eikä profiilitiedostosta.

Tuettua korjausta testaa alkuyhteys ja uudelleenneuvottelu, koska kerran muodostuva istunto voi silti epäonnistua, kun avaimet uusitaan.

Jos tunneli muodostuu ja sivustot yhä epäonnistuvat, salaus ei ole enää epäilty. Jatka reitityksellä ja DNS:llä. Työn järjestys: lue molemmat lokirivit, vertaa molempia luetteloita, tarkista versiot, lisää varavaihtoehto vain sitä tarvitsevalle vastapuolelle ja testaa sitten uusintapolku uudelleen.