Prečo správa routera prestane odpovedať po zmene VPN

Zmenili ste trasu alebo pravidlo firewallu, aby ste otestovali tunel na routeri, a teraz stránka správy neodpovedá z notebooku, ktorý pred desiatimi minútami fungoval bez problémov. Reflex je obviniť VPN. Väčšinou je tunel zdravý a pokazila sa jedna z troch ďalších vecí: chýba trasa späť na vlastnú adresu routera, vstupná politika zahadzuje požiadavku, alebo webová služba nepočúva na adrese, ktorú voláte. Všetky tri vyzerajú v prehliadači rovnako, preto ľudia hodinu reštartujú tunel a nič sa nedozvedia.

Tu je mýtus, ktorý sa oplatí zabiť ako prvý: funkčný tunel nie je cesta späť dnu. Je to nové sieťové pripojenie s vlastnými otázkami dôvery a môže potichu odstrániť vašu starú cestu správy, zatiaľ čo otvára novú, ktorú nikto neskontroloval.

Tunel nikdy nebol cestou správy

Preposielanie a vstup sú rôzne úlohy. „Môže sa klient dostať cez tunel na NAS?“ je otázka preposielania o paketoch, ktoré prechádzajú cez router. „Môžem otvoriť SSH port routera?“ je otázka vstupu o paketoch adresovaných samotnému routeru. Pravidlo povolenia napísané pre preposielanú prevádzku nerobí pre druhú otázku nič, a to je najčastejší dôvod, prečo tunel, ktorý prevádzku prenáša bezchybne, stále odmieta vašu reláciu správy.

Opačná chyba je dôverovať názvu rozhrania. Tunel je šifrovaný voči partnerovi, nie voči každej službe za ním, a slovo VPN v označení rozhrania nič nehovorí o tom, ktorým zdrojom má byť povolené prihlásenie.

Prvá vrstva: existuje trasa na vlastnú adresu routera?

Začnite na klientovi a spýtajte sa jadra, kam paket pôjde. V Linuxe ip route get 10.6.0.1 vypíše zvolenú trasu, odchádzajúce rozhranie a zdrojovú adresu. Ak hlási predvolenú trasu k vášmu poskytovateľovi, paket sa nikdy nedostane do tunela a žiadne pravidlo na routeri ho nezachráni.

Strana tunela má svoju vlastnú verziu otázky. WireGuard považuje AllowedIPs za smerovaciu tabuľku kryptokľúčov: na každom konci deklaruje, ktoré zdrojové adresy môže partner používať a ktoré ciele sa posielajú tomu partnerovi. Ak záznam klienta neobsahuje tunelovú adresu routera, klient na ňu nemá trasu. Ak záznam servera pre tohto klienta nepokrýva tunelovú adresu klienta, server paket zahodí skôr, než sa pozrie na akékoľvek pravidlo firewallu.

Potvrďte presnú adresu, ktorú očakávate, že dosiahnete, skôr než začnete ladenie politiky. Zastaraný záznam DNS alebo cachovaný záznam suseda z čias pred zmenou vás zavedie na adresu, ktorú router nikdy nevlastnil.

Druhá vrstva: vstupná politika, nie politika preposielania

Firewally vyhodnocujú pravidlá na rozhraní, na ktorom paket prichádza. Na pfSense a OPNsense rozhoduje karta rozhrania a poradie pravidiel, či je prevádzka k vlastným službám firewallu povolená; pravidlo, ktoré pustí klientov LAN do internetu, nie je pravidlom, ktoré dovolí partnerovi tunela otvoriť webové rozhranie. Na OpenWrt s firewall4 nesie každá zóna vstupnú politiku, option input 'ACCEPT' alebo 'REJECT', a tunelové rozhranie v zóne so vstupom REJECT bude odmietať spojenia správy, pričom stále preposiela prevádzku, ak je preposielanie povolené.

Nevypínajte pravidlo proti uzamknutiu, aby nová cesta fungovala. To pravidlo chráni adresu správy LAN pred uzamknutím zlým pravidlom; chráni podsieti LAN, nie podsieti tunela, ktorú ste práve vytvorili. Pridajte jedno úzke pravidlo pre zdroj správcu a bezpečnostnú sieť nechajte na pokoji. Dokumentácia pfSense o prístupe správcu vysvetľuje, kde tieto ovládacie prvky sú.

# 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

Tretia vrstva: počúva na tej adrese vôbec niečo?

