Zakaj upravljanje usmerjevalnika preneha odgovarjati po spremembi VPN

Spremenili ste pot ali pravilo požarnega zidu, da bi preizkusili tunel na usmerjevalniku, in zdaj se stran za upravljanje ne odziva s prenosnika, ki je deset minut prej deloval brezhibno. Prvi odziv je kriviti VPN. Največkrat je tunel zdrav, pokvarila pa se je ena od treh drugih stvari: ni poti nazaj na lasten naslov usmerjevalnika, vhodna politika zavrže zahtevo, ali spletna storitev ne posluša na naslovu, ki ga kličete. Vse tri so v brskalniku videti enako, zato ljudje uro ponovno zaganjajo tunel in se ničesar ne naučijo.

Tukaj je mit, ki se ga splača ubiti prvega: delujoč tunel ni pot nazaj noter. Je nova omrežna povezava z lastnimi vprašanji zaupanja in lahko tiho odstrani staro pot upravljanja, medtem ko odpira novo, ki je nihče ni pregledal.

Tunel ni bil nikoli pot upravljanja

Posredovanje in vhod sta različni opravili. »Ali lahko odjemalec doseže NAS skozi tunel?« je vprašanje posredovanja o paketih, ki gredo skozi usmerjevalnik. »Ali lahko odprem vrata SSH usmerjevalnika?« je vprašanje vhoda o paketih, naslovljenih na sam usmerjevalnik. Pravilo prepuščanja, napisano za posredovani promet, ne naredi ničesar za drugo vprašanje, in to je najpogostejši razlog, da tunel, ki promet odlično prenaša, še vedno zavrača vašo sejo upravljanja.

Nasprotna napaka je zaupanje imenu vmesnika. Tunel je šifriran do partnerja, ne do vsake storitve za njim, in beseda VPN na oznaki vmesnika ne pove ničesar o tem, katerim virom naj bo dovoljena prijava.

Prvi sloj: ali obstaja pot na lasten naslov usmerjevalnika?

Začnite na odjemalcu in vprašajte jedro, kam bo šel paket. V Linuxu ip route get 10.6.0.1 izpiše izbrano pot, odhodni vmesnik in izvorni naslov. Če poroča privzeto pot proti vašemu ponudniku, paket nikoli ne vstopi v tunel in nobeno pravilo na usmerjevalniku ga ne more rešiti.

Stran tunela ima svojo različico vprašanja. WireGuard obravnava AllowedIPs kot usmerjevalno tabelo kriptografskih ključev: na vsakem koncu razglasi, katere izvorne naslove lahko uporablja partner in kateri cilji se pošiljajo temu partnerju. Če vnos odjemalca ne vsebuje naslova tunela usmerjevalnika, odjemalec nima poti do njega. Če vnos strežnika za tega odjemalca ne pokriva naslova tunela odjemalca, strežnik paket zavrže, preden se pregleda katero koli pravilo požarnega zidu.

Preden odpravljate težave s politiko, potrdite točen naslov, ki ga želite doseči. Zastarel zapis DNS ali predpomnilniški zapis soseda iz časa pred spremembo vas pelje na naslov, ki ga usmerjevalnik ni nikoli imel.

Drugi sloj: vhodna politika, ne politika posredovanja

Požarni zidovi ocenjujejo pravila na vmesniku, na katerem paket prispe. Na pfSense in OPNsense zavihk vmesnika in vrstni red pravil odločata, ali je promet do lastnih storitev požarnega zidu dovoljen; pravilo, ki spusti odjemalce LAN v internet, ni pravilo, ki bi partnerju tunela dovolilo odpreti spletni vmesnik. Na OpenWrt s firewall4 nosi vsaka cona vhodno politiko, option input 'ACCEPT' ali 'REJECT', in vmesnik tunela v coni z vhodom REJECT bo zavračal upravljalne povezave, hkrati pa še vedno posredoval promet, če je posredovanje dovoljeno.

Ne izklopite pravila proti zaklepu, da bi nova pot delovala. To pravilo preprečuje, da bi slabo pravilo zaklenilo upravljalni naslov LAN; ščiti podomrežje LAN, ne podomrežja tunela, ki ste ga pravkar ustvarili. Dodajte eno ozko pravilo za vir skrbnika in varnostno mrežo pustite pri miru. Dokumentacija pfSense o skrbniškem dostopu pojasnjuje, kje so ti nadzori.

# 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

Tretji sloj: ali na tem naslovu sploh kaj posluša?

