Miért hagy fel a router adminisztrációs felülete a válaszadással VPN-változás után

Módosított egy útvonalat vagy tűzfalszabályt, hogy alagutat teszteljen a routeren, és most az adminisztrációs oldal nem válaszol arról a laptopról, amely tíz perccel korábban még jól működött. A reflex az, hogy a VPN-t hibáztatjuk. Legtöbbször az alagút egészséges, és három másik dolog közül tört el egy: nincs visszaút a router saját címére, egy bemeneti házirend eldobja a kérést, vagy egy webszolgáltatás nem figyel azon a címen, amelyet hív. Mindhárom ugyanúgy néz ki a böngészőben, ezért az emberek egy órán át újraindítják az alagutat, és semmit sem tanulnak.

Íme a mítosz, amelyet érdemes először megölni: egy működő alagút nem visszavezető út. Új hálózati kapcsolat a saját bizalmi kérdéseivel, és csendesen eltávolíthatja a régi felügyeleti útvonalát, miközben olyan újat nyit, amelyet senki sem vizsgált meg.

Az alagút soha nem volt a felügyeleti útvonal

A továbbítás és a bemenet külön feladatok. „Elérheti egy kliens az NAS-t az alagúton keresztül?” továbbítási kérdés a routeren áthaladó csomagokról. „Megnyithatom a router SSH-portját?” bemeneti kérdés a magának a routernek címzett csomagokról. A továbbított forgalomra írt engedélyező szabály semmit nem tesz a második kérdésért, és ez a leggyakoribb oka annak, hogy egy tökéletesen forgalmat szállító alagút mégis elutasítja az adminisztrációs munkamenetet.

A fordított hiba az, ha egy interfésznévben bízunk. Az alagút a partnerhez van titkosítva, nem a mögötte lévő minden szolgáltatáshoz, és az interfészcímkében szereplő VPN szó semmit nem mond arról, mely forrásoknak szabad bejelentkezniük.

Első réteg: van-e útvonal a router saját címére?

Kezdje a kliensen, és kérdezze meg a kernelt, hová megy a csomag. Linuxon a ip route get 10.6.0.1 kiírja a választott útvonalat, a kimenő interfészt és a forráscímet. Ha az internetszolgáltatója felé mutató alapértelmezett útvonalat jelenti, a csomag soha nem lép be az alagútba, és a routeren egyetlen szabály sem mentheti meg.

Az alagút oldalának megvan a maga változata a kérdésre. A WireGuard az AllowedIPs listát titkosításikulcs-útválasztási táblaként kezeli: mindkét végén kinyilvánítja, mely forráscímeket használhat egy partner, és mely célok kerülnek ahhoz a partnerhez. Ha a kliens bejegyzése nem tartalmazza a router alagútcímét, a kliensnek nincs útvonala oda. Ha a szerver bejegyzése ehhez a klienshez nem fedi le a kliens alagútcímét, a szerver eldobja a csomagot, mielőtt bármely tűzfalszabályt megnéznének.

Erősítse meg a pontosan elérni kívánt címet, mielőtt a házirendet hibakeresné. Egy elavult DNS-rekord vagy a változás előtti gyorsítótárazott szomszédbejegyzés olyan címre küldi, amellyel a router soha nem rendelkezett.

Második réteg: a bemeneti házirend, nem a továbbítási házirend

A tűzfalak a szabályokat azon az interfészen értékelik, amelyen a csomag érkezik. A pfSense és az OPNsense esetében az interfész lap és a szabályok sorrendje dönti el, hogy a tűzfal saját szolgáltatásai felé irányuló forgalom engedélyezett-e; az a szabály, amely a LAN-klienseket kiengedi az internetre, nem az a szabály, amely egy alagútpartnernek megengedi a webes felület megnyitását. A firewall4-gyel futó OpenWrt esetében minden zóna bemeneti házirendet hordoz, option input 'ACCEPT' vagy 'REJECT', és a REJECT bemenetű zónában lévő alagútinterfész elutasítja a felügyeleti kapcsolatokat, miközben továbbra is továbbítja a forgalmat, ha a továbbítás engedélyezett.

Ne kapcsolja ki a zárolásellenes szabályt, hogy az új útvonal működjön. Az a szabály megakadályozza, hogy egy rossz szabály kizárja a LAN felügyeleti címét; a LAN alhálózatot védi, nem az éppen létrehozott alagút alhálózatát. Adjon hozzá egy szűk szabályt az adminisztrátor forrásához, és hagyja békén a biztonsági hálót. A pfSense adminisztrátori hozzáférésről szóló dokumentációja elmagyarázza, hol találhatók ezek a vezérlők.

# 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

Harmadik réteg: figyel-e valami azon a címen?