Služba môže bežať a napriek tomu byť nedostupná, pretože sa naviazala na jednu adresu. uhttpd v OpenWrt drží explicitné záznamy počúvania v /etc/config/uhttpd, napríklad list listen_http '0.0.0.0:80'; zostavenie, ktoré sa viaže len na adresu LAN, nič na tunelovej adrese neprijme, a produkty, ktoré zverejňujú nastavenie rozhrania počúvania, sa správajú rovnako. Príkazy počúvania vyššie na to odpovedajú priamo.

Potom oddeľte odmietnutie od ticha. nc -vz 10.6.0.1 443 vracajúce odmietnuté spojenie znamená, že paket dorazil k routeru a niečo ho odmietlo, buď zatvorený port, alebo explicitné pravidlo odmietnutia. Zaseknutie do vypršania znamená, že paket bol zahodený alebo nikdy nesmerovaný. Tento rozdiel vám povie, ktorú vrstvu skúmať ďalej, a stojí päť sekúnd.

Rozhranie VPN je hranica, nie cesta obnovy

Šifrovanie chráni drôt; nehovorí nič o tom, kto smie otvoriť stránku správy. Keď tunel funguje, odolajte nutkaniu vyriešiť dostupnosť tým, že na tunelovom rozhraní povolíte všetko. Dajte správcom pravidlo viazané na ich vlastnú tunelovú adresu alebo samostatný tunel len pre správcov a držte bežných používateľov, NAS, kamery a rodinné notebooky ďalej od portu správy. Partner, ktorý potrebuje zdieľanie súborov, by nemal byť jedno pravidlo od prihlásenia do routera.

Úloha routera mení odpoveď. Router, ktorý tunel ukončuje, môže legitímne prijímať správcov z neho, zatiaľ čo router, ktorý tunel používa len ako výstup do internetu, by to zvyčajne nemal. V oboch prípadoch povolenie podsiete nie je prihlásenie, preto nechajte zapnuté overovanie účtu a zabezpečenie prenosu.

Kompenzačný krok, ktorý ľudia po uzamknutí urobia, je horší: zapnutie správy cez WAN alebo presmerovanie portu na webové rozhranie. To premení krátky výpadok na trvalé vystavenie a prihlasovacia stránka je potom dostupná každému skeneru na internete. Otestujte aj zakázanú stranu, nielen povolenú, aby partner, ktorý by nemal mať prístup správcu, dostal vypršanie alebo odmietnutie namiesto výzvy na prihlásenie.

Testujte aj novým spojením. Stavový firewall drží existujúce toky vo svojej tabuľke stavov, takže už otvorená relácia SSH môže prežiť zmenu, ktorá blokuje každé nové spojenie. Tak zostáva uzamknutie neviditeľné až do ďalšieho reštartu alebo ďalšieho uspania notebooku.

Pripravte si cestu späť, skôr než sa dotknete politiky

Pred prvou zmenou si zapíšte štyri veci: ako sa dostanete k zariadeniu, ak tunel zomrie, napríklad cez sériovú konzolu, konzolu poskytovateľa alebo stroj v LAN; kam sa exportuje súčasná konfigurácia; ktoré jediné pravidlo alebo trasu sa chystáte zmeniť; a ako presne tú položku vrátite. Na OpenWrt sysupgrade -b /tmp/backup.tar.gz zachytí konfiguráciu a úpravy zostávajú čakajúce do uci commit, čo vám dáva lacné vrátenie, ak si to včas všimnete. pfSense vedie históriu konfigurácie a AutoConfigBackup pomáha len vtedy, ak už bol zapnutý. Ak router beží so sadou pravidiel fail-closed, overte, že plánovaná cesta údržby nie je vnútri prevádzky, ktorú to pravidlo blokuje, a pamätajte, že reštart znova uplatní trvalé pravidlá namiesto toho, aby ich vymazal.

Meňte jednu hranicu na pokus, potom testujte z nového spojenia, nie z shellu, ktorý držíte otvorený. Ak test zlyhá, vráťte tú jednu zmenu skôr, než sa dotknete ďalšej vrstvy. Tunel môže zostať hore celý čas, ale jeho zelená ikona stavu nie je dôkazom, že sa ešte dostanete dnu.

Rýchla kontrola pred odchodom:

• Dostanete sa k routeru zo zdroja, ktorý nezávisí od pravidla, ktoré ste práve upravili?
• Povoľuje vstupná politika na tunelovom rozhraní iba zdroj správcu?
• Je služba správy viazaná na adresu, ktorá v tuneli existuje?
• Otestovali ste jedného zakázaného partnera a jednu novú reláciu?
• Je plocha správy cez WAN stále zavretá?