Storitev lahko teče in je vseeno nedosegljiva, ker se je vezala na en naslov. uhttpd v OpenWrt hrani izrecne vnose poslušanja v /etc/config/uhttpd, na primer list listen_http '0.0.0.0:80'; gradnja, ki se veže samo na naslov LAN, na naslovu tunela ne sprejme ničesar, izdelki z nastavitvijo vmesnika poslušanja pa se obnašajo enako. Zgornji ukazi poslušanja na to odgovarjajo neposredno.

Nato ločite zavrnitev od tišine. nc -vz 10.6.0.1 443, ki vrne zavrnjeno povezavo, pomeni, da je paket dosegel usmerjevalnik in ga je nekaj zavrnilo, bodisi zaprta vrata bodisi izrecno pravilo zavrnitve. Visenje do izteka časa pomeni, da je bil paket zavržen ali nikoli usmerjen. Ta razlika vam pove, kateri sloj pregledati naslednji, in stane pet sekund.

Vmesnik VPN je meja, ne pot obnovitve

Šifriranje ščiti žico; ne pove ničesar o tem, kdo sme odpreti stran za upravljanje. Ko tunel deluje, se uprite želji, da bi dosegljivost rešili z dovoljenjem vsega na vmesniku tunela. Skrbnikom dajte pravilo, vezano na njihov lastni naslov tunela, ali ločen tunel samo za skrbnike, in navadne uporabnike, NAS, kamere in družinske prenosnike držite stran od vrat za upravljanje. Partner, ki potrebuje souporabo datotek, ne sme biti eno pravilo oddaljen od prijave v usmerjevalnik.

Vloga usmerjevalnika spremeni odgovor. Usmerjevalnik, ki zaključi tunel, lahko zakonito sprejema skrbnike iz njega, medtem ko usmerjevalnik, ki tunel uporablja le kot izhod v internet, tega običajno ne bi smel. V obeh primerih dovoljenje podomrežja ni prijava, zato pustite omogočeno preverjanje računa in varnost prenosa.

Kompenzacijska poteza, ki jo ljudje naredijo po zaklepu, je slabša: vklop upravljanja prek WAN ali preusmeritev vrat na spletni vmesnik. To kratek izpad spremeni v trajno izpostavljenost, prijavna stran pa je nato dosegljiva vsakemu skenerju na internetu. Preizkusite tudi zavrnjeno stran, ne le dovoljene, da partner, ki ne bi smel imeti skrbniškega dostopa, dobi potek časa ali zavrnitev namesto poziva k prijavi.

Preizkusite tudi z novo povezavo. Stavni požarni zid hrani obstoječe tokove v svoji tabeli stanj, zato lahko že odprta seja SSH preživi spremembo, ki blokira vsako novo povezavo. Tako zaklep ostane neviden do naslednjega ponovnega zagona ali naslednjega spanja prenosnika.

Pripravite pot nazaj, preden se dotaknete politike

Pred prvo spremembo zapišite štiri stvari: kako boste dosegli napravo, če tunel umre, na primer serijska konzola, ponudnikova konzola ali stroj v omrežju LAN; kam se izvaža trenutna konfiguracija; katero eno pravilo ali pot boste spremenili; in kako boste natanko ta element vrnili. V OpenWrt sysupgrade -b /tmp/backup.tar.gz zajame konfiguracijo, spremembe pa ostanejo v čakanju do uci commit, kar vam da poceni razveljavitev, če to pravočasno opazite. pfSense vodi zgodovino konfiguracije, AutoConfigBackup pa pomaga le, če je bil že omogočen. Če usmerjevalnik izvaja nabor pravil fail-closed, preverite, da načrtovana pot vzdrževanja ni znotraj prometa, ki ga to pravilo blokira, in ne pozabite, da ponovni zagon znova uveljavi trajna pravila, namesto da bi jih izbrisal.

Spreminjajte eno mejo na poskus, nato preizkusite z nove povezave, ne iz lupine, ki jo držite odprto. Če preizkus ne uspe, razveljavite tisto eno spremembo, preden se dotaknete naslednjega sloja. Tunel lahko ostane pokonci ves čas, vendar njegova zelena ikona stanja ni dokaz, da še vedno lahko vstopite.

Hitro preverjanje pred odhodom:

• Ali dosežete usmerjevalnik iz vira, ki ni odvisen od pravila, ki ste ga pravkar uredili?
• Ali vhodna politika na vmesniku tunela dovoljuje samo vir skrbnika?
• Ali je storitev upravljanja vezana na naslov, ki obstaja na tunelu?
• Ali ste preizkusili enega zavrnjenega partnerja in eno novo sejo?
• Ali je površina upravljanja prek WAN še vedno zaprta?