Yhteys hylätty ei ole varmenneongelma: VPN-toimintaohje

Asiakas kertoo yhteyden hylätyksi heti CRL:n uudelleenluonnin jälkeen, joten CRL näyttää syylliseltä. Se ei ole. Hylkäys on kuljetuskerroksen vastaus, ja varmenteen validointi tapahtuu myöhemmin tunnelin kättelyn sisällä. Ajoitus on konteksti, ei todiste.

Kaksi tarkistusta erottaa tapaukset alle minuutissa, eikä kumpikaan niistä koske luottamusasetuksiin.

Lue virhe kerrokselta, joka sen tuotti

ECONNREFUSED connectista tarkoittaa, että kuljetusyritys hylättiin: jokin vastasi resetillä tai pino ilmoitti saavuttamattomasta portista. Varmenneongelma ei voi tuottaa tuota virhettä, koska TLS-kättely ei koskaan ala ilman kuljetusyhteyttä. Jos näet hylkäyksen, asiakas ei koskaan päässyt tarpeeksi pitkälle esittääkseen varmennetta. Tämä yksi tosiasia sulkee pois mitätöinnin syynä.

Myös päinvastainen pätee. Mitätöity varmenne tuottaa valmiin TCP-yhteyden ja epäonnistuneen kättelyn, joka kirjataan palvelimella vahvistusvirheeksi.

TCP-hylkäys: kukaan ei kuuntele

TCP:n kohdalla tarkista, onko aiottu instanssi käynnissä ja sidottu profiilin osoitteeseen ja porttiin. ss -lntp näyttää kuuntelijat, ja niiden puuttuminen on tavallinen selitys. Palomuuri, joka hylkää sen sijaan että pudottaisi, tuottaa saman viestin asiakkaan puolella, siksi tarkistat molemmat.

Tarkista myös osoiteperhe. Palvelu, joka on sidottu osoitteeseen 127.0.0.1 tai vain IPv6:een, hylkää asiakkaan, joka ratkeaa toiseen.

Lue sitten palvelun loki sen sijaan että arvaisit. Uudelleenkäynnistys CA-huollon jälkeen voi epäonnistua lukukelvottomaan tai puuttuvaan tiedostoon eikä koskaan saavuta kuuntelutilaa, ja loki nimeää tiedoston. Se on käynnistysvirhe, eri vika kuin hylätty varmenne.

UDP:llä ei ole kättelyä hylättäväksi

OpenVPN UDP:n yli ei muodosta yhteyttä TCP:n mielessä, joten connect-hetkellä ei ole mitään hylättävää. Linuxissa UDP-pistokkeen ilmoittama virhe voi tulla aiemman datagrammin tuottamasta ICMP port-unreachable -viestistä. udp(7)-manuaalisivu kuvaa tämän asynkronisen käyttäytymisen.

Siksi UDP-asiakas voi tulostaa hylkäyksen, vaikka palvelinprosessi on käynnissä mutta ei sidottu odotettuun osoitteeseen.

Missä CRL oikeasti tarkistetaan

CRL:ää konsultoidaan TLS-kättelyn aikana, sen jälkeen kun vastapuoli on esittänyt varmenteensa, ja vain jos palvelimen kokoonpano sallii sen. OpenVPN:n crl-verify-valinta osoittaa tiedostoon, ja epäonnistuminen näkyy palvelimen lokissa vahvistusvirheenä, joka nimeää varmenteen.

Mitätöity asiakas siis yhdistää kuljetuskerroksella ja epäonnistuu sitten todennuksessa. Sama palvelin, sama portti, täysin eri viesti.

Tarkista CRL:n myöntäjä ja voimassaolopäivät, kun pääset siihen vaiheeseen. Väärän CA:n allekirjoittama CRL tai sellainen, joka vanheni ennen asiakkaan yhdistämistä, tuottaa vahvistusvirheitä, joilla ei ole mitään tekemistä asiakkaan oman varmenteen kanssa.

Lyhyt toimintaohje seuraavaa kertaa varten

Vahvista ensin kuljetus: kuuntelija on olemassa, oikea osoiteperhe, palomuuri ei hylkää. Vahvista sitten käynnistysloki lukemalla, että palvelu saavutti kuuntelutilansa. Ja vasta sitten katso kättelyvirheitä vahvistusviestien varalta. Pidä tämä järjestys kiinteänä, koska jokainen vaihe sulkee pois kokonaisen syyluokan.

Kirjaa ylös kuljetus, ratkaistu kohde, portti ja virheen tarkka teksti. Asiakkaan uudelleenasennus tuhoaa tämän todisteen eikä yleensä muuta mitään.