Proč správa routeru přestane odpovídat po změně VPN

Změnili jste trasu nebo pravidlo firewallu, abyste otestovali tunel na routeru, a teď stránka správy neodpovídá z notebooku, který před deseti minutami fungoval bez problémů. Reflex je obvinit VPN. Většinou je tunel zdravý a rozbila se jedna ze tří dalších věcí: chybí trasa zpět na vlastní adresu routeru, vstupní politika zahazuje požadavek, nebo webová služba neposlouchá adresu, kterou voláte. Všechny tři vypadají v prohlížeči stejně, a proto lidé hodinu restartují tunel a nic se nedozvědí.

Tady je mýtus, který je nejlepší zabít jako první: funkční tunel není cesta zpět dovnitř. Je to nové síťové připojení s vlastními otázkami důvěry a může tiše odstranit vaši starou cestu správy, zatímco otevírá novou, kterou nikdo nezkontroloval.

Tunel nikdy nebyl cestou správy

Přesměrování a vstup jsou různé úkoly. „Může se klient dostat přes tunel na NAS?“ je otázka přesměrování o paketech, které procházejí routerem. „Můžu otevřít SSH port routeru?“ je otázka vstupu o paketech adresovaných samotnému routeru. Pravidlo povolení napsané pro přesměrovaný provoz nedělá pro druhou otázku nic, a to je nejčastější důvod, proč tunel, který provoz přenáší bezchybně, stále odmítá vaši relaci správy.

Opačná chyba je důvěřovat názvu rozhraní. Tunel je šifrovaný vůči protějšku, ne vůči každé službě za ním, a slovo VPN v označení rozhraní nic neříká o tom, kterým zdrojům má být povoleno přihlášení.

První vrstva: existuje trasa na vlastní adresu routeru?

Začněte na klientovi a zeptejte se jádra, kam paket půjde. V Linuxu ip route get 10.6.0.1 vypíše zvolenou trasu, odchozí rozhraní a zdrojovou adresu. Pokud hlásí výchozí trasu k vašemu ISP, paket se do tunelu nikdy nedostane a žádné pravidlo na routeru ho nezachrání.

Strana tunelu má svou vlastní verzi otázky. WireGuard považuje AllowedIPs za směrovací tabulku kryptoklíčů: na každém konci deklaruje, které zdrojové adresy smí protějšek používat a které cíle se posílají tomu protějšku. Pokud záznam klienta neobsahuje tunelovou adresu routeru, klient na ni nemá trasu. Pokud záznam serveru pro tohoto klienta nepokrývá tunelovou adresu klienta, server paket zahodí dřív, než se podívá na jakékoli pravidlo firewallu.

Potvrďte přesnou adresu, kterou očekáváte, že dosáhnete, než začnete ladit politiku. Zastaralý záznam DNS nebo cached záznam souseda z doby před změnou vás zavede na adresu, kterou router nikdy nevlastnil.

Druhá vrstva: vstupní politika, ne politika přesměrování

Firewally vyhodnocují pravidla na rozhraní, na kterém paket dorazí. Na pfSense a OPNsense rozhoduje karta rozhraní a pořadí pravidel, zda je provoz k vlastním službám firewallu povolen; pravidlo, které pustí klienty LAN do internetu, není pravidlem, které dovolí protějšku tunelu otevřít webové rozhraní. Na OpenWrt s firewall4 nese každá zóna vstupní politiku, option input 'ACCEPT' nebo 'REJECT', a tunelové rozhraní v zóně se vstupem REJECT bude odmítat spojení správy, zatímco stále přesměrovává provoz, pokud je přesměrování povoleno.

Nevypínejte pravidlo proti uzamčení, aby nová cesta fungovala. To pravidlo chrání adresu správy LAN před uzamčením špatným pravidlem; chrání podsíť LAN, ne podsíť tunelu, kterou jste právě vytvořili. Přidejte jedno úzké pravidlo pro zdroj administrátora a bezpečnostní síť nechte být. Dokumentace pfSense o přístupu správce vysvětluje, kde tyto ovládací prvky jsou.

# 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

Třetí vrstva: naslouchá na této adrese vůbec něco?

