Nagbago ang WAN IP at bumagsak ang tunnel: ang mga pagsusuri sa pagkakasunod-sunod

Bumagsak ang tunnel, nag-log ang router ng muling pagkonekta, at walang gumalaw sa LAN. Binabalewala ng bagong WAN address ang panlabas na koneksyon nang walang binabago sa loob: nagbago ang source address ng kliyente, ang lumang NAT state ay tumuturo sa pinagmulang wala na, at ang malayong peer ay maaaring nagpapadala pa rin sa dating address. Ang pagbangon ay normal na pag-uugali, at ang kapaki-pakinabang na tanong ay aling estado ang nabigong ma-update.

Pangalanan ang kaganapan bago basahin ang log

Suriin kung ano talaga ang nangyari sa access layer. Ang pag-renew ng lease mula sa ISP ay isang kaganapan. Ang PPPoE session na muling kumonekta ay isa pa. Ang fiber modem na nag-reboot, o ang WAN failover mula sa isang uplink patungo sa isa pa, ay nagbabago ng panlabas na address o ng landas nito sa ikatlong paraan. Hindi sila ang parehong kaganapan at hindi sila nag-iiwan ng parehong latak.

Ang linyang muling pagkonekta sa VPN log ay hindi rin patunay ng pagbabago ng WAN. Ang idle timeout, agwat ng muling pagpapatunay at pagtuklas ng patay na peer ay lahat gumagawa ng muling pagkonekta nang walang anumang pagbabago ng address. Ihambing ang mga timestamp mula sa access log sa VPN log bago maghinuha ng anuman, at panatilihing sapat na malawak ang window ng paghahambing upang mahuli ang pagbabagong nangyari sa gabi.

Ang roaming at muling pagkonekta ay magkaibang protocol

May authenticated roaming na nakapaloob sa protocol ang WireGuard: kapag tumanggap ang peer ng tamang authenticated na packet mula sa bagong source address, ina-update nito ang endpoint ng peer na iyon. Inilalarawan ng Mabilisang pagsisimula ng WireGuard ang peer configuration na nagpapangyari nito, kaya madalas bumangon ang kliyente sa nagbabagong address nang walang nakikitang restart.

Iba ang kilos ng OpenVPN bilang default. Maaaring magtapos at muling kumonekta ang UDP session, at pinapayagan ng opsyonal na float behavior ang authenticated na peer na magpatuloy mula sa bagong address kung saan pinapayagan ng configuration. Ang mga tunnel na nakabatay sa TCP ay mas mahigpit, dahil ang koneksyon mismo ay nakatali sa pares ng address. Ang pagkakaibang iyon ang nagtatakda kung ang pagbangon ay mukhang hindi nakikita o nagpapahayag ng sarili sa log sa bawat pagkakataon.

Wala sa dalawang kilos ang nagsasabi tungkol sa mga aplikasyon sa loob. Ang nabangong tunnel ay hindi nagpapanumbalik ng TCP session na itinuring nang patay ng peer.

Estadong hindi pag-aari ng tunnel

Ang estado ng pagsasalin at pagruruta ay nakakaligtas sa muling pagkonekta sa mga paraang nakakagulat. Ang conntrack entry na ginawa para sa dating pinagmulan ay nagpapanatili sa landas ng tugon na nakaangkla sa address na wala na, at nag-expire ito ayon sa sarili nitong iskedyul, hindi noong bumalik ang tunnel. Ang pag-restart ng serbisyo ng tunnel ay hindi nagpapaikli sa paghihintay na iyon, kaya ang naayos na link ay maaaring mukhang sira pa rin nang ilang sandali.

Ang mga ruta at patakaran ng polisiya ay maaaring tumukoy sa dating gateway o interface. Ang set ng mga patakaran na tama bago ang pagbabago ng WAN ay maaaring tumuro sa device na sira na ngayon, na gumagawa ng tunnel na nag-uulat na konektado at trapikong hindi napupunta kahit saan. Ang dynamic DNS para sa server na hinohost mo ay hiwalay na problema sa kliyenteng nakakakuha ng bagong pinagmulan. Kailangang i-update ang record upang mahanap ka ng malalayong kliyente, at walang configuration sa panig ng kliyente ang makakabawi sa address na hindi ipapasa ng pagsasalin sa itaas.

Isaayos ang mga pagsusuri mula labas patungo loob

Ang pagkakasunod-sunod sa ibaba ay mula sa panlabas na koneksyon patungo loob, at ang paghinto sa unang hakbang na nabigo ang gumagawa nitong kapaki-pakinabang: ibinubukod ng bawat pagsusuri ang layer sa itaas nito. Panatilihin ang pagkakasunod-sunod na iyon kahit mukhang halata ang sira.

wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40

Ipinapakita ng unang utos ang kasalukuyang endpoint at edad ng handshake para sa bawat peer. Ipinapakita ng ikalawa at ikatlo kung may saysay pa ang panlabas na interface at ang ruta patungo sa endpoint. Ang bilang ng conntrack ay magaspang na pagsusuri ng estadong natira mula sa dating address, at ang journal ang lugar kung saan naitala ang dahilan ng muling pagkonekta.

Pagkatapos ay subukan mula sa isang kliyente ng LAN at hindi mula sa router. Ang ping na ipinadala mismo ng router ay gumagamit ng ibang landas kaysa sa trapikong ipinapasa, kaya ang matagumpay na ping mula sa router ay nagpapatunay na may tunnel at wala tungkol sa maabot ng kliyente.

Magpasya sa inaasahang pag-uugali at isulat ito

Ang muling pagkonekta ay tamang pag-uugali para sa karamihan ng deployment, kaya ang layunin ay hindi ito pigilan. Sa halip, magpasya kung ano ang dapat mangyari sa trapiko sa panahon ng agwat: ihinto ito, panatilihin ito, o lumipat sa ibang landas. Ang desisyong iyon ay pag-aari ng firewall at ng patakaran sa pagruruta, hindi ng profile ng VPN.

Itala nang magkasama ang mga kaganapan sa pag-access at ang mga oras ng muling pagkonekta sa loob ng isang linggo. Ang paulit-ulit na pagbabago na walang tugmang kaganapan sa pag-access ay tumuturo sa serbisyo ng pag-access, at ang pagpapalit ng profile ng VPN ay hindi mag-aayos ng uplink na patuloy na nakikipagnegosasyon. Ang isang pares ng entry sa parehong minuto ay nagtatapos sa tanong para sa insidenteng iyon at nagbibigay ng baseline sa susunod.