Toets die herstel van die VPN-bediener ná herbegin: wat om eerste na te gaan
Herbegin terwyl niemand aangemeld is nie en maak dan van buite verbinding. Gaan die eenheid, koppelvlak, roetes en firewallreëls na wat vanself moet terugkeer.
Herbegin die bediener terwyl niemand aangemeld is nie en maak dan verbinding vanaf ’n netwerk wat jy nie beheer nie. Daardie enkele toets wys of herstel werklik is, want ’n tonnel wat eers werk nadat iemand met die hand ’n opdrag uitgevoer het, is nie herstel nie, dit is ’n herstelling. Die meeste kontroles stop te vroeg: die diens wys aktief, die koppelvlak wys op, en die bladsy laai steeds nie. Die gaping is byna altyd die blywendheid van die dele rondom die tonnel, nie die tonnelopdrag self nie.
Vier eienaars, vier verskillende toetse
Noem voor die herbegin wat die tonnel veronderstel is om terug te bring. Die toets wat jy uitvoer en die herstel wat jy toepas, hang albei van daardie antwoord af, en daar is vier algemene eienaars: ’n systemd-eenheid vir die VPN-diens, ’n wg-quick-instansie-eenheid vir ’n WireGuard-koppelvlak, ’n houerruntime, of ’n netwerkbestuurderprofiel. As jy nie die eienaar kan noem nie, stop en vind dit, want ’n herbegintoets sonder ’n verwagte opstartpad sê net vir jou dat iets gebeur het.
Elke eienaar hou sy konfigurasie op ’n ander plek. ’n systemd-bestuurde OpenVPN-bediener lees sy konfigurasie by die opstart, so wat ook al in die lêer is tydens die selflaai, is wat loop. ’n wg-quick-koppelvlak kry sy adresse, roetes en DNS uit dieselfde lêer, wat beteken dat ’n koppelvlak wat met die hand uit ’n dop opgebring is en nooit as ’n eenheid geaktiveer is nie, nie sal terugkeer nie. ’n Houer bring sy intreepunt terug, maar nie die gasheer se firewallveranderings nie, tensy dit buite die houer leef.
Eers ’n basislyn, anders beteken die uitslag niks
Teken die werkende toestand vas terwyl dit werk: adresse op die tonnel, roetes vir die kliëntsubnet, NAT- of deurvoerreëls, die luisterende sok, en die deurvoer-sysctl. ip addr show wg0, ip route, nft list ruleset of iptables-save, ss -lunp, en sysctl net.ipv4.ip_forward is op die meeste gashere genoeg.
Teken aan hoe die diens gekonfigureer is om te begin, nie net dat dit loop nie. systemctl is-enabled wg-quick@wg0 en systemctl is-active wg-quick@wg0 beantwoord verskillende vrae, en die geaktiveerde toestand is die een wat tydens selflaai saak maak, soos beskryf in systemctl(1). Vir OpenVPN, kyk watter sjabloon die gasheer gebruik, want openvpn@server en openvpn-server@server is verskillende eenhede met verskillende verstekke.
Voer die herbegin uit en lees die eerste fout
Herbegin doelbewus, gedurende ’n venster wat jy gekies het, met ’n konsole of buitebandpad oop. Let op die volgorde van gebeurtenisse eerder as die finale toestand: gasheer bereikbaar, eenheid geaktiveer, koppelvlak teenwoordig, roetes geïnstalleer, firewallreëls teenwoordig, luisteraar gebind, kliënt aanvaar. Die eerste stap wat nie gebeur nie, is die bevinding; alles daarna is geraas.
’n Diens kan aktief wees terwyl die tonnel onbruikbaar is, en dit is die algemeenste valse slaag. Die opstart kan voltooi voordat die netwerk aanlyn is as die eenheid net op network.target wag in plaas van network-online.target. Verwysde lêers soos sertifikate, sleutels of ’n CRL kan op daardie oomblik onleesbaar wees omdat ’n montering of ’n geheime pad nog nie gereed is nie. Nie een van die twee probleme wys in systemctl status voordat jy die joernaal vir die eenheid lees nie.
Toets van buite die gasheer. ’n Kliënt op dieselfde LAN kan deur ’n roete slaag wat geen afgeleë kliënt ooit sou gebruik nie, en ’n SSH-sessie na die masjien bewys niks oor die tonnel nie. Maak verbinding, los ’n interne naam op, bereik die private hulpbron, en maak dan weer een keer verbinding om te bevestig dat die herroepingstatus en sleutels steeds geld.
Die drie voorwaardes wat jou herstel bepaal
As die tonnel terugkeer maar kliënte niks kan bereik nie, is die fout in roetering of NAT-blywendheid. As kliënte nie eers ’n handdruk kan voltooi nie, is die fout in die koppelvlak of die outentiseringsmateriaal. As die diens nooit begin nie, is die fout in die eenheidslêer of sy afhanklikhede. Daardie drie takke lei na verskillende herstellings, en daarom kos ’n blinde herbegin sonder ’n basislyn meer tyd as wat dit bespaar.
Maak die herstel waar die instelling besit word. Sit deurvoer in ’n sysctl-drop-in, sit NAT-reëls in die reëlversameling wat tydens selflaai laai, aktiveer die eenheid eerder as om dit te begin, en hou geheime op ’n pad wat bestaan voordat die eenheid begin. Om ’n slaap by die eenheid te voeg, verberg ’n afhanklikheid in plaas daarvan om dit te verklaar.
Teken die uitslag in die runbook aan
Skryf neer wat vanself teruggekom het, wat jy moes begin, en hoe lank die gaping geduur het. Sluit die presiese opdragte in wat jy gebruik het om te verifieer, sodat die volgende persoon die toets herhaal in plaas van een te bedink. As enige stap ’n handopdrag nodig gehad het, hoort daardie opdrag in die konfigurasie, nie as ’n permanente stap in die runbook nie.
Skeduleer dan die volgende toets vir ná die volgende verandering aan die gasheer se netwerkstapel, nie vir ’n kalenderdatum ses maande vooruit nie. Die foutmodus waarteen jy waak, is ’n tydelike opdrag wat permanent gevoel het, en dit verskyn presies wanneer iemand firewallreëls wysig of ’n diens na ’n nuwe eenheid skuif.