Hafnað tenging er ekki vandamál með skilríki: VPN-handbók

Biðlarinn segir tengingu hafnað rétt eftir að þú bjóst CRL til að nýju, svo CRL virðist sekur. Það er hann ekki. Höfnun er svar flutningslaganna, og staðfesting skilríkis fer fram síðar, inni í handabandi göngunnar. Tímasetningin er samhengi, ekki sönnun.

Tvær athuganir aðskilja tilfellin á innan við mínútu, og hvorug þeirra snertir trauststillingar.

Lesið villuna á því lagi sem framleiddi hana

ECONNREFUSED frá connect þýðir að flutningstilrauninni var hafnað: eitthvað svaraði með reset, eða staflinn tilkynnti óaðgengilega höfn. Vandamál með skilríki getur ekki framleitt þá villu, því TLS-handabandið hefst aldrei án flutningstengingar. Ef þú sérð höfnun komst biðlarinn aldrei nógu langt til að leggja fram skilríki. Þessi eina staðreynd útilokar afturköllun sem orsök.

Hið gagnstæða gildir líka. Afturkallað skilríki framleiðir fullkláraða TCP-tengingu og misheppnað handaband, sem skráist á netþjóninum sem staðfestingarvilla.

Höfnun TCP: enginn er að hlusta

Fyrir TCP, athugaðu hvort fyrirhugað eintak sé í gangi og bundið við vistfangið og höfnina í prófílnum. ss -lntp sýnir hlustendur, og skortur á einum er venjulega skýringin. Eldveggur sem hafnar í stað þess að sleppa framleiðir sama skilaboð á biðlarahlið, þess vegna athugar þú bæði.

Athugaðu líka vistfangafjölskylduna. Þjónusta bundin við 127.0.0.1 eða aðeins IPv6 mun hafna biðlara sem leysist í hina.

Lestu síðan þjónustulogið í stað þess að giska. Endurræsing eftir viðhald CA getur mistekist á ólæsilegri eða vantaðri skrá og nær aldrei hlustunarstöðunni, og logið nefnir skrána. Það er ræsingarvilla, önnur villa en hafnað skilríki.

UDP hefur ekkert handaband til að hafna

OpenVPN yfir UDP myndar ekki tengingu í TCP-skyni, þannig að ekkert er til að hafna við connect. Á Linux getur villa sem UDP-tengi sýnir komið frá ICMP port-unreachable sem fyrri gagnagramma myndaði. handbókarsíðan udp(7) lýsir þessari ósamstilltu hegðun.

Þess vegna getur UDP-biðlari prentað höfnun meðan þjónustuferlið er í gangi en er ekki bundið við væntanlegt vistfang.

Hvar CRL er í raun athugað

CRL er ráðfært við í TLS-handabandinu, eftir að mótaðilinn leggur fram skilríki sitt, og aðeins ef stilling netþjónsins leyfir það. Valkostur OpenVPN crl-verify vísar á skrána, og bilun birtist í netþjónsloginu sem staðfestingarvilla sem nefnir skilríkið.

Afturkallaður biðlari tengist því á flutningslaginu og mistekst síðan í auðkenningu. Sami netþjónn, sama höfn, gjörólík skilaboð.

Athugaðu útgefanda og gildisdagsetningar CRL þegar þú kemur á það stig. CRL undirritað af röngu CA, eða eitt sem rann út áður en biðlarinn tengdist, framleiðir staðfestingarvillur sem hafa ekkert með skilríki biðlarans sjálfs að gera.

Stutt handbók fyrir næsta skipti

Staðfestu flutninginn fyrst: hlustandi til staðar, rétt vistfangafjölskylda, eldveggur hafnar ekki. Staðfestu síðan að þjónustan hafi náð hlustunarstöðu með því að lesa ræsingarlogið. Og aðeins þá skoðaðu handabandsvillur eftir staðfestingarskilaboðum. Haltu þeirri röð fastri, því hvert skref útilokar heilan flokk orsaka.

Skrifaðu niður flutninginn, leysta áfangastaðinn, höfnina og nákvæman villutexta. Enduruppsetning biðlarans eyðileggur þá sönnun og breytir venjulega engu.