Testoni rikuperimin e serverit VPN pas rinisjes: çfarë të kontrolloni së pari

Rinisni serverin pa qenë askush i identifikuar, pastaj lidhuni nga një rrjet që nuk e kontrolloni. Ky test i vetëm përgjigjet nëse rikuperimi është i vërtetë, sepse një tunel që funksionon vetëm pasi dikush ekzekuton një komandë me dorë nuk është rikuperim, është riparim. Shumica e kontrolleve ndalen shumë herët: shërbimi shfaqet aktiv, ndërfaqja ngrihet dhe faqja prapë nuk ngarkohet. Hendeku është pothuajse gjithmonë në këmbënguljen e pjesëve rreth tunelit, jo në vetë komandën e tunelit.

Katër pronarë, katër teste të ndryshme

Para rinisjes, emërtoni çfarë duhet ta kthejë tunelin. Testi që kryeni dhe rregullimi që aplikoni varen të dy nga ai përgjigje, dhe ka katër pronarë të zakonshëm: një njësi systemd për shërbimin VPN, një njësi instance wg-quick për një ndërfaqe WireGuard, një runtime kontejnerësh ose një profil menaxheri rrjeti. Nëse nuk mund ta emërtoni pronarin, ndaloni dhe gjeni atë, sepse një test rinisjeje pa një rrugë të pritur nisjeje ju thotë vetëm se diçka ndodhi.

Secili pronar e mban konfigurimin e tij diku tjetër. Një server OpenVPN i menaxhuar nga systemd e lexon konfigurimin në nisje, kështu që ajo që është në skedar në kohën e boot-it është ajo që ekzekutohet. Një ndërfaqe wg-quick i nxjerr adresat, rrugët dhe DNS-në nga i njëjti skedar, që do të thotë se një ndërfaqe e ngritur me dorë nga një shell dhe kurrë e aktivizuar si njësi nuk do të kthehet. Një kontejner e kthen pikën e hyrjes, por jo ndryshimet e firewall-it të hostit, përveçse kur ato jetojnë jashtë kontejnerit.

Së pari vija bazë, përndryshe rezultati nuk do të thotë asgjë

Regjistroni gjendjen funksionale ndërsa funksionon: adresat në tunel, rrugët për nënrrjetin e klientëve, rregullat NAT ose të përcjelljes, socket-i i dëgjimit dhe sysctl-i i përcjelljes. ip addr show wg0, ip route, nft list ruleset ose iptables-save, ss -lunp dhe sysctl net.ipv4.ip_forward mjaftojnë në shumicën e hosteve.

Regjistroni si është konfiguruar shërbimi për t'u nisur, jo vetëm që po funksionon. systemctl is-enabled wg-quick@wg0 dhe systemctl is-active wg-quick@wg0 i përgjigjen pyetjeve të ndryshme, dhe gjendja e aktivizuar është ajo që ka rëndësi në boot, siç përshkruhet në systemctl(1). Për OpenVPN, kontrolloni cilin shabllon përdor hosti, pasi openvpn@server dhe openvpn-server@server janë njësi të ndryshme me vlera të paracaktuara të ndryshme.

Kryeni rinisjen dhe lexoni dështimin e parë

Rinisni me qëllim, brenda një dritareje që keni zgjedhur, me një konsolë ose një rrugë jashtë brezit të hapur. Vëzhgoni rendin e ngjarjeve në vend të gjendjes përfundimtare: hosti i arritshëm, njësia e aktivizuar, ndërfaqja e pranishme, rrugët e instaluara, rregullat e firewall-it të pranishme, dëgjuesi i lidhur, klienti i pranuar. Hapi i parë që nuk ndodh është gjetja; gjithçka pas tij është zhurmë.

Një shërbim mund të jetë aktiv ndërsa tuneli është i papërdorshëm, dhe ky është kalimi i rremë më i zakonshëm. Nisja mund të përfundojë para se rrjeti të jetë online nëse njësia pret vetëm network.target në vend të network-online.target. Skedarët e referuar si certifikatat, çelësat ose një CRL mund të jenë të palexueshëm në atë moment sepse një montim ose një rrugë sekretesh nuk është gati ende. Asnjë nga të dy problemet nuk shfaqet në systemctl status derisa të lexoni ditarin e njësisë.

Testoni nga jashtë hostit. Një klient në të njëjtin LAN mund të ketë sukses përmes një rruge që asnjë klient në distancë nuk do ta përdorte ndonjëherë, dhe një sesion SSH në makinë nuk provon asgjë për tunelin. Lidhuni, zgjidhni një emër të brendshëm, arrini burimin privat, pastaj rilidhuni një herë për të konfirmuar që gjendja e revokimit dhe çelësat ende zbatohen.

Tre kushtet që vendosin rregullimin tuaj

Nëse tuneli kthehet por klientët nuk arrijnë asgjë, dështimi është në rrugëzim ose në këmbënguljen e NAT. Nëse klientët nuk mund të përfundojnë as një shtrëngim duarsh, dështimi është në ndërfaqe ose në materialin e vërtetimit. Nëse shërbimi nuk niset kurrë, dështimi është në skedarin e njësisë ose në varësitë e tij. Këto tre degë çojnë në rregullime të ndryshme, prandaj një rinisje e verbër pa vijë bazë kushton më shumë kohë sesa kursen.

Bëni rregullimin aty ku cilësimi është në pronësi. Vendosni përcjelljen në një sysctl drop-in, vendosni rregullat NAT në grupin e rregullave që ngarkohet në boot, aktivizoni njësinë në vend që ta nisni, dhe mbani sekretet në një rrugë që ekziston para se njësia të niset. Shtimi i një gjumi në njësi fsheh një varësi në vend që ta deklarojë atë.

Regjistroni rezultatin në runbook

Shkruani çfarë u kthye vetë, çfarë ju desh të nisni dhe sa zgjati hendeku. Përfshini komandat e sakta që përdorët për verifikim, që personi tjetër ta përsëritë testin në vend që të shpikë një të ri. Nëse ndonjë hap kërkonte një komandë manuale, ajo komandë i përket konfigurimit, jo runbook-ut si hap i përhershëm.

Pastaj planifikoni testin tjetër pas ndryshimit tjetër në stivën e rrjetit të hostit, jo për një datë kalendari gjashtë muaj më vonë. Mënyra e dështimit kundër së cilës mbroni veten është një komandë e përkohshme që dukej e përhershme, dhe ato shfaqen pikërisht kur dikush redakton rregullat e firewall-it ose zhvendos një shërbim në një njësi të re.