Ang keepalive ay hindi reconnect: pumili ayon sa failure na mayroon ka

Ang keepalive at reconnect ay kino-configure sa isang hininga ngunit nilulutas ang magkaibang problema, kaya bihirang ayusin ng pag-tune ng isa ang isa pa. Ang keepalive ay nagpapadala ng maliit na trapiko upang panatilihing buhay ang isang entry ng estado o mapansin na tumigil nang sumagot ang isang peer. Ang reconnect ay ginigiba ang sira at muling itinatayo ang ugnayan, kasama ang mga key, address at ruta. Piliin ang mekanismong tumutugma sa failure, hindi ang alam mo nang hawakan. Dalawang tanong ang nagpapasya: patay na ba ang landas, o may nakakalimot nito sa pagitan ng mga peer?

Kapag ang mapping ang problema

Ang tunnel na namamatay lamang pagkatapos ng mga minutong katahimikan ay karaniwang nawawalan ng entry ng pagsasalin at hindi ng peer. Ang opsyong PersistentKeepalive sa WireGuard ay umiiral para sa estado ng NAT at firewall, at inilalarawan ito ng sariling mga tala ng proyekto nang ganoon, hindi bilang pagsusuri ng kalusugan. Ang pagitan ng ilang sampung segundo ay nagpapanatili ng entry na mainit, habang ang isang packet bawat segundo ay desisyon sa baterya at hindi sa pagiging maaasahan. OpenVPN ay dumarating sa parehong lugar ping at ping-restart sa pamamagitan ng, na unang napapansin ang katahimikan at pagkatapos ay kumikilos dito.

Ang mga setting na ito ay hindi rin mapagpapalit sa pagitan ng mga protocol. Ang patakaran ng patay na peer ng IKEv2, ang ping timer ng OpenVPN at ang keepalive ng WireGuard ay sumasagot sa parehong tanong gamit ang tatlong magkaibang sintaks at tatlong magkaibang default, kaya ang pagkopya ng numero sa pagitan nila ay haka-hakang nakadamit ng pag-tune.

Kapag wala na ang ugnayan

Kung magbabago ng address ang peer, mag-e-expire ang kredensyal o mag-restart ang malayong dulo, ang maliliit na packet ay hindi ang pagkukumpuni. Kailangang muling itayo ng reconnect ang estado : kumuha ng address, muling i-install ang mga ruta, muling makipag-negosasyon sa mga key at sa ilang deployment ay muling i-authenticate ang isang user.

Ang mga client na muling kumokonekta nang walang pagmamatyag ay may hawak na sertipiko o nakatagong lihim. Ang client na magtatanong sa tao ay nabibigo kapag walang sinuman, at iyon ang sitwasyon kung saan mahalaga ang reconnect. Iyon ay desisyong disenyo na ginawa maraming buwan ang nakalipas, hindi setting na mababago mo habang may outage.

Ang hindi pinapatunayan ng alinman

Ang tunnel ay maaaring nakareconnect, may mga key at ruta, habang down ang serbisyo sa likod nito, at ang keepalive ay maaaring magpanatili ng mapping na bukas para sa session na ang server ay wala nang ilang oras. Ang parehong mekanismo ay maaaring mag-ulat ng tagumpay habang ang talagang mahalaga sa iyo ay hindi available.

Kaya nagtatapos ang pagsubok sa isang tunay na kahilingan. Magpadala ng isang bagay sa tunnel pagkatapos ng pagitan na mahalaga sa iyo, pagkatapos ay hiwalay na pukawin ang failure na dinisenyo mo: panahon ng walang ginagawa para sa kaso ng mapping, restart o pagbabago ng address para sa kaso ng reconnect.

Ang pagharang sa direktang trapiko ay hiwalay na desisyon

Ang reconnect loop ay maaaring ganap na malusog habang tahimik na gumagamit ang isang application ng ordinaryong ruta, at iyon ay pagtagas at hindi failure. Kung ang hinihingi ay walang lumabas sa labas ng tunnel, sabihin ito nang malinaw sa configuration ng client at patunayan sa pamamagitan ng pagbaba ng tunnel at pagtingin sa kung ano pa ang kumokonekta. Wala sa dalawang mekanismo ang nagpapahiwatig ng ganoong pag-uugali, at walang disiplina sa pag-uulit ang nagtatatag nito.

Itala kung aling mekanismo ang tumakbo at kung nagtagumpay ang bagong kahilingan pagkatapos. Ang dalawang katotohanang iyon ang kailangan ng susunod na inhinyero, at wala sa kanila ang nakikita sa icon ng estado. Ang log line na nagsasabing nagreconnect ang client ay hindi kapareho ng kahilingang gumana.

Isulat ang patakaran, hindi lamang ang numero

Ilagay ang pares sa isang pangungusap: ang pagitan ng walang ginagawa, ang hangganan ng buhay, ano ang nagpapasimula ng muling pagtatayo , at ano ang ginagawa ng client habang nag-uulit. Kung wala ang pangungusap na iyon, binubuksan muli ng bawat susunod na insidente ang parehong pagtatalo kung masyadong maikli ang keepalive o masyadong mabagal ang reconnect.

Ang mga tala ng WireGuard tungkol sa mga limitasyon ay kapaki-pakinabang na paalala na ang keepalive ay paraan ng pag-iwas para sa mga middlebox at hindi pangkalahatang disenyo ng buhay. Basahin ang limitasyong iyon bago taasan ang dalas bilang tugon sa problemang hindi nito malulutas.