Dir hutt eng Route oder eng Firewall-Regel geännert fir en Tunnel um Router ze testen, an elo äntwert d'Admin-Säit net méi vum Laptop, dee virun zéng Minutten nach ganz gutt funktionéiert huet. De Reflex ass, d'VPN ze beschëllegen. Meeschtens ass den Tunnel gesond an eng vun dräi aneren Saachen ass futti: keng Route zréck op d'Adress vum Router selwer, eng Input-Politik, déi d'Ufro verwërft, oder en Webservice, deen net op der Adress lauschtert, déi Dir urufft. All dräi gesinn am Browser d'selwecht aus, dofir starte Leit den Tunnel eng Stonn nei a léieren näischt.

Hei ass de Mythos, deen et wäert ass fir d'éischt ze maachen: en Tunnel, dee funktionéiert, ass kee Wee zréck eranzekommen. Et ass eng nei Netzwierkverbindung mat hirem eegene Vertrauensfroen, an et kann Ären ale Verwaltungswee onbemierkt ewechhuelen, während et en neien opmécht, deen keen iwwerpréift huet.

Den Tunnel war ni de Verwaltungswee

Viruleedung an Input sinn ënnerschiddlech Aarbechten. „Kann e Client iwwer den Tunnel d'NAS erreechen?“ ass eng Viruleedungsfro iwwer Paketen, déi duerch de Router ginn. „Kann ech den SSH-Port vum Router opmaachen?“ ass eng Input-Fro iwwer Paketen, déi un de Router selwer adresséiert sinn. Eng Erlaabnesregel, déi fir virugeluedenen Traffic geschriwwe gouf, mécht näischt fir déi zweet, an dat ass dee meeschten heefege Grond, firwat en Tunnel, deen Traffic perfekt dréit, nach ëmmer Är Admin-Sitzung refuséiert.

De Géigendeel-Fehler ass, engem Interface-Numm ze trauen. En Tunnel gëtt zum Peer verschlësselt, net zu all Service dohannert, an d'Wuert VPN an engem Interface-Label seet näischt driwwer, wéi eng Quellen sech sollten alogge kënnen.

Éischt Schicht: gëtt et eng Route op d'Adress vum Router selwer?

Fänkt um Client un a freet de Kernel, wou de Paket higeet. Op Linux dréckt ip route get 10.6.0.1 déi gewielte Route, den Ausgangsinterface an d'Quelladress. Wann et d'Standardroute a Richtung Ärem Provider mëscht, geet de Paket ni an den Tunnel, an keng Regel um Router kann et retten.

D'Tunnelsäit huet seng eege Versioun vun der Fro. WireGuard behandelt AllowedIPs als eng Krypto-Schlëssel-Routingtabell: op all Enn deklaréiert et, wéi eng Quelladressen e Peer benotze kann a wéi eng Destinatiounen un dee Peer geschéckt ginn. Wann d'Client-Andrag d'Tunneladress vum Router net enthält, huet de Client keng Route dohinner. Wann d'Server-Andrag fir dee Client d'Tunneladress vum Client net deckt, verwërft de Server de Paket, ier iergendeng Firewall-Regel consultéiert gëtt.

Bestätegt déi genau Adress, déi Dir wëllt erreechen, ier Dir d'Politik debuggt. En alen DNS-Record oder en gecchedten Noper-Andrag vun virun der Ännerung schéckt Iech op eng Adress, déi de Router ni hat.

Zweet Schicht: d'Input-Politik, net d'Viruleedungspolitik

Firewalle bewäerten Regele um Interface, op deem de Paket ukënnt. Op pfSense an OPNsense entscheeden den Interface-Tab an d'Reiefolleg vun de Reegelen, ob Traffic zu de Services vun der Firewall selwer erlaabt ass; eng Regel, déi LAN-Cliente fort an den Internet léisst, ass keng Regel, déi engem Tunnel-Peer d'Web-GUI opmécht. Op OpenWrt mat firewall4 dréit all Zon eng Input-Politik, option input 'ACCEPT' oder 'REJECT', an en Tunnel-Interface an enger Zon mat Input REJECT refuséiert Verwaltungsverbindungen, während et Traffic nach viruleet, wann d'Viruleedung erlaabt ass.

Deaktivéiert net d'Anti-Lockout-Regel, fir deen neie Wee schaffen ze loossen. Déi Regel verhënnert, datt eng schlecht Regel d'LAN-Verwaltungsadress späert; si schützt d'LAN-Subnetz, net d'Tunnel-Subnetz, déi Dir just ugeluecht hutt. Füügt eng schmuel Regel fir d'Quell vum Administrateur bäi a loosst de Sécherheetsnetz a Rou. D'pfSense Dokumentatioun zum Admin-Zougang erkläert, wou déi Kontrollen ze fannen ass.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Drëtt Schicht: lauschtert iergendeppes op där Adress?

