Herstel fan VPN-server nei in werstart testen: wat earst te kontrolearjen

Werstart de server wylst nimmen oanmeld is, en ferbynje jo dan fan in netwurk dat jo net beheare. Dy iene test antwurdet oft it herstel echt is, want in tunnel dy't pas wurket neidat immen in opdracht mei de hân útfiert, is gjin herstel, it is in reparaasje. De measte kontrôles stopje te betiid: de tsjinst docht aktyf, de interface komt op, en de side laded noch hieltyd net. De kleau sit hast altyd yn it fuortbestean fan 'e stikken om 'e tunnel hinne, net yn 'e tunnelopdracht sels.

Fjouwer eigeners, fjouwer ferskate tests

Neam foar de werstart wat de tunnel werom bringe moat. De test dy't jo útfiere en de reparaasje dy't jo tapasse hingje beide fan dat antwurd ôf, en der binne fjouwer gewoane eigeners: in systemd-ienheid foar de VPN-tsjinst, in wg-quick-ynstânsje-ienheid foar in WireGuard-interface, in container-runtime, of in netwurkbehearderprofyl. As jo de eigener net neame kinne, stopje en sykje it, want in werstarttest sûnder ferwachte opstartpaad fertelt jo allinnich dat der wat bard is.

Elke eigener hâldt syn konfiguraasje earne oars. In systemd-beheard OpenVPN-server lêst syn konfiguraasje by it opstarten, dus wat by de boot yn it bestân stiet, dat rint. In wg-quick-interface ûntlient syn adressen, rûtes en DNS oan itselde bestân, wat betsjut dat in interface dy't mei de hân út in shell omheech brocht is en nea as ienheid ynskeakele is, net weromkomt. In container bringt syn yngongspunt werom, mar net de firewallferoarings fan 'e host, behalve as dy bûten de container libje.

Earst in basisline, oars betsjut it resultaat neat

Skriuw de wurkjende tastân op wylst er wurket: adressen op 'e tunnel, rûtes foar it kliïnt-subnet, NAT- of trochstjoerregels, de harkjende socket, en de trochstjoer-sysctl. ip addr show wg0, ip route, nft list ruleset of iptables-save, ss -lunp en sysctl net.ipv4.ip_forward binne op 'e measte hosts genôch.

Skriuw op hoe't de tsjinst konfigurearre is om te starten, net allinnich dat er rint. systemctl is-enabled wg-quick@wg0 en systemctl is-active wg-quick@wg0 beantwurdzje ferskate fragen, en de ynskeakele tastân is dejinge dy't by de boot telt, sa't beskreaun yn systemctl(1). Foar OpenVPN, kontrolearje hokker sjabloan de host brûkt, want openvpn@server en openvpn-server@server binne ferskate ienheden mei ferskate standertwearden.

Fier de werstart út en lês de earste flater

Werstart opsetlik, yn in finster dat jo keazen hawwe, mei in konsola of bûtenbânpaad iepen. Sjoch nei de folchoarder fan barrens ynstee fan 'e einstân: host berikber, ienheid aktivearre, interface oanwêzich, rûtes ynstallearre, firewallregels oanwêzich, harker bûn, kliïnt akseptearre. De earste stap dy't net bart, is de befinning; alles dêrnei is lûd.

In tsjinst kin aktyf wêze wylst de tunnel ûnbrûkber is, en dat is de meast foarkommende falske trochgong. It opstarten kin klear wêze foardat it netwurk online is as de ienheid allinnich op network.target wachtet ynstee fan network-online.target. Ferwiisde bestannen lykas sertifikaten, kaaien of in CRL kinne op dat stuit ûnlêsber wêze om't in mount of in geheime paad noch net klear is. Gjin fan beide problemen docht him sjen yn systemctl status oant jo it sjoernaal fan 'e ienheid lêze.

Test fan bûten de host. In kliïnt op itselde LAN kin slagje fia in rûte dy't gjin inkelde kliïnt op ôfstân ea brûke soe, en in SSH-sesje nei de masine bewiist neat oer de tunnel. Ferbynje jo, los in ynterne namme op, berik it privee-ryk, en ferbynje jo dan noch ien kear om te befêstigjen dat de ynlûkingsstatus en kaaien noch jilde.

De trije betingsten dy't jo reparaasje bepale

As de tunnel weromkomt mar kliïnten berikke neat, dan sit de flater yn 'e rûtebepaling of NAT-fuortbestean. As kliïnten sels gjin handshake ôfmeitsje kinne, sit de flater yn 'e interface of it autentikaasjemateriaal. As de tsjinst nea start, sit de flater yn it ienheidsbestân of syn ôfhinklikheden. Dy trije tûken liede ta ferskate reparaasjes, en dêrom kostet in bline werstart sûnder basisline mear tiid as er besparret.

Doch de reparaasje dêr't de ynstelling eigendom is. Set trochstjoeren yn in sysctl drop-in, set NAT-regels yn 'e regelbondel dy't by de boot lade, skeakelje de ienheid yn ynstee fan har te starten, en hâld geheimen op in paad dat bestiet foardat de ienheid start. In sliep tafoegje oan 'e ienheid ferberget in ôfhinklikheid ynstee fan har te ferklearjen.

Skriuw it resultaat yn it runbook

Skriuw op wat fan sels weromkaam, wat jo starte moasten en hoe lang't de kleau duorre. Nim de krekte opdrachten op dy't jo brûkten om te kontrolearjen, sadat de folgjende persoan de test werhellet ynstee fan in nije te betinken. As in stap in hânopdracht nedich hie, heart dy opdracht yn 'e konfiguraasje, net yn it runbook as in permaninte stap.

Plen dan de folgjende test foar nei de folgjende feroaring oan 'e netwurkstapel fan 'e host, net foar in kalinderdatum oer seis moannen. De flatermodus dêr't jo tsjin wachtsje is in tydlike opdracht dy't permanint field, en dy ferskine krekt as immen firewallregels bewurket of in tsjinst nei in nije ienheid ferpleatst.