P_CONTROL_HARD_RESET_CLIENT_V2 lokissa: onko se virhe?

Rivi toistuu muutaman sekunnin välein ja näyttää kaiken syyltä: paketti nimeltä control hard reset, joka tulee asiakkaalta, joka ei koskaan päädy mihinkään. Se ei ole virhe. Se on uuden istunnon ensimmäinen viesti, ja toistuminen on oire jostain muusta, joka epäonnistuu pidemmällä. Sen erottaminen, mitä nimike sanoo, siitä, mitä yhteys teki seuraavaksi, on koko diagnoosi.

Opcode nimeää kohdan protokollassa

OpenVPN multipleksoi useita pakettityyppejä yhden pistokkeen yli, ja opcode kertoo vastaanottajalle, mitä tyyppiä se pitää. Hard-reset-paketit avaavat istunnon, ohjauspaketit kuljettavat kättelymateriaalia, kuittaukset vahvistavat vastaanoton ja datapaketit kuljettavat tunnelin hyötykuorman. Ensimmäisen tavun lukeminen näyttää, mihin paketti kuuluu tuossa vaihdossa, ja lähdekoodin pakettimääritelmät nimeävät jokaisen perheen eksplisiittisesti.

Se on kaikki, mitä se sanoo. Asiakkaan alkuperäiseksi nollaukseksi merkitty paketti todistaa, että paketti saavutti havaintopisteesi ja että vastapuoli haluaa aloittaa istunnon. Se ei todista, että asiakas luotti sertifikaattiisi, että sen tunnistetiedot hyväksyttiin tai että datakanavasta tuli koskaan käyttökelpoinen.

V2-pääte on kyseisen pakettiperheen protokollasukupolven merkki, ei tuoteversio eikä asetus, jonka asennat. Mikään nimessä ei viittaa tunnelin nollaukseen, palvelun uudelleenkäynnistykseen tai välimuistin tyhjennykseen.

Mitä asiakas todella tekee sillä hetkellä

Asiakas avaa istuntotunnisteen, johon molemmat päät liittävät seuraavan ohjausliikenteen. Kun ohjauskanavan suojaus on määritetty, tuo ensimmäinen paketti kantaa jo HMAC:n, jonka avulla vastaanottaja voi päättää, kannattaako vaihdon loppuun nähdä vaivaa. Vastaanottaja, joka ei voi vahvistaa sitä, pudottaa paketin hiljaa, ja siksi väärä jaettu avain näyttää asiakkaalta, joka puhuu tyhjyyteen.

Mitään käyttäjälle näkyvää ei ole vielä tapahtunut. Yhtään sertifikaattia ei ole validoitu, yhtään käyttäjätunnusta ei ole tarjottu eikä yhtään tunneliosoitetta ole annettu. Nollaus on kättelyn johdanto, joten mikä tahansa arvio yhteydestä tässä vaiheessa on ennenaikainen.

Joutilaassa uudelleenyhdistämisen silmukassa kiinnostava yksityiskohta on väli. Asiakas, joka yrittää uudelleen kiinteällä syklillä edistymättä, hylätään yleensä ennen kuin se voi edetä, ja syy on vastapuolen lokissa, ei paketin nimessä.

Mihin todellinen vika kätkeytyy nollauksen jälkeen

Lue kaksi lokia rinnakkain ja etsi ensimmäinen tapahtuma, joka ei ole nollaus. Asiakkaalla sertifikaatin vahvistuksen epäonnistuminen raportoidaan tarkalla syyllä: vanhentunut sertifikaatti, nimen epäsopivuus tai tuntematon myöntäjä. Palvelimella tunnistetietojen hylkäys raportoidaan todennuksen epäonnistumisena omalla syyllään. Molemmat ovat paljon tarkempia kuin palvelimen toistuva näkemys uusista yrityksistä.

Sovita yksi yritys aikaleiman mukaan sen sijaan, että lukisit kunkin lokin erikseen, koska sama epäonnistuminen näkyy molemmissa paikoissa eri sanamuodoin ja eri vakavuudella. Vastapuoli, joka luovuttaa, kertoo yleensä miksi.

Jos kumpikaan osapuoli ei raportoi hylkäystä ja vaihto juuttuu silti, raja on saavutettavuus eikä luottamus. Palomuuri, joka pudottaa paluusuunnan, verkko-osoitteiden käännöslaitteisto, jonka mappaus vanhenee, tai MTU-ongelma, joka tappaa suuremmat kättelypaketit, tuottavat kaikki pysähtyneen vaihdon ilman yhtään todennusvirhettä.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

Tuo haku ei ole itsessään diagnoosi, mutta se siirtää sinut yhdellä askeleella protokollasanastosta todelliseen vikaluokkaan.

Miksi vahvistuksen poistaminen on väärä refleksi

Kun nollaus jatkaa ilmestymistään, nopeimmalta näyttävä korjaus on poistaa sertifikaattien vahvistus käytöstä tai luopua ohjauskanavan suojauksesta, jotta jotain yhdistyy. Se vaihtaa diagnosoitavan vian diagnosoimattomaan ja jättää käyttöönoton hyväksymään vastapuolia, jotka se rakennettiin hylkäämään.

Muuta sen sijaan rajaa, joka todella petti. Luottamusongelma kuuluu sertifikaattiviranomaiselle ja profiilille, joka viittaa siihen. Aikaongelma kuuluu kellolle. Tunnistetieto-ongelma kuuluu todennuksen taustajärjestelmälle, joka hylkäsi sen, ja saavuttamaton vastapuoli kuuluu kahden isännän väliselle reitille.

Opcodesta on tukikeskustelussa hyötyä yhdessä asiassa: se kertoo, että vastapuoli pääsi tarpeeksi pitkälle yrittääkseen. Se, mitä sen jälkeen tapahtui, on se, mitä sinun on tiedettävä, ja se on kirjattu siihen lokiin, joka tallentaa ensimmäisen konkreettisen hylkäyksen. Aloita siitä, niin nollausrivi lakkaa näyttämästä syyltä ja alkaa näyttää aikaleimalta.