Waarom die router se admin ophou antwoord ná 'n VPN-verandering

Jy het 'n roete of 'n firewall-reël verander om 'n tonnel op die router te toets, en nou antwoord die admin-bladsy nie vanaf die skootrekenaar wat tien minute gelede nog reg gewerk het nie. Die refleks is om die VPN te blameer. Meestal is die tonnel gesond en het een van drie ander dinge gebreek: geen roete terug na die router se eie adres nie, 'n insetbeleid wat die versoek laat val, of 'n webdiens wat nie op die adres luister wat jy oproep nie. Al drie lyk dieselfde in die blaaier, en daarom herbegin mense 'n uur lank die tonnel en leer niks.

Hier is die mite wat eerste doodgemaak moet word: 'n werkende tonnel is nie 'n manier om weer in te kom nie. Dit is 'n nuwe netwerkverbinding met sy eie vertrouevrae, en dit kan jou ou bestuurspad stilweg verwyder terwyl dit 'n nuwe een oopmaak wat niemand nagegaan het nie.

Die tonnel was nooit die bestuurspad nie

Deurstuur en inset is verskillende take. "Kan 'n kliënt die NAS deur die tonnel bereik?" is 'n deurstuurvraag oor pakkette wat deur die router beweeg. "Kan ek die router se SSH-poort oopmaak?" is 'n insetvraag oor pakkette wat aan die router self gerig is. 'n Deurlaatreël wat vir deurgestuurde verkeer geskryf is, doen niks vir die tweede nie, en dit is die algemeenste rede waarom 'n tonnel wat verkeer perfek dra, steeds jou admin-sessie weier.

Die omgekeerde fout is om 'n koppelvlaknaam te vertrou. 'n Tonnel word na die eweknie geënkripteer, nie na elke diens daar agter nie, en die woord VPN in 'n koppelvlaketiket sê niks oor watter bronne mag aanmeld nie.

Laag een: is daar 'n roete na die router se eie adres?

Begin op die kliënt en vra die kernel waarheen die pakket sal gaan. Op Linux druk ip route get 10.6.0.1 die gekose roete, die uitgaande koppelvlak en die bronadres. As dit die verstekroete na jou ISP rapporteer, betree die pakket nooit die tonnel nie, en geen reël op die router kan dit red nie.

Die tonnelkant het sy eie weergawe van die vraag. WireGuard behandel AllowedIPs as 'n kriptosleutel-roeteringstabel: aan elke kant verklaar dit watter bronadresse 'n eweknie mag gebruik en watter bestemmings na daardie eweknie gestuur word. As die kliëntinskrywing nie die router se tonneladres insluit nie, het die kliënt geen roete daarvoor nie. As die bediener se inskrywing vir daardie kliënt nie die kliënt se tonneladres dek nie, laat val die bediener die pakket voordat enige firewall-reël geraadpleeg word.

Bevestig die presiese adres wat jy verwag om te bereik voordat jy beleid ontfout. 'n Verouderde DNS-rekord of 'n gekasde buurrekord van voor die verandering stuur jou na 'n adres wat die router nooit besit het nie.

Laag twee: die insetbeleid, nie die deurstuurbeleid nie

Firewalls evalueer reëls op die koppelvlak waar die pakket aankom. Op pfSense en OPNsense bepaal die koppelvlak-oortjie en die reëlvolgorde of verkeer na die firewall se eie dienste toegelaat word; 'n reël wat LAN-kliënte na die internet laat gaan, is nie 'n reël wat 'n tonnel-eweknie die web-GUI laat oopmaak nie. Op OpenWrt met firewall4 dra elke sone 'n insetbeleid, option input 'ACCEPT' of 'REJECT', en 'n tonnelkoppelvlak in 'n sone met inset REJECT weier bestuursverbindings terwyl dit steeds verkeer deurstuur as deurstuur toegelaat word.

Moenie die teenuitsluit-reël deaktiveer om die nuwe pad te laat werk nie. Daardie reël verhoed dat die LAN-bestuursadres deur 'n slegte reël uitgesluit word; dit beskerm die LAN-subnet, nie die tonnel-subnet wat jy pas geskep het nie. Voeg een smal reël vir die administrateur-bron by en los die veiligheidsnet alleen. Die pfSense dokumentasie oor admin-toegang verduidelik waar daardie beheermaatreëls is.

# 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

Laag drie: luister enigiets op daardie adres?

