Kodėl maršrutizatoriaus administravimas nustoja atsakyti po VPN pakeitimo

Pakeitėte maršrutą ar ugniasienės taisyklę, kad išbandytumėte tunelį maršrutizatoriuje, ir dabar administravimo puslapis neatsako iš nešiojamojo kompiuterio, kuris prieš dešimt minučių veikė tinkamai. Pirmoji reakcija – kaltinti VPN. Dažniausiai tunelis sveikas, o sugedo vienas iš trijų kitų dalykų: nėra maršruto atgal į paties maršrutizatoriaus adresą, įvesties politika numeta užklausą arba žiniatinklio tarnyba nesiklauso adreso, kurį kviečiate. Visi trys naršyklėje atrodo vienodai, todėl žmonės valandą perkrauna tunelį ir nieko neišmoksta.

Štai mitas, kurį verta nužudyti pirmiausia: veikiantis tunelis nėra kelias atgal į vidų. Tai nauja tinklo jungtis su savo pasitikėjimo klausimais, ir ji gali tyliai pašalinti senąjį valdymo kelią, tuo pat metu atidarydama naują, kurio niekas neperžiūrėjo.

Tunelis niekada nebuvo valdymo kelias

Persiuntimas ir įvestis yra skirtingi darbai. „Ar klientas gali pasiekti NAS per tunelį?“ – tai persiuntimo klausimas apie paketus, einančius per maršrutizatorių. „Ar galiu atidaryti maršrutizatoriaus SSH prievadą?“ – tai įvesties klausimas apie pačiam maršrutizatoriui adresuotus paketus. Persiunčiamam srautui parašyta leidimo taisyklė antrajam klausimui nieko nedaro, ir tai yra dažniausia priežastis, kodėl tunelis, puikiai pernešantis srautą, vis tiek atsisako jūsų administravimo sesijos.

Priešinga klaida – pasitikėti sąsajos pavadinimu. Tunelis šifruojamas iki partnerio, o ne iki kiekvienos tarnybos už jo, ir žodis VPN sąsajos etiketėje nieko nesako apie tai, kokiems šaltiniams turėtų būti leidžiama prisijungti.

Pirmas sluoksnis: ar yra maršrutas į paties maršrutizatoriaus adresą?

Pradėkite kliente ir paklauskite branduolio, kur keliaus paketas. Linux sistemoje ip route get 10.6.0.1 išspausdina pasirinktą maršrutą, išėjimo sąsają ir šaltinio adresą. Jei jis praneša apie numatytąjį maršrutą link jūsų tiekėjo, paketas niekada nepatenka į tunelį, ir jokia maršrutizatoriaus taisyklė jo neišgelbės.

Tunelio pusė turi savo klausimo versiją. WireGuard AllowedIPs traktuoja kaip šifravimo rakto maršruto lentelę: kiekviename gale ji deklaruoja, kokius šaltinio adresus partneris gali naudoti ir kokie tikslai siunčiami tam partneriui. Jei kliento įraše nėra maršrutizatoriaus tunelio adreso, klientas neturi maršruto į jį. Jei serverio įrašas tam klientui neapima kliento tunelio adreso, serveris numeta paketą dar prieš patikrindamas bet kokią ugniasienės taisyklę.

Prieš derindami politiką patvirtinkite tikslų adresą, kurį tikitės pasiekti. Pasenęs DNS įrašas arba podėlyje esantis kaimyno įrašas iš laikų prieš pakeitimą nukreipia jus į adresą, kurio maršrutizatorius niekada neturėjo.

Antras sluoksnis: įvesties politika, o ne persiuntimo politika

Ugniasienės taisykles vertina sąsajoje, į kurią atvyksta paketas. pfSense ir OPNsense atveju sąsajos skirtukas ir taisyklių tvarka nusprendžia, ar leidžiamas srautas į pačios ugniasienės tarnybas; taisyklė, leidžianti LAN klientams išeiti į internetą, nėra taisyklė, leidžianti tunelio partneriui atidaryti žiniatinklio sąsają. OpenWrt su firewall4 atveju kiekviena zona turi įvesties politiką, option input 'ACCEPT' arba 'REJECT', o tunelio sąsaja zonoje, kurios įvestis REJECT, atsisakys valdymo jungčių, tačiau toliau persiųs srautą, jei persiuntimas leidžiamas.

Neišjunkite apsaugos nuo užsiblokavimo taisyklės, kad veiktų naujasis kelias. Ta taisyklė neleidžia blogai taisyklei užblokuoti LAN valdymo adreso; ji saugo LAN potinklį, o ne ką tik sukurto tunelio potinklį. Pridėkite vieną siaurą taisyklę administratoriaus šaltiniui ir palikite saugos tinklą ramybėje. pfSense administravimo prieigos dokumentacija paaiškina, kur yra tie valdikliai.

# 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

Trečias sluoksnis: ar kas nors klausosi tame adrese?

