Testi la rekuperon de VPN-servilo post restartigo: kion kontroli unue

Restartigu la servilon dum neniu estas ensalutinta, poste konektiĝu de reto, kiun vi ne kontrolas. Tiu ununura testo respondas, ĉu la rekupero estas reala, ĉar tunelo, kiu funkcias nur post kiam iu rulas komandon permane, ne estas rekupero, ĝi estas riparo. Plej multaj kontroloj haltas tro frue: la demono montriĝas aktiva, la interfaco aperas, kaj la paĝo tamen ne ŝargiĝas. La manko estas preskaŭ ĉiam en la daŭreco de la pecoj ĉirkaŭ la tunelo, ne en la tunela komando mem.

Kvar posedantoj, kvar malsamaj testoj

Antaŭ la restartigo, nomu tion, kio devus revenigi la tunelon. La testo, kiun vi rulas, kaj la riparo, kiun vi aplikas, ambaŭ dependas de tiu respondo, kaj ekzistas kvar kutimaj posedantoj: systemd-unuo por la VPN-demono, unuo de wg-quick-instanca por WireGuard-interfaco, uja runtime, aŭ profilo de retadministrilo. Se vi ne povas nomi la posedanton, haltu kaj trovu ĝin, ĉar restartiga testo sen atendata startovojo nur diras al vi, ke io okazis.

Ĉiu posedanto tenas sian agordon aliloke. systemd-administrata OpenVPN-servilo legas sian agordon ĉe starto, do tio, kio estas en la dosiero ĉe la ekfunkciigo, estas tio, kio ruliĝas. wg-quick-interfaco derivas siajn adresojn, vojojn kaj DNS el la sama dosiero, kio signifas, ke interfaco levita permane el ŝelo kaj neniam ŝaltita kiel unuo ne revenos. Ujo revenigas sian enirpunkton, sed ne la fajroŝirmilajn ŝanĝojn de la gastiganto, krom se tiuj vivas ekster la ujo.

Unue bazlinio, alie la rezulto signifas nenion

Registru la funkciantan staton dum ĝi funkcias: adresoj sur la tunelo, vojoj por la klienta subreto, NAT aŭ plusendaj reguloj, la aŭskultanta soketo, kaj la plusenda sysctl. ip addr show wg0, ip route, nft list ruleset aŭ iptables-save, ss -lunp kaj sysctl net.ipv4.ip_forward sufiĉas sur plej multaj gastigantoj.

Registru, kiel la servo estas agordita por starti, ne nur ke ĝi funkcias. systemctl is-enabled wg-quick@wg0 kaj systemctl is-active wg-quick@wg0 respondas malsamajn demandojn, kaj la ŝaltita stato estas tiu, kiu gravas ĉe ekfunkciigo, kiel priskribite en systemctl(1). Por OpenVPN, kontrolu, kiun ŝablonon la gastiganto uzas, ĉar openvpn@server kaj openvpn-server@server estas malsamaj unuoj kun malsamaj defaŭltoj.

Rulu la restartigon kaj legu la unuan malsukceson

Restartigu intence, dum fenestro, kiun vi elektis, kun malfermita konzolo aŭ ekstrabenda vojo. Observu la ordon de la eventoj anstataŭ la finan staton: gastiganto atingebla, unuo ŝaltita, interfaco ĉeesta, vojoj instalitaj, fajroŝirmilaj reguloj ĉeestaj, aŭskultanto ligita, kliento akceptita. La unua paŝo, kiu ne okazas, estas la trovaĵo; ĉio post ĝi estas bruo.

Demono povas esti aktiva dum la tunelo estas neuzebla, kaj tio estas la plej ofta falsa sukceso. Starto povas finiĝi antaŭ ol la reto estas enlinea, se la unuo atendas nur network.target anstataŭ network-online.target. Referencitaj dosieroj kiel atestiloj, ŝlosiloj aŭ CRL povas esti nelegeblaj en tiu momento, ĉar muntado aŭ kaŝita vojo ankoraŭ ne pretas. Neniu el la du problemoj montriĝas en systemctl status ĝis vi legos la taglibron de la unuo.

Testu de ekster la gastiganto. Kliento en la sama LAN povas sukcesi per vojo, kiun neniu fora kliento iam uzus, kaj SSH-sesio al la maŝino pruvas nenion pri la tunelo. Konektiĝu, solvu internan nomon, atingiu la privatan rimedon, poste rekonektiĝu unufoje por konfirmi, ke la revoka stato kaj la ŝlosiloj ankoraŭ validas.

La tri kondiĉoj, kiuj decidas vian riparon

Se la tunelo revenas sed klientoj atingas nenion, la malsukceso estas en enkursigo aŭ NAT-daŭreco. Se klientoj eĉ ne povas fini manpremon, la malsukceso estas en la interfaco aŭ en la aŭtentiga materialo. Se la servo neniam startas, la malsukceso estas en la unua dosiero aŭ ĝiaj dependecoj. Tiuj tri branĉoj kondukas al malsamaj riparoj, kaj tial blinda restartigo sen bazlinio kostas pli da tempo ol ĝi ŝparas.

Faru la riparon tie, kie la agordo estas posedata. Metu plusendadon en sysctl-drop-in, metu NAT-regulojn en la regulan aron, kiu ŝargiĝas ĉe ekfunkciigo, ŝaltu la unuon anstataŭ starti ĝin, kaj tenu sekretojn sur vojo, kiu ekzistas antaŭ ol la unuo startas. Aldoni dormon al la unuo kaŝas dependecon anstataŭ deklari ĝin.

Registru la rezulton en la runbook

Skribu, kio revenis per si mem, kion vi devis starti, kaj kiom longe la manko daŭris. Inkluzivu la ĝustajn komandojn, kiujn vi uzis por kontroli, por ke la sekva persono ripetu la teston anstataŭ elpensi unu. Se iu paŝo bezonis permanan komandon, tiu komando apartenas al la agordo, ne al la runbook kiel daŭra paŝo.

Poste planu la sekvan teston por post la sekva ŝanĝo en la reta stako de la gastiganto, ne por kalendara dato ses monatojn poste. La malsukcesa reĝimo, kontraŭ kiu vi gardas, estas provizora komando, kiu sentiĝis daŭra, kaj tiuj aperas ĝuste kiam iu redaktas fajroŝirmilajn regulojn aŭ movas servon al nova unuo.