Pārstartējiet serveri, kamēr neviens nav pieteicies, un pēc tam pievienojieties no tīkla, kuru nekontrolējat. Šis viens tests atbild, vai atjaunošanās ir īsta, jo tunelis, kas darbojas tikai pēc tam, kad kāds manuāli izpilda komandu, nav atjaunošanās, bet gan remonts. Lielākā daļa pārbaužu apstājas pārāk agri: dēmons rādās aktīvs, saskarne paceļas, un lapa tomēr neielādējas. Atstarpe gandrīz vienmēr ir tuneli apņemošo daļu noturībā, nevis pašā tuneļa komandā.

Četri īpašnieki, četri dažādi testi

Pirms pārstartēšanas nosauciet, kam būtu jāatgriež tunelis. Tests, ko veicat, un labojums, ko piemērojat, abi ir atkarīgi no šīs atbildes, un ir četri ierasti īpašnieki: systemd vienība VPN dēmonam, wg-quick instances vienība WireGuard saskarnei, konteineru izpildlaiks vai tīkla pārvaldnieka profils. Ja nevarat nosaukt īpašnieku, apstājieties un atrodiet to, jo pārstartēšanas tests bez gaidītā starta ceļa tikai pasaka, ka kaut kas notika.

Katrs īpašnieks savu konfigurāciju glabā citur. systemd pārvaldīts OpenVPN serveris konfigurāciju nolasa starta laikā, tāpēc startā failā esošais ir tas, kas darbojas. wg-quick saskarne adreses, maršrutus un DNS iegūst no tā paša faila, kas nozīmē, ka saskarne, kas manuāli pacelta no čaulas un nekad nav iespējota kā vienība, neatgriezīsies. Konteiners atgriež savu ieejas punktu, bet ne ugunsmūra izmaiņas uz resursdatora, ja vien tās nedzīvo ārpus konteinera.

Vispirms bāzes stāvoklis, citādi rezultātam nav nozīmes

Fiksējiet darba stāvokli, kamēr tas darbojas: adreses tunelī, maršruti klienta apakštīklam, NAT vai pārraides noteikumi, klausošā ligzda un pārraides sysctl. ip addr show wg0, ip route, nft list ruleset vai iptables-save, ss -lunp un sysctl net.ipv4.ip_forward vairumā resursdatoru ir pietiekami.

Pierakstiet, kā pakalpojums ir konfigurēts startam, nevis tikai to, ka tas darbojas. systemctl is-enabled wg-quick@wg0 un systemctl is-active wg-quick@wg0 atbild uz dažādiem jautājumiem, un startā svarīgs ir tieši iespējotais stāvoklis, kā aprakstīts systemctl(1). Attiecībā uz OpenVPN pārbaudiet, kuru veidni resursdators izmanto, jo openvpn@server un openvpn-server@server ir dažādas vienības ar dažādām noklusējuma vērtībām.

Veiciet pārstartēšanu un nolasiet pirmo kļūdu

Pārstartējiet apzināti, jūsu izvēlētā logā, ar atvērtu konsoli vai ārpusjoslas ceļu. Vērojiet notikumu secību, nevis gala stāvokli: resursdators sasniedzams, vienība aktivizēta, saskarne ir, maršruti uzstādīti, ugunsmūra noteikumi ir, klausītājs piesaistīts, klients pieņemts. Pirmais solis, kas nenotiek, ir atradums; viss pēc tā ir troksnis.

Dēmons var būt aktīvs, kamēr tunelis nav lietojams, un tas ir visbiežākā nepareizā iziešana. Starts var pabeigties pirms tīkls ir tiešsaistē, ja vienība gaida tikai network.target, nevis network-online.target. Uzskaitītie faili, piemēram, sertifikāti, atslēgas vai CRL, tajā brīdī var būt nelasāmi, jo montāža vai noslēpumu ceļš vēl nav gatavs. Neviens no abiem problemām neparādās systemctl status, kamēr neizlasāt vienības žurnālu.

Pārbaudiet ārpus resursdatora. Klients tajā pašā LAN var gūt panākumus maršrutā, ko neviens attālināts klients nekad neizmantotu, un SSH sesija uz mašīnu neko nepierāda par tuneli. Pievienojieties, atrisiniet iekšējo nosaukumu, sasniedziet privāto resursu, pēc tam vēlreiz pievienojieties, lai apstiprinātu, ka atsaukšanas stāvoklis un atslēgas joprojām ir spēkā.

Trīs nosacījumi, kas nosaka jūsu labojumu

Ja tunelis atgriežas, bet klienti neko nesasniedz, kļūda ir maršrutēšanā vai NAT noturībā. Ja klienti pat nevar pabeigt rokasspiedienu, kļūda ir saskarnē vai autentifikācijas materiālā. Ja pakalpojums nekad nesākas, kļūda ir vienības failā vai tā atkarībās. Šie trīs zari ved pie dažādiem labojumiem, tāpēc akla pārstartēšana bez bāzes stāvokļa izmaksā vairāk laika, nekā ietaupa.

Veiciet labojumu tur, kur iestatījums pieder. Ielieciet pārraidi sysctl drop-in, ielieciet NAT noteikumus noteikumu kopā, kas ielādējas startā, iespējojiet vienību, nevis startējiet to, un glabājiet noslēpumus ceļā, kas pastāv pirms vienības starta. Miega pievienošana vienībai slēpj atkarību, nevis to deklarē.

Ierakstiet rezultātu runbook

Pierakstiet, kas atgriezās pats, kas jums bija jāstartē un cik ilgi atstarpe ilga. Iekļaujiet precīzās komandas, ko izmantojāt pārbaudei, lai nākamā persona atkārtotu testu, nevis izdomātu jaunu. Ja kādam solim bija vajadzīga manuāla komanda, šī komanda pieder konfigurācijai, nevis runbook kā pastāvīgam solim.

Pēc tam ieplānojiet nākamo testu pēc nākamās izmaiņas resursdatora tīkla stekā, nevis kalendāra datumam pēc sešiem mēnešiem. Kļūmes režīms, no kura sargājaties, ir pagaidu komanda, kas šķita pastāvīga, un tās parādās tieši tad, kad kāds rediģē ugunsmūra noteikumus vai pārvieto pakalpojumu uz jaunu vienību.

Saistītie raksti