Zavrnjena povezava ni težava s potrdilom: navodila za VPN

Odjemalec pravi, da je bila povezava zavrnjena takoj po tem, ko ste znova ustvarili CRL, zato je CRL videti kriv. Ni. Zavrnitev je odgovor transportnega sloja, preverjanje potrdila pa se zgodi pozneje, znotraj rokovanja predora. Časovno ujemanje je kontekst, ne dokaz.

Dve preverjanji ločita primera v manj kot minuti in nobeno od njiju se ne dotakne nastavitev zaupanja.

Napako berite na sloju, ki jo je ustvaril

ECONNREFUSED iz connect pomeni, da je bil poskus transporta zavrnjen: nekaj je odgovorilo z resetom ali pa je sklad sporočil nedosegljiva vrata. Težava s potrdilom ne more ustvariti te napake, ker se rokovanje TLS nikoli ne začne brez transportne povezave. Če vidite zavrnitev, odjemalec nikoli ni prišel tako daleč, da bi predložil potrdilo. To eno dejstvo izključi preklic kot vzrok.

Velja tudi obratno. Preklicano potrdilo ustvari dokončano povezavo TCP in neuspešno rokovanje, ki se na strežniku zabeleži kot napaka preverjanja.

Zavrnitev TCP: nihče ne posluša

Pri TCP preverite, ali predvidena instanca teče in je vezana na naslov in vrata v profilu. ss -lntp prikaže poslušalce, njihova odsotnost pa je običajna razlaga. Požarni zid, ki zavrne namesto zavrže, ustvari na strani odjemalca isto sporočilo, zato preverite oboje.

Preverite tudi družino naslovov. Storitev, vezana na 127.0.0.1 ali samo na IPv6, bo zavrnila odjemalca, ki se razreši v drugega.

Nato berite dnevnik storitve, namesto da ugibate. Ponovni zagon po vzdrževanju CA lahko spodleti na neberljivi ali manjkajoči datoteki in nikoli ne doseže stanja poslušanja, dnevnik pa imenuje datoteko. To je napaka ob zagonu, drugačna napaka od zavrnjenega potrdila.

UDP nima rokovanja, ki bi ga lahko zavrnili

OpenVPN prek UDP ne vzpostavi povezave v smislu TCP, zato ob connect ni česa zavrniti. V Linuxu lahko napaka, ki jo pokaže vtičnica UDP, izvira iz ICMP port-unreachable, ki ga je ustvaril prejšnji datagram. stran priročnika udp(7) opisuje to asinhrono vedenje.

Zato lahko odjemalec UDP izpiše zavrnitev, medtem ko proces strežnika teče, a ni vezan na pričakovani naslov.

Kje se CRL dejansko preverja

CRL se posvetuje med rokovanjem TLS, potem ko nasprotna stran predloži svoje potrdilo, in le če konfiguracija strežnika to dovoli. Možnost OpenVPN crl-verify kaže na datoteko, napaka pa se v dnevniku strežnika pojavi kot napaka preverjanja z imenom potrdila.

Preklican odjemalec se torej poveže na transportnem sloju in nato spodleti pri overjanju. Isti strežnik, ista vrata, povsem drugo sporočilo.

Ko pridete do te faze, preverite izdajatelja CRL in datume veljavnosti. CRL, ki jo je podpisal napačni CA, ali tista, ki je potekla pred povezavo odjemalca, ustvari napake preverjanja, ki nimajo nič skupnega s potrdilom odjemalca samega.

Kratka navodila za naslednjič

Najprej potrdite transport: poslušalec je prisoten, pravilna družina naslovov, požarni zid ne zavrača. Nato potrdite, da je storitev dosegla stanje poslušanja, tako da preberete zagonski dnevnik. In šele nato poglejte napake rokovanja za sporočila o preverjanju. Vrstni red naj ostane fiksen, ker vsak korak izloči cel razred vzrokov.

Zapišite transport, razrešeni cilj, vrata in točno besedilo napake. Ponovna namestitev odjemalca uniči ta dokaz in običajno ne spremeni ničesar.