OpenVPN yrittää yhä uudelleen TLS-virheen jälkeen: näin saat sen loppumaan

Asiakas yhdistää, epäonnistuu TLS-neuvottelun aikana, odottaa ja yrittää samaa palvelinta uudelleen samalla tuloksella. Valvojan alla, joka käynnistää epäonnistuneen prosessin uudelleen, näistä yrityksistä tulee loputon silmukka lokiin, ja ensimmäinen diagnostiikkarivi valuu pois näkyvistä. OpenVPN sisältää asetuksen, joka muuttaa neuvottelun epäonnistumisen näkyväksi poistumiseksi uuden yrityksen sijaan. Se on diagnostiikka- ja valvonta-asetus, ei korjaus, joten yhdistä se käytäntöön, joka todella antaa prosessin jäädä alas.

Silmukka, joka kätkee ensimmäisen virheen

Näet toistuvan lohkon etkä yksittäistä epäonnistumista: yhteysyritys, TLS-virhe, tauko ja sitten sama jakso. Jokainen toisto työntää alkuperäistä riviä ylemmäs lokissa. Jos yksikkö käynnistyy uudelleen epäonnistuessa, silmukka voi jatkua tunteja kenenkään lukematta syytä. Oire on silmukka, vaikka taustalla oleva vika on yksi ainoa neuvotteluongelma.

Interaktiiviset istunnot sietävät tätä, koska hetkellinen virhe voi poistua seuraavalla yrityksellä. Automaattiset yhteydet eivät voi sallia samaa optimismia: prosessin on pysähdyttävä, jotta ihminen tai valvoja näkee tilan.

Ennen kuin muutat mitään, tallenna yksi täysi kierros. Merkitse muistiin etäosoite, virheessä mainittu TLS-vaihe ja poistuuko prosessi ylipäätään.

Silmukan takana oleva uudelleenyritysmekanismi

Uudelleenyritys on oletuksena, koska useat toisistaan riippumattomat aikakatkaisut jakavat saman mekanismin. connect-retry asettaa yhteysyritysten välisen aikavälin, connect-retry-max voi rajoittaa, kuinka usein kukin etäkohde yritetään, ja resolv-retry ohjaa toistuvia nimihakuja. TLS-neuvottelun epäonnistuminen saavuttaa tämän mekanismin siirtotapahtumana, joten asiakas aikatauluttaa uuden yrityksen raportoinnin sijaan. Oletus auttaa epävakaassa yhteydessä ja haittaa viassa, joka ei voi parantua.

Asetus --tls-exit muuttaa vain neuvottelutapausta. Käsikirja kuvaa sen poistumisena TLS-neuvottelun epäonnistuessa, mikä on kapeampi kuin poistuminen jokaisella virheellä. Aikakatkaisut, resolverin viat ja todennuksen hylkäykset säilyttävät oman käyttäytymisensä.

Asiakkaan poistuminen TLS-virheessä

Aseta tls-exit profiiliin, jonka asiakas tosiasiassa lataa, tai anna --tls-exit käynnistyksen yhteydessä, ja aja se kerran etualalla. Lue poistumistila ja viimeinen lokirivi, koska valvoja reagoi juuri tilaan. Nollasta poikkeava poistuminen neuvottelun epäonnistumisen jälkeen on tarkoitettu tulos. Jos prosessi jatkaa yrittämistä lopettamisen sijaan, asetus ei ole profiilissa, jonka asiakas tosiasiassa lataa.

Valvoja päättää, onko poistuminen näkyvää. systemd-yksikkö asetuksella Restart=always tai Restart=on-failure käynnistää asiakkaan uudelleen, joten silmukka jatkuu ja asetus näyttää tekevän ei mitään. Tarkista käytäntö ennen kuin syytät asiakasta:

systemctl show -p Restart -p RestartSec openvpn-client@office
journalctl -u openvpn-client@office -n 40 --no-pager

Restart=no antaa prosessin jäädä alas, ja Restart=on-failure käynnistää silti uudelleen nollasta poikkeavan tilan jälkeen. Jos haluat vian olevan näkyvä mutta palvelun toipuvan irrallisista kaatumisista, aseta Restart=on-failure ja käytä StartLimitBurst ja StartLimitIntervalSec uudelleenkäynnistysten myrskyn pysäyttämiseen. Lue sitten yksikön tila vahvistaaksesi viimeisen poistumiskoodin: systemctl status raportoi sen, ja loki pitää ensimmäisen virheen uudelleenkäynnistysten yläpuolella.

Kirjoita päätös yksikköön tai profiilin muistiinpanoihin. Profiili, joka poistuu TLS-virheessä, näyttää seuraavasta ihmisestä vahingolta, ellei syytä ole kirjattu. Ilmoita, mitkä viat pysäyttävät prosessin ja mitkä yritetään uudelleen.

Todista se kertakäyttöisellä päätepisteellä

Nähdäksesi käyttäytymisen ennen kuin luotat siihen, kopioi profiili ja osoita kopio päätepisteeseen, joka hyväksyy TCP-yhteyden mutta ei koskaan puhu OpenVPN:tä. Riittää kuuntelija, joka vastaa ja vaikenee sitten. tls-exit-asetuksella asiakkaan pitäisi loppua, kun kättely epäonnistuu; ilman sitä saman profiilin pitäisi jatkaa kiertämistä. Käytä kopiota, älä koskaan toimivaa profiilia.

Vertaa kahta ajoa poistumistilan ja ensimmäisen virherivin perusteella, ei sen perusteella, kuinka kauan kumpikin kesti. Tila kertoo, laukesi ko asetus, ja ensimmäinen rivi kertoo, mikä vaihe epäonnistui.

Poista testiprofiili, kun olet valmis. Kopio, jossa on tarkoituksella väärä päätepiste, on ansa jokaiselle, joka myöhemmin käynnistää kaikki hakemiston profiilit.

Vaiheet, joihin tämä asetus ei koskaan yllä

Todennuksen hylkäys on myöhempi vaihe. Jos palvelin arvioi tilin ja hylkää sen, TLS on jo neuvoteltu, joten tls-exit ei laukea. Todennuksen uudelleenyritysasetukset ovat seuraava katsomisen paikka, ja palvelimen syy merkitsee enemmän kuin asiakkaan viimeinen rivi. Väärä salasana ja puuttuva varmenne voivat tuottaa samankaltaisia viestejä asiakkaan puolella.

Puuttuva reitti, väärä resolver tai saavuttamaton yhdyskäytävä ovat myös asetuksen ulkopuolella, koska ne eivät ole neuvottelun epäonnistumisia. Äänetön pakettihäviö on vähiten ilmeinen tapaus: riippuen siitä, kuinka pitkälle vaihto eteni, asiakas voi raportoida neuvottelun epäonnistumisen tai yksinkertaisesti aikakatkaista.

Säilytä ero muistiinpanoissasi. Asetus on diagnostiikkaa ja valvontaa varten, ei korjausta, joten se ei korjaa salauksen poikkeamaa, varmenneongelmaa tai väärää porttia. Korjaa ensin epäonnistuneen neuvottelun syy ja päätä sitten, sopiiko välitön poistuminen yhä käyttöönottoon.