Subukan ang pagbawi ng VPN server pagkatapos ng reboot: ano ang unang titingnan

I-reboot ang server nang walang naka-log in, pagkatapos kumonekta mula sa isang network na hindi mo kontrolado. Ang nag-iisang pagsubok na ito ang sumasagot kung totoo ang pagbawi, dahil ang tunnel na gumagana lamang pagkatapos may magpatakbo ng utos nang manu-mano ay hindi pagbawi, ito ay pagkukumpuni. Karamihan ng pagsusuri ay masyadong maagang humihinto: aktibo ang itsura ng daemon, tumataas ang interface, at hindi pa rin naglo-load ang pahina. Ang agwat ay halos palaging nasa pagpapatuloy ng mga bahagi sa paligid ng tunnel, hindi sa utos ng tunnel mismo.

Apat na may-ari, apat na magkaibang pagsubok

Bago ang reboot, pangalanan kung ano ang dapat magbalik ng tunnel. Ang pagsubok na isinasagawa mo at ang pagwawastong inilalapat mo ay parehong nakadepende sa sagot na iyon, at may apat na karaniwang may-ari: isang systemd unit para sa serbisyo ng VPN, isang wg-quick instance unit para sa isang WireGuard interface, isang container runtime, o isang profile ng network manager. Kung hindi mo mapangalanan ang may-ari, huminto at hanapin ito, dahil ang pagsubok ng reboot na walang inaasahang landas ng pagsisimula ay nagsasabi lamang na may nangyari.

Bawat may-ari ay nag-iimbak ng kanyang configuration sa ibang lugar. Ang OpenVPN server na pinamamahalaan ng systemd ay nagbabasa ng configuration sa pagsisimula, kaya ang nasa file sa oras ng boot ang tumatakbo. Ang wg-quick interface ay kumukuha ng mga address, ruta at DNS mula sa parehong file, ibig sabihin, ang interface na itinaas nang manu-mano mula sa shell at hindi kailanman na-enable bilang unit ay hindi babalik. Ang container ay nagbabalik ng entrypoint nito ngunit hindi ang mga pagbabago sa firewall ng host, maliban kung ang mga iyon ay nasa labas ng container.

Baseline muna, kung hindi walang kahulugan ang resulta

Itala ang gumaganang estado habang gumagana ito: mga address sa tunnel, ruta para sa subnet ng kliyente, NAT o forwarding rules, ang socket na nakikinig, at ang forwarding sysctl. ip addr show wg0, ip route, nft list ruleset o iptables-save, ss -lunp at sysctl net.ipv4.ip_forward ay sapat sa karamihan ng host.

Itala kung paano naka-configure ang serbisyo upang magsimula, hindi lamang na ito ay tumatakbo. Ang systemctl is-enabled wg-quick@wg0 at systemctl is-active wg-quick@wg0 ay sumasagot sa magkaibang tanong, at ang naka-enable na estado ang mahalaga sa boot, gaya ng inilarawan sa systemctl(1). Para sa OpenVPN, suriin kung aling template ang ginagamit ng host, dahil ang openvpn@server at openvpn-server@server ay magkaibang unit na may magkaibang default.

Isagawa ang reboot at basahin ang unang pagkabigo

I-reboot nang sadya, sa loob ng window na pinili mo, nang bukas ang console o out-of-band na landas. Panoorin ang pagkakasunod-sunod ng mga pangyayari hindi ang huling estado: naaabot ang host, na-activate ang unit, naroon ang interface, naka-install ang ruta, naroon ang firewall rules, nakatali ang listener, natanggap ang kliyente. Ang unang hakbang na hindi nangyari ang natuklasan; lahat ng sumunod ay ingay.

Maaaring aktibo ang serbisyo habang hindi magamit ang tunnel, at ito ang pinakakaraniwang maling pagpasa. Maaaring matapos ang pagsisimula bago maging online ang network kung ang unit ay naghihintay lamang sa network.target sa halip na network-online.target. Ang mga file na tinutukoy tulad ng mga sertipiko, key o CRL ay maaaring hindi mabasa sa sandaling iyon dahil hindi pa handa ang isang mount o landas ng mga sikreto. Wala sa dalawang problema ang lumalabas sa systemctl status hanggang basahin mo ang journal ng unit.

Subukan mula sa labas ng host. Ang kliyente sa parehong LAN ay maaaring magtagumpay sa isang rutang hindi kailanman gagamitin ng anumang remote client, at ang SSH session sa makina ay walang pinatutunayan tungkol sa tunnel. Kumonekta, lutasin ang isang panloob na pangalan, maabot ang pribadong resource, pagkatapos kumonekta muli nang isang beses upang kumpirmahin na ang estado ng pagbawi at mga key ay nalalapat pa rin.

Ang tatlong kondisyon na nagpapasya sa iyong pagwawasto

Kung bumabalik ang tunnel ngunit walang naaabot ang mga kliyente, ang pagkabigo ay sa routing o pagpapatuloy ng NAT. Kung hindi man lang makumpleto ng mga kliyente ang handshake, ang pagkabigo ay sa interface o sa materyal ng authentication. Kung hindi kailanman nagsisimula ang serbisyo, ang pagkabigo ay sa file ng unit o sa mga dependency nito. Ang tatlong sangay na ito ay humahantong sa magkaibang pagwawasto, kaya ang bulag na reboot na walang baseline ay mas maraming oras ang kinakain kaysa natitipid.

Gawin ang pagwawasto kung saan pagmamay-ari ang setting. Ilagay ang forwarding sa isang sysctl drop-in, ilagay ang NAT rules sa rule set na naglo-load sa boot, i-enable ang unit sa halip na simulan ito, at itago ang mga sikreto sa landas na umiiral bago magsimula ang unit. Ang pagdaragdag ng sleep sa unit ay nagtatago ng dependency sa halip na ideklara ito.

Itala ang resulta sa runbook

Isulat kung ano ang kusang bumalik, ano ang kinailangan mong simulan, at gaano katagal ang agwat. Isama ang eksaktong mga utos na ginamit mo upang i-verify, upang ulitin ng susunod na tao ang pagsubok sa halip na mag-imbento ng bago. Kung ang anumang hakbang ay nangangailangan ng manu-manong utos, ang utos na iyon ay kabilang sa configuration, hindi sa runbook bilang permanenteng hakbang.

Pagkatapos, i-iskedyul ang susunod na pagsubok pagkatapos ng susunod na pagbabago sa network stack ng host, hindi para sa isang petsa sa kalendaryo anim na buwan mula ngayon. Ang failure mode na pinoprotektahan mo ay isang pansamantalang utos na parang permanente, at lumalabas ang mga iyon kapag may nag-edit ng firewall rules o naglilipat ng serbisyo sa bagong unit.