E Service kann lafen an nach ëmmer onereechbar sinn, well en un eng eenzeg Adress gebonnen ass. OpenWrt seng uhttpd hält explizit Listener-Andräg an /etc/config/uhttpd, zum Beispill list listen_http '0.0.0.0:80'; e Build, dee sech nëmmen un d'LAN-Adress bind, acceptéiert näischt op der Tunneladress, a Produkter, déi eng Astellung fir den Listener-Interface weisen, behuelen sech gläich. D'Listener-Befehler uewendriwwer äntweren dat direkt.

Dann trennt d'Oflehnung vun der Stille. nc -vz 10.6.0.1 443, dee refuséierte Verbindung zréckgëtt, heescht, datt de Paket de Router erreecht huet an eppes en ofgelehnt huet, entweder en zouenen Port oder eng explizit Oflehnungsregel. Hängelen bis zum Timeout heescht, datt de Paket verworf oder ni gerout gouf. Dee Ënnerscheed seet Iech, wéi eng Schicht Dir als nächst kuckt, an et kascht fënnef Sekonnen.

En VPN-Interface ass eng Grenz, keen Erhuelungswee

Verschlësselung schützt de Kabel; si seet näischt driwwer, wien d'Admin-Säit dierf opmaachen. Wann den Tunnel schafft, widersetzt Iech dem Impuls, d'Erreechbarkeet ze léisen, andeems Dir um Tunnel-Interface alles erlaabt. Gitt den Administrateuren eng Regel, déi un hir eege Tunneladress gebonnen ass, oder en eegene just-Admin-Tunnel, a hält gewéinlech Benotzer, d'NAS, d'Kameraen an d'Familljelaptopen vum Verwaltungsport ewech. E Peer, deen eng Fichèreedelung brauch, sollt net eng Regel vum Login um Router ewech sinn.

D'Roll vum Router ännert d'Äntwert. E Router, deen den Tunnel terminéiert, kann Administrateuren legitim vun him unhuelen, während e Router, deen den Tunnel nëmmen als Internetausgang benotzt, dat normalerweis net soll. An deenen zwou Fäll ass d'Subnetz-Erlaabnes net de Login, also loosst Kont-Authentifikatioun an Transport-Sécherheet ageschalt.

De Kompensatiounsschratt, deen d'Leit no engem Lockout maachen, ass schléchter: WAN-Verwaltung aschalten oder e Port op d'Web-GUI viruleeden. Dat mécht aus engem kuerzen Ausfall eng dauerhaft Expositioun, an d'Loginsäit ass dann fir all Scanner am Internet erreechbar. Test och déi refuséiert Säit, net nëmmen déi erlaabt, sou datt e Peer, deen keen Admin-Zougang soll hunn, en Timeout oder eng Oflehnung kritt, amplaz eng Login-Ufro.

Test och mat enger fräscher Verbindung. Eng zustandsbehaft Firewall hält bestoend Flëss an hirer Zustandstabell, dofir kann d'SSH-Sitzung, déi Dir schonn op hutt, eng Ännerung iwwerliewen, déi all nei Verbindung blockéiert. Sou bleift e Lockout onsiichtbar bis zum nächsten Neistart oder dem nächste Schlof vum Laptop.

Bereet de Wee zréck vir, ier Dir d'Politik beréiert

Schreift véier Saachen op virun der éischter Ännerung: wéi Dir d'Apparat erreecht, wann den Tunnel stierft, zum Beispill eng seriell Konsole, eng Provider-Konsole oder eng Maschinn am LAN; wou déi aktuell Konfiguratioun exportéiert gëtt; wéi eng eenzeg Regel oder Route Dir ännere wëllt; an wéi Dir genau dee Punkt zréckrollt. Op OpenWrt hëlt sysupgrade -b /tmp/backup.tar.gz d'Konfiguratioun op, an Ännerungen bleiwen ausstoend bis uci commit, wat Iech e billeg Undoen gëtt, wann Dir et rechtzäiteg merkt. pfSense hält eng Konfiguratiounshistorie, an AutoConfigBackup hëlleft nëmmen, wann et schonn ageschalt war. Wann de Router e fail-closed Regelwierk lafe léisst, bestätegt, datt de geplangte Wartungswee net an deem Traffic läit, deen dës Regel blockéiert, a denkt drun, datt en Neistart dauerhaft Reegelen erëm uwent amplaz se ze läschen.

Ännert eng Grenz pro Versuch a test dann vun enger neier Verbindung amplaz vun der Shell, déi Dir oppen hält. Wann den Test feelt, hëlt déi eng Ännerung zréck, ier Dir déi nächst Schicht beréiert. Den Tunnel kann déi ganz Zäit uewen bleiwen, awer säin gréngen Status-Ikon ass kee Beweis, datt Dir nach erakommt.

Séierschnellkontroll ier Dir fortgeet:

  • Kënnt Dir de Router vun enger Quell erreechen, déi net vun der Regel ofhängt, déi Dir just geännert hutt?
  • Erlaabt d'Input-Politik um Tunnel-Interface nëmmen d'Quell vum Administrateur?
  • Ass de Verwaltungsservice un eng Adress gebonnen, déi um Tunnel existéiert?
  • Hutt Dir ee refuséierte Peer an eng frësch Sitzung getest?
  • Ass d'WAN-Verwaltungsoberfläch nach ëmmer zou?

Ähnlech Artikelen