'n Diens kan loop en steeds onbereikbaar wees omdat dit aan een adres gebind is. OpenWrt se uhttpd hou eksplisiete luisterinskrywings in /etc/config/uhttpd, byvoorbeeld list listen_http '0.0.0.0:80'; 'n bou wat net aan die LAN-adres bind, aanvaar niks op die tonneladres nie, en produkte met 'n luisterkoppelvlak-instelling werk dieselfde. Die luisteropdragte hierbo antwoord dit direk.

Skei dan weiering van stilte. nc -vz 10.6.0.1 443 wat 'n geweierde verbinding teruggee, beteken die pakket het die router bereik en iets het dit verwerp, hetsy 'n geslote poort of 'n eksplisiete verwerpingsreël. 'n Hang tot tydsverloop beteken die pakket is laat val of nooit gerouteer nie. Daardie onderskeid sê vir jou watter laag volgende ondersoek moet word, en dit kos vyf sekondes.

'n VPN-koppelvlak is 'n grens, nie 'n herstelpad nie

Enkripsie beskerm die draad; dit sê niks oor wie die admin-bladsy mag oopmaak nie. Sodra die tonnel werk, weerstaan die drang om bereikbaarheid op te los deur alles op die tonnelkoppelvlak toe te laat. Gee administrateurs 'n reël wat aan hulle eie tonneladres gekoppel is of 'n aparte administrateur-only tonnel, en hou gewone gebruikers, die NAS, die kameras en die familie se skootrekenaars weg van die bestuursport. 'n Eweknie wat 'n lêerdeling nodig het, moet nie een reël van die router se aanmelding af wees nie.

Die router se rol verander die antwoord. 'n Router wat die tonnel termineer, mag administrateurs wettig daaruit aanvaar, terwyl 'n router wat die tonnel net as internetuitgang gebruik, dit gewoonlik nie moet doen nie. In beide gevalle is die subnet-toelating nie die aanmelding nie, so hou rekeningverifikasie en vervoersekuriteit geaktiveer.

Die vergoedende skuif wat mense ná 'n uitsluiting maak, is erger: WAN-administrasie aktiveer of 'n poort na die web-GUI deurstuur. Dit verander 'n kort onderbreking in 'n permanente blootstelling, en die aanmeldbladsy is dan vir elke skandeerder op die internet bereikbaar. Toets ook die geweierde kant, nie net die toegelate kant nie, sodat 'n eweknie wat nie admin-toegang behoort te hê nie, uittyd of geweier word in plaas daarvan om 'n aanmeldprompt te kry.

Toets ook met 'n vars verbinding. 'n Toestandvolle firewall hou bestaande strome in sy toestandtabel, so die SSH-sessie wat jy reeds oop het, kan 'n verandering oorleef wat elke nuwe verbinding blokkeer. Dis hoe 'n uitsluiting onsigbaar bly tot die volgende herbegin of die volgende slaap van die skootrekenaar.

Berei die pad terug voor jy aan beleid raak

Skryf vier dinge neer voor die eerste verandering: hoe jy die toestel sal bereik as die tonnel sterf, soos 'n serie-konsole, 'n verskaffer-konsole of 'n masjien op die LAN; waar die huidige konfigurasie uitgevoer word; watter enkele reël of roete jy op die punt is om te wysig; en hoe jy presies daardie item sal terugrol. Op OpenWrt neem sysupgrade -b /tmp/backup.tar.gz die konfigurasie vas, en wysigings bly hangend tot uci commit, wat jou 'n goedkoop ontskakeling gee as jy betyds oplet. pfSense hou 'n konfigurasiegeskiedenis, en AutoConfigBackup help net as dit reeds geaktiveer is. As die router 'n fail-closed reëlstel het, bevestig dat die onderhoudspad wat jy beplan het nie binne die verkeer is wat daardie reël blokkeer nie, en onthou dat 'n herbegin aanhoudende reëls weer toepas eerder as om hulle te skrap.

Verander een grens per poging en toets dan vanaf 'n nuwe verbinding eerder as die dop wat jy oophou. As die toets misluk, rol daardie een verandering terug voordat jy die volgende laag aanraak. Die tonnel kan die hele tyd op bly, maar sy groen statusikoon is nie bewys dat jy nog kan inkom nie.

Vinnige kontrole voordat jy wegstap:

• Kan jy die router bereik vanaf 'n bron wat nie van die reël wat jy pas gewysig het afhang nie?
• Laat die insetbeleid op die tonnelkoppelvlak net die administrateur-bron toe?
• Is die bestuursdiens gebind aan 'n adres wat op die tonnel bestaan?
• Het jy een geweierde eweknie en een vars sessie getoets?
• Is die WAN-administrasie-oppervlak steeds gesluit?