Ferbiningswegering is gjin sertifikaatprobleem: in VPN-handlieding

De klant seit ferbining wegere krekt nei’t jo de CRL opnij makke hawwe, dus de CRL liket skuldich. Dat is er net. Wegering is in antwurd fan ’e transportlaach, en sertifikaatfalidaasje bart letter, binnen de hanskieding fan ’e tunnel. De timing is kontekst, gjin bewiis.

Twa kontrôles skiede de gefallen yn minder as in minút, en gjinien fan beide rekket fertrouwensynstellingen oan.

Lês de flater op ’e laach dy’t him makke hat

ECONNREFUSED fan connect betsjut dat de transportpoging wegere is: eat antwurde mei in reset, of de stack melde in net berikbere poarte. In sertifikaatprobleem kin dy flater net meitsje, want de TLS-hanskieding begjint nea sûnder transportferbining. Sjogge jo in wegering, dan kaam de klant nea fier genôch om in sertifikaat te presintearjen. Dat iene feit slút yntrekking as oarsaak út.

It tsjinoerstelde jildt ek. In ynlutsen sertifikaat makket in foltôge TCP-ferbining en in mislearre hanskieding, dy’t op ’e server as falidaasjeflater logd wurdt.

TCP-wegering: nimmen harket

Foar TCP, kontrolearje oft de bedoelde eksimplaar rint en bûn is oan it adres en de poarte yn it profyl. ss -lntp toant harkers, en it ûntbrekken fan ien is de gewoane ferklearring. In firewall dy’t wegeret ynstee fan te dropjen makket deselde boadskip oan ’e klantkant, dêrom kontrolearje jo beide.

Kontrolearje ek de adresfamylje. In tsjinst bûn oan 127.0.0.1 of allinnich oan IPv6 sil in klant wegerje dy’t nei de oare resolvet.

Lês dan it tsjinstlog ynstee fan te rieden. In werstart nei CA-ûnderhâld kin mislearje op in ûnlêsber of ûntbrekkend bestân en nea de harkstân berikke, en it log neamt it bestân. Dat is in startflater, in oare bug as in wegere sertifikaat.

UDP hat gjin hanskieding om te wegerjen

OpenVPN oer UDP makket gjin ferbining yn ’e TCP-sin, dus by connect is der neat te wegerjen. Op Linux kin in flater dy’t in UDP-socket toant, komme fan in ICMP port-unreachable dy’t troch in earder datagram makke is. De manpazjina udp(7) beskriuwt dat asynkrone gedrach.

Dêrom kin in UDP-klant in wegering printsje wylst it serverproses rint mar net oan it ferwachte adres bûn is.

Wêr’t in CRL echt kontrolearre wurdt

De CRL wurdt yn ’e TLS-hanskieding rieplachte, neidat de oare kant syn sertifikaat presintearre hat, en allinnich as de serverkonfiguraasje dat tasteat. De opsje crl-verify fan OpenVPN wiist nei it bestân, en in mislearring ferskynt yn it serverlog as in falidaasjeflater dy’t it sertifikaat neamt.

In ynlutsen klant ferbynt dus op ’e transportlaach en mislearret dêrnei by de autentikaasje. Deselde server, deselde poarte, folslein oare boadskip.

Kontrolearje de útjouwer en de jildichheidsdatums fan ’e CRL as jo dat stadium berikke. In CRL ûndertekene troch de ferkearde CA, of ien dy’t ferrûn foardat de klant ferbûn, makket falidaasjeflaters dy’t neat mei it eigen sertifikaat fan ’e klant te meitsjen hawwe.

In koarte hânlieding foar de folgjende kear

Befêstigje earst it transport: harker oanwêzich, krekte adresfamylje, firewall dy’t net wegeret. Befêstigje dêrnei dat de tsjinst har harkstân berikt hat troch it startlog te lêzen. En dêrnei, en pas dan, sjoch foar hanskiedingsflaters nei falidaasjeboadskippen. Hâld dy folchoarder fêst, want elke stap slút in hiele klasse oarsaken út.

Skriuw it transport, de resolvet bestimming, de poarte en de krekte flatertekst op. In werynstallaasje fan ’e klant ferneatiget dat bewiis en feroaret meastentiids neat.