Služba může běžet a přesto být nedostupná, protože se navázala na jednu adresu. uhttpd v OpenWrt drží explicitní záznamy naslouchání v /etc/config/uhttpd, například list listen_http '0.0.0.0:80'; sestavení, které se váže jen na adresu LAN, nic na tunelové adrese nepřijme, a produkty, které vystavují nastavení rozhraní pro naslouchání, se chovají stejně. Příkazy pro naslouchání výše na to odpovídají přímo.

Pak oddělte odmítnutí od ticha. nc -vz 10.6.0.1 443 vracející odmítnuté spojení znamená, že paket dorazil k routeru a něco ho odmítlo, buď zavřený port, nebo explicitní pravidlo odmítnutí. Zaseknutí do vypršení znamená, že paket byl zahozen nebo nikdy nesměrován. Ten rozdíl vám řekne, kterou vrstvu zkoumat dál, a stojí pět sekund.

Rozhraní VPN je hranice, ne cesta obnovy

Šifrování chrání drát; neříká nic o tom, kdo smí otevřít stránku správy. Jakmile tunel funguje, odolejte nutkání vyřešit dosažitelnost tím, že na tunelovém rozhraní povolíte všechno. Dejte administrátorům pravidlo vázané na jejich vlastní tunelovou adresu nebo samostatný tunel jen pro administrátory a držte běžné uživatele, NAS, kamery a rodinné notebooky daleko od portu správy. Protějšek, který potřebuje sdílení souborů, nemá být jedno pravidlo od přihlášení do routeru.

Role routeru mění odpověď. Router, který tunel ukončuje, může legitimně přijímat administrátory z něj, zatímco router, který tunel používá jen jako výstup do internetu, by to obvykle neměl. V obou případech povolení podsítě není přihlášení, takže nechte zapnuté ověřování účtu a zabezpečení přenosu.

Kompenzační krok, který lidé po uzamčení udělají, je horší: zapnutí správy přes WAN nebo přesměrování portu na webové rozhraní. To promění krátký výpadek v trvalé vystavení a přihlašovací stránka je pak dostupná každému skeneru na internetu. Otestujte i zakázanou stranu, ne jen povolenou, aby protějšek, který by neměl mít přístup správce, dostal vypršení nebo odmítnutí místo výzvy k přihlášení.

Testujte i novým spojením. Stavový firewall drží existující toky ve své tabulce stavů, takže už otevřená SSH relace může přežít změnu, která blokuje každé nové spojení. Tak zůstává uzamčení neviditelné až do dalšího restartu nebo dalšího uspání notebooku.

Připravte cestu zpět, než se dotknete politiky

Než uděláte první změnu, zapište si čtyři věci: jak se dostanete k zařízení, když tunel zemře, například přes sériovou konzoli, konzoli poskytovatele nebo stroj v LAN; kam se exportuje současná konfigurace; které jediné pravidlo nebo trasu se chystáte změnit; a jak přesně tu položku vrátíte. Na OpenWrt sysupgrade -b /tmp/backup.tar.gz zachytí konfiguraci a úpravy zůstávají čekající do uci commit, což vám dá levné vrácení, pokud si toho včas všimnete. pfSense vede historii konfigurace a AutoConfigBackup pomáhá jen tehdy, pokud už byl zapnutý. Pokud router běží se sadou pravidel fail-closed, ověřte, že plánovaná cesta údržby není uvnitř provozu, který to pravidlo blokuje, a pamatujte, že restart znovu uplatní trvalá pravidla, místo aby je smazal.

Měňte jednu hranici na pokus, pak testujte z nového spojení, ne z shellu, který držíte otevřený. Pokud test selže, vraťte tu jednu změnu, než se dotknete další vrstvy. Tunel může zůstat nahoru celou dobu, ale jeho zelená ikona stavu není důkazem, že se ještě dostanete dovnitř.

Rychlá kontrola, než odejdete:

• Dostanete se k routeru ze zdroje, který nezávisí na pravidle, které jste právě upravili?
• Povoluje vstupní politika na tunelovém rozhraní jen zdroj administrátora?
• Je služba správy vázaná na adresu, která v tunelu existuje?
• Otestovali jste jednoho zakázaného protějška a jednu novou relaci?
• Je plocha správy přes WAN stále zavřená?