Miksi opt-verifyn lisääminen ei korjaa OpenVPN-salaamisen virhettä

Löydät ehdotuksen lisätä opt-verify, lisäät rivin, ja salausvirhe pysyy täsmälleen siinä, missä se oli. Tulos on ennustettavissa, koska asetus ei koskaan neuvotellut salausta. Se oli asetusten johdonmukaisuustarkistus, vanhentunut versiossa 2.6 ja poistettu versiossa 2.7, eikä profiili, joka vielä jäsennetään sen kanssa, ole sillä pakottanut mitään.

On hyödyllistä tietää, mitä rivi ennen teki, ennen kuin päättelee sen olevan puuttuva pala. Historia selittää myös, miksi se ei voi auttaa nyt.

Mitä asetus ennen pakotti

Version 2.6 käsikirja merkitsee asetuksen opt-verify vanhentuneeksi ja kuvaa aiemman toiminnan: palvelin pudottaa asiakkaat, joiden ilmoitetut asetukset eivät vastaa sen omia, vertaamalla esimerkiksi laitetyyppiä ja MTU:ta. Tarkistus riippuu myös siitä, että asetusten johdonmukaisuustarkistus pysyy käytössä, joten palvelimella, joka toimii asetuksen disable-occ kanssa, sitä ei ole koskaan ollut. Huomaa, mistä vertailu rakennetaan: tekstistä, joka kuvaa vastapuolen kokoonpanoa. Se ei kerro mitään siitä, mitä salausta datakanava käyttää.

Tämä on ensimmäinen syy, miksi lippu ei voi korjata salausvirhettä. Salauksen valintaa ohjaa data-ciphers-käytäntö ja se, mitä molemmat osapuolet tukevat, eikä tekstimuotoinen johdonmukaisuustarkistus laajenna tätä luetteloa eikä suorita neuvottelua. Toinen syy on laajuus: tarkistus koskee sitä, näyttävätkö ilmoitetut asetukset yhteensopivilta, ei syntyvän polun laatua.

Mitä 2.7 tekee nähdessään rivin

Versiossa 2.7 asetusta ei ole. Jäsennin tunnistaa edelleen nimen, minkä vuoksi vanha profiili latautuu ilman syntaksivirhettä, ja se ilmoittaa, että asetus on poistettu, sen sijaan että ohittaisi sen hiljaa. Nimen tunnistaminen ja toiminnan pakottaminen ovat eri asioita, ja vain ensimmäinen tapahtuu enää. Poistohuomautukset kertovat syyn: kun parametreista voidaan neuvotella, kahdella osapuolella voi olla laillisesti erilaiset asetusmerkkijonot, vaikka ne sopisivat yhteydestä.

Jäsennettävä profiili ei siis ole todiste siitä, että mikään hyväksyntätarkistus olisi suoritettu. Jos ainoa merkki on, että asiakas yhdisti, olet oppinut, että syntaksi hyväksyttiin.

Missä vika todella sijaitsee

Säilytä ensimmäinen konkreettinen virhe ennen kuin muutat mitään, sillä myöhemmät viestit ovat yleensä sen seurauksia. Datakanavan neuvotteluvirhe kuuluu hyväksyttyyn salauskäytäntöön ja ominaisuuksiin, joita molemmat osapuolet todella mainostavat. TLS-version tai -sarjan virhe kuuluu ohjauskanavaan. Varmennehylkäys tarvitsee identiteetin ja luottamusketjun, ei yhteensopivuuslippua.

Tunnista myös moottori molemmissa päissä. Työpöytäsovellus voi sisältää eri koontiversion kuin testaamasi komentorivin binaari, ja asetusten tuki eroaa niiden välillä. Tarkista kyseisen moottorin dokumentaatio sen sijaan, että olettaisit jokaisen profiilin tuovan ohjelman käyttäytyvän samoin.

Korvaa aikomus, älä vain riviä

Jos vanhempi hallinnoitu palvelin todella nojasi johdonmukaisuustarkistukseen, kirjaa, mitä rajoitusta se pakotti ennen päivitystä. Huomiotta jätetyn asetuksen pitäminen uudemmassa profiilissa ei voi säilyttää tätä käytäntöä, eikä rivien summittainen poistaminenkaan.

Älä vastaa vanhaan ehdotukseen, että kaikki salaukset on poistettu käytöstä, ottamalla käyttöön jokainen historiallinen algoritmi.

Hyväksytyn korjauksen jälkeen tarkastele neuvotellut tulokset uudella yhteydellä ja testaa sovellus, jota käyttäjä todella tarvitsee. Pidä palvelimen versio ja tehokas käytäntö tämän tuloksen vieressä, jotta seuraava henkilö näkee, mitä sovittiin eikä vain sitä, mitä hyväksyttiin.

Tavoitteena on tuettu rajoitus ja toimiva todennettu polku, ei vanha lippu, joka vielä jäsennetään.