Test oporavka VPN servera nakon ponovnog pokretanja: šta prvo provjeriti

Ponovo pokrenite server dok niko nije prijavljen, a zatim se povežite s mreže koju ne kontrolišete. Taj jedan test odgovara da li je oporavak stvaran, jer tunel koji radi samo nakon što neko ručno pokrene komandu nije oporavak, to je popravka. Većina provjera stane prerano: demon pokazuje aktivan, interfejs se podiže, a stranica se ipak ne učitava. Razmak je gotovo uvijek u trajnosti dijelova oko tunela, a ne u samoj komandi tunela.

Četiri vlasnika, četiri različita testa

Prije restarta imenujte šta treba da vrati tunel. Test koji izvodite i popravka koju primjenjujete zavise od tog odgovora, a postoje četiri uobičajena vlasnika: systemd unit za VPN demon, unit wg-quick instance za WireGuard interfejs, kontejnerski runtime ili profil mrežnog menadžera. Ako ne možete imenovati vlasnika, zaustavite se i pronađite ga, jer test ponovnog pokretanja bez očekivane putanje pokretanja samo vam kaže da se nešto dogodilo.

Svaki vlasnik čuva svoju konfiguraciju na drugom mjestu. OpenVPN server kojim upravlja systemd čita konfiguraciju pri pokretanju, pa ono što je u datoteci pri dizanju sistema je ono što se izvršava. wg-quick interfejs izvodi adrese, rute i DNS iz iste datoteke, što znači da se interfejs podignut ručno iz školjke i nikada aktiviran kao unit neće vratiti. Kontejner vraća svoju ulaznu tačku, ali ne i promjene firewall-a na hostu, osim ako te promjene žive izvan kontejnera.

Prvo osnovno stanje, inače rezultat ništa ne znači

Zabilježite radno stanje dok radi: adrese na tunelu, rute za klijentsku podmrežu, NAT ili pravila prosljeđivanja, soket koji sluša i sysctl za prosljeđivanje. ip addr show wg0, ip route, nft list ruleset ili iptables-save, ss -lunp i sysctl net.ipv4.ip_forward dovoljni su na većini hostova.

Zabilježite kako je servis konfigurisan da se pokrene, a ne samo da radi. systemctl is-enabled wg-quick@wg0 i systemctl is-active wg-quick@wg0 odgovaraju na različita pitanja, a stanje aktivacije je ono koje je važno pri dizanju, kao što je opisano u systemctl(1). Za OpenVPN provjerite koji šablon host koristi, jer openvpn@server i openvpn-server@server su različiti uniti s različitim zadanim vrijednostima.

Izvedite restart i pročitajte prvi neuspjeh

Ponovo pokrenite namjerno, u prozoru koji ste odabrali, s otvorenom konzolom ili vanpojasnom putanjom. Posmatrajte redoslijed događaja, a ne konačno stanje: host dostupan, unit aktiviran, interfejs prisutan, rute instalirane, firewall pravila prisutna, slušalac vezan, klijent prihvaćen. Prvi korak koji se ne dogodi je nalaz; sve nakon njega je šum.

Demon može biti aktivan dok je tunel neupotrebljiv, i to je najčešći lažni prolaz. Pokretanje može završiti prije nego što je mreža online ako unit čeka samo network.target umjesto network-online.target. Referencirane datoteke kao što su certifikati, ključevi ili CRL mogu u tom trenutku biti nečitljive jer montaža ili putanja do tajni još nije spremna. Nijedan od tih problema ne prikazuje se u systemctl status dok ne pročitate dnevnik unita.

Testirajte izvan hosta. Klijent na istoj LAN mreži može uspjeti kroz rutu koju nijedan udaljeni klijent ne bi koristio, a SSH sesija na mašinu ništa ne dokazuje o tunelu. Povežite se, razriješite interno ime, dođite do privatnog resursa, pa se ponovo povežite jednom da potvrdite da stanje opoziva i ključevi još vrijede.

Tri uslova koja odlučuju o vašoj popravci

Ako se tunel vrati ali klijenti ne mogu ništa dohvatiti, neuspjeh je u rutiranju ili trajnosti NAT-a. Ako klijenti ne mogu ni dovršiti rukovanje, neuspjeh je u interfejsu ili materijalu za autentifikaciju. Ako se servis nikada ne pokrene, neuspjeh je u datoteci unita ili njegovim zavisnostima. Te tri grane vode do različitih popravki, zato slijepi restart bez osnovnog stanja košta više vremena nego što uštedi.

Izvršite popravku tamo gdje je postavka vlasništvo. Stavite prosljeđivanje u sysctl drop-in, stavite NAT pravila u skup pravila koji se učitava pri dizanju, aktivirajte unit umjesto da ga pokrećete, i držite tajne na putanji koja postoji prije nego što se unit pokrene. Dodavanje pauze u unit skriva zavisnost umjesto da je deklariše.

Zabilježite rezultat u runbook

Zapišite šta se vratilo samo, šta ste morali pokrenuti i koliko je razmak trajao. Uključite tačne komande koje ste koristili za provjeru, da sljedeća osoba ponovi test umjesto da izmišlja novi. Ako je neki korak zahtijevao ručnu komandu, ta komanda pripada konfiguraciji, a ne runbooku kao trajni korak.

Zatim zakažite sljedeći test za nakon sljedeće promjene mrežnog steka hosta, a ne za kalendarski datum za šest mjeseci. Način kvara od kojeg se štitite je privremena komanda koja se činila trajnom, a one se pojavljuju upravo kada neko uređuje firewall pravila ili premešta servis u novi unit.