Tarnyba gali veikti ir vis tiek būti nepasiekiama, nes prisirišo prie vieno adreso. OpenWrt uhttpd laiko aiškius klausymosi įrašus /etc/config/uhttpd, pavyzdžiui list listen_http '0.0.0.0:80'; rinkinys, kuris prisiriša tik prie LAN adreso, nieko nepriima tunelio adresu, o produktai, rodantys klausymosi sąsajos nustatymą, elgiasi taip pat. Aukščiau pateiktos klausymosi komandos į tai atsako tiesiogiai.

Tada atskirkite atmetimą nuo tylos. nc -vz 10.6.0.1 443 grąžinantis atmestą jungtį reiškia, kad paketas pasiekė maršrutizatorių ir kažkas jį atmetė – arba uždarytas prievadas, arba aiški atmetimo taisyklė. Kabojimas iki laiko limito reiškia, kad paketas buvo numestas arba niekada nesumarsrutintas. Šis skirtumas pasako, kurį sluoksnį tikrinti toliau, ir jis kainuoja penkias sekundes.

VPN sąsaja yra riba, o ne atkūrimo kelias

Šifravimas saugo laidą; jis nieko nesako apie tai, kas gali atidaryti administravimo puslapį. Kai tunelis veikia, atsispirkite norui išspręsti pasiekiamumą leidžiant viską tunelio sąsajoje. Suteikite administratoriams taisyklę, susietą su jų pačių tunelio adresu, arba atskirą tunelį tik administratoriams, ir laikykite paprastus naudotojus, NAS, kameras ir šeimos nešiojamuosius toli nuo valdymo prievado. Partneris, kuriam reikia failų bendrinimo, neturėtų būti per vieną taisyklę nuo maršrutizatoriaus prisijungimo.

Maršrutizatoriaus vaidmuo keičia atsakymą. Maršrutizatorius, kuris užbaigia tunelį, gali teisėtai priimti iš jo administratorius, o maršrutizatorius, kuris tunelį naudoja tik kaip išėjimą į internetą, paprastai neturėtų. Abiem atvejais potinklio leidimas nėra prisijungimas, todėl palikite įjungtą paskyros autentifikavimą ir transporto saugumą.

Kompensacinis žingsnis, kurį žmonės atlieka po užsiblokavimo, yra blogesnis: WAN administravimo įjungimas arba prievado persiuntimas į žiniatinklio sąsają. Tai trumpą sutrikimą paverčia nuolatiniu pavojumi, o prisijungimo puslapis tampa pasiekiamas kiekvienam interneto skaitytuvui. Išbandykite ir atmestąją pusę, ne tik leidžiamąją, kad partneris, kuris neturėtų turėti administratoriaus prieigos, gautų laiko limitą arba atmetimą, o ne prisijungimo raginimą.

Išbandykite ir nauja jungtimi. Būsenos ugniasienė laiko esamus srautus savo būsenų lentelėje, todėl jau atidaryta SSH sesija gali išgyventi pakeitimą, blokuojantį kiekvieną naują jungtį. Taip užsiblokavimas lieka nematomas iki kito perkrovimo ar kito nešiojamojo kompiuterio miego.

Pasiruoškite kelią atgal prieš liesdami politiką

Prieš pirmąjį pakeitimą užsirašykite keturis dalykus: kaip pasieksite įrenginį, jei tunelis mirs, pavyzdžiui, nuoseklioji konsolė, tiekėjo konsolė arba mašina LAN tinkle; kur eksportuojama dabartinė konfigūracija; kurią vieną taisyklę ar maršrutą ketinate keisti; ir kaip tiksliai grąžinsite tą elementą. OpenWrt sistemoje sysupgrade -b /tmp/backup.tar.gz užfiksuoja konfigūraciją, o pakeitimai lieka laukiantys iki uci commit, tai suteikia pigų atšaukimą, jei laiku pastebėsite. pfSense laiko konfigūracijos istoriją, o AutoConfigBackup padeda tik jei jis jau buvo įjungtas. Jei maršrutizatorius naudoja fail-closed taisyklių rinkinį, patvirtinkite, kad suplanuotas techninės priežiūros kelias nėra to srauto, kurį blokuoja ši taisyklė, viduje, ir atminkite, kad perkrovimas vėl taiko ilgalaikes taisykles, o ne jas ištrina.

Keiskite vieną ribą per bandymą, tada tikrinkite iš naujos jungties, o ne iš apvalkalo, kurį laikote atidarytą. Jei bandymas nepavyksta, atšaukite tą vieną pakeitimą prieš liesdami kitą sluoksnį. Tunelis gali likti iškeltas visą laiką, bet jo žalia būsenos piktograma nėra įrodymas, kad dar galite patekti.

Greitas patikrinimas prieš išeinant:

• Ar pasiekiate maršrutizatorių iš šaltinio, kuris nepriklauso nuo ką tik redaguotos taisyklės?
• Ar tunelio sąsajos įvesties politika leidžia tik administratoriaus šaltinį?
• Ar valdymo tarnyba susieta su adresu, kuris egzistuoja tunelyje?
• Ar išbandėte vieną atmestą partnerį ir vieną naują sesiją?
• Ar WAN administravimo paviršius vis dar uždarytas?