Egy szolgáltatás futhat, és mégis elérhetetlen lehet, mert egyetlen címhez kötődik. Az OpenWrt uhttpd-je kifejezett figyelő bejegyzéseket tart a /etc/config/uhttpd fájlban, például list listen_http '0.0.0.0:80'; az a build, amely csak a LAN-címhez kötődik, semmit nem fogad el az alagútcímen, és a figyelőinterfész-beállítást kínáló termékek ugyanígy viselkednek. A fenti figyelőparancsok erre közvetlenül válaszolnak.

Ezután válassza el az elutasítást a csendtől. A nc -vz 10.6.0.1 443 elutasított kapcsolatot visszaadó eredménye azt jelenti, hogy a csomag elérte a routert, és valami elutasította, akár zárt port, akár kifejezett elutasító szabály. Az időtúllépésig tartó akadás azt jelenti, hogy a csomagot eldobták, vagy soha nem volt rá útvonal. Ez a különbség megmondja, melyik réteget vizsgálja következőként, és öt másodpercbe kerül.

A VPN-interfész határ, nem helyreállítási útvonal

A titkosítás a vezetéket védi; semmit nem mond arról, ki nyithatja meg az adminisztrációs oldalt. Amikor az alagút működik, álljon ellen a kísértésnek, hogy az elérhetőséget minden engedélyezésével oldja meg az alagútinterfészen. Adjon az adminisztrátoroknak a saját alagútcímükhöz kötött szabályt vagy külön, csak adminisztrátoroknak szóló alagutat, és tartsa távol a hétköznapi felhasználókat, a NAS-t, a kamerákat és a családi laptopokat a felügyeleti porttól. Egy partnernek, amelynek fájlmegosztásra van szüksége, nem szabadna egyetlen szabályra lennie a router bejelentkezésétől.

A router szerepe megváltoztatja a választ. Az alagutat lezáró router jogosan fogadhat el adminisztrátorokat belőle, míg az az útválasztó, amely az alagutat csak internetes kijáratként használja, általában nem teheti ezt. Mindkét esetben az alhálózati engedély nem a bejelentkezés, ezért tartsa bekapcsolva a fiókhitelesítést és a szállítási biztonságot.

A zárolás után az emberek által tett kompenzáló lépés rosszabb: a WAN-felügyelet bekapcsolása vagy egy port továbbítása a webes felületre. Ez egy rövid kiesést állandó kitettséggé változtat, és a bejelentkezési oldal akkor az internet minden szkennerje számára elérhetővé válik. Tesztelje az elutasított oldalt is, ne csak az engedélyezettet, hogy az a partner, amelynek nem szabadna adminisztrátori hozzáféréssel rendelkeznie, időtúllépést vagy elutasítást kapjon bejelentkezési kérés helyett.

Teszteljen friss kapcsolattal is. Az állapotalapú tűzfal a meglévő folyamatokat az állapottáblájában tartja, ezért az már nyitva lévő SSH-munkamenet túlélhet egy olyan változást, amely minden új kapcsolatot blokkol. Így marad a zárolás láthatatlan a következő újraindításig vagy a laptop következő alvásáig.

Készítse elő a visszautat, mielőtt a házirendhez nyúl

Írjon le négy dolgot az első változtatás előtt: hogyan éri el az eszközt, ha az alagút meghal, például soros konzolon, szolgáltatói konzolon vagy a LAN-on lévő gépen keresztül; hová exportálják a jelenlegi konfigurációt; melyik egyetlen szabályt vagy útvonalat fogja módosítani; és hogyan állítja vissza pontosan azt az elemet. Az OpenWrt-n a sysupgrade -b /tmp/backup.tar.gz rögzíti a konfigurációt, és a módosítások a uci commit parancsig függőben maradnak, ami olcsó visszavonást ad, ha időben észreveszi. A pfSense konfigurációtörténetet vezet, és az AutoConfigBackup csak akkor segít, ha már be volt kapcsolva. Ha a router fail-closed szabálykészletet futtat, ellenőrizze, hogy a tervezett karbantartási útvonal nincs-e azon forgalom belsejében, amelyet ez a szabály blokkol, és ne feledje, hogy az újraindítás újra alkalmazza a tartós szabályokat, nem törli őket.

Kísérletenként egy határt változtasson, majd friss kapcsolatból teszteljen, ne a nyitva tartott héjból. Ha a teszt sikertelen, vonja vissza azt az egy változtatást, mielőtt a következő réteghez nyúl. Az alagút végig fent maradhat, de a zöld állapotikona nem bizonyíték arra, hogy még be tud lépni.

Gyors ellenőrzés, mielőtt elmegy:

• Eléri-e a routert olyan forrásból, amely nem függ az éppen szerkesztett szabálytól?
• Az alagútinterfész bemeneti házirendje csak az adminisztrátor forrását engedélyezi?
• A felügyeleti szolgáltatás olyan címhez van kötve, amely létezik az alagúton?
• Tesztelt egy elutasított partnert és egy friss munkamenetet?
• A WAN-felügyeleti felület még mindig zárva van?