P_CONTROL_HARD_RESET_CLIENT_V2 sa log: error ba ito?

Inuulit ang linyang iyon tuwing ilang segundo at mukhang sanhi ng lahat: isang packet na tinatawag na control hard reset, na nagmumula sa isang client na hindi umabot kahit saan. Hindi ito error. Ito ang unang mensahe ng bagong session, at ang pag-uulit ay sintomas ng ibang bagay na nabibigo sa unahan. Ang paghihiwalay ng sinasabi ng label at ng ginawa ng koneksyon pagkatapos ay ang buong diyagnosis.

Pinapangalanan ng opcode ang posisyon sa protocol

OpenVPN nagmu-multiplex ng ilang uri ng packet sa isang socket, at sinasabi ng opcode sa tatanggap kung anong uri ang hawak niya. Binubuksan ng hard-reset packet ang session, dinadala ng control packet ang materyal ng handshake, kinukumpirma ng acknowledgements ang pagtanggap, at dinadala ng data packet ang kargamento ng tunnel. Ang pagbasa ng unang byte ay nagpapakita kung saan nabibilang ang packet sa palitan na iyon, at ang mga depinisyon ng packet sa source code ay tahasang pinapangalanan ang bawat pamilya.

Iyon lang ang sinasabi nito. Ang packet na may label na paunang client reset ay nagpapatunay na naabot ng packet ang iyong observation point at gustong magsimula ng session ng kapares. Hindi nito pinatutunayan na nagtiwala ang client sa iyong sertipiko, na tinanggap ang kredensyal nito, o na naging magagamit ang isang data channel.

Ang hulaping V2 ay marker ng henerasyon ng protocol para sa pamilyang iyon ng packet, hindi bersyon ng produkto at hindi setting na ini-install mo. Wala sa pangalan ang tumutukoy sa pag-reset ng tunnel, pag-restart ng serbisyo o paglilinis ng cache.

Ano talaga ang ginagawa ng client sa sandaling iyon

Binubuksan ng client ang isang session identifier na kakabitan ng dalawang dulo ng susunod na control traffic. Kapag naka-configure ang proteksyon ng control channel, dinadala na ng unang packet na iyon ang HMAC na nagpapahintulot sa tatanggap na magpasya kung sulit na maglaan ng pagsisikap sa natitirang palitan. Ang tatanggap na hindi ito ma-verify ay tahimik na itinatapon ang packet, kaya ang maling shared key ay mukhang client na nagsasalita sa kawalan.

Wala pang nakikitang nangyari sa user. Walang sertipikong na-validate, walang username na inalok at walang tunnel address na itinalaga. Ang reset ay paunang salita ng handshake, kaya ang anumang paghatol sa koneksyon sa puntong ito ay wala pa sa panahon.

Sa isang idle na loop ng muling pagkonekta, ang kawili-wiling detalye ay ang agwat. Ang client na muling sumusubok sa takdang siklo nang walang pag-unlad ay karaniwang tinatanggihan bago pa man makausad, at ang dahilan ay nasa log ng kapares, hindi sa pangalan ng packet.

Saan nagtatago ang tunay na pagkabigo pagkatapos ng reset

Basahin ang dalawang log nang magkatabi at hanapin ang unang pangyayaring hindi reset. Sa client, ang pagkabigo sa beripikasyon ng sertipiko ay iniuulat kasama ang tiyak na dahilan: nag-expire na sertipiko, hindi tugmang pangalan o hindi kilalang issuer. Sa server, ang pagtanggi sa kredensyal ay iniuulat bilang pagkabigo sa pagpapatotoo na may sariling dahilan. Pareho silang mas tiyak kaysa sa paulit-ulit na tingin ng server sa mga bagong pagtatangka.

Itugma ang isang pagtatangka ayon sa timestamp sa halip na basahin ang bawat log nang hiwalay, dahil lumilitaw ang parehong pagkabigo sa dalawang lugar na may ibang pananalita at ibang tindi. Karaniwang sinasabi ng kapares na sumusuko kung bakit.

Kung walang panig na nag-uulat ng pagtanggi at natigil pa rin ang palitan, ang hangganan ay maabot, hindi tiwala. Ang firewall na nagtatapon ng pabalik na direksyon, ang device sa pagsasalin ng network address na nag-expire ang mapping, o ang problema sa MTU na pumapatay sa mas malalaking handshake packet — lahat sila ay gumagawa ng natigil na palitan na walang anumang error sa pagpapatotoo.

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

Ang paghahanap na iyon ay hindi diyagnosis sa sarili nito, ngunit inililipat ka nito mula sa bokabularyo ng protocol tungo sa tunay na klase ng pagkabigo sa isang hakbang.

Bakit mali ang reflex na patayin ang beripikasyon

Kapag patuloy na lumilitaw ang reset, ang pinakamabilis na mukhang lunas ay patayin ang beripikasyon ng sertipiko o bitawan ang proteksyon ng control channel para may makakonekta. Ipinagpapalit nito ang pagkabigong maaaring ma-diyagnos sa hindi ma-diyagnos, at iniiwan ang deployment na tumatanggap ng mga kapares na itinayo itong tanggihan.

Palitan sa halip ang hangganang talagang nabigo. Ang problema sa tiwala ay pag-aari ng certificate authority at ng profile na tumutukoy dito. Ang problema sa oras ay pag-aari ng orasan. Ang problema sa kredensyal ay pag-aari ng backend ng pagpapatotoong tumanggi dito, at ang hindi maabot na kapares ay pag-aari ng landas sa pagitan ng dalawang host.

Ang opcode ay kapaki-pakinabang sa usapan sa suporta para sa isang bagay: sinasabi nito na umabot ang kapares sa sapat na layo upang subukan. Ang nangyari pagkatapos ay siyang kailangan mong malaman, at nakasulat ito sa alinmang log na nagtatala ng unang tiyak na pagtanggi. Magsimula doon, at ang linya ng reset ay hihinto sa pagmumukhang sanhi at magsisimulang magmukhang timestamp.