Kial la administra paĝo de la enkursigilo ĉesas respondi post ŝanĝo de VPN

Vi ŝanĝis vojon aŭ fajroŝirman regulon por testi tunelon sur la enkursigilo, kaj nun la administra paĝo ne respondas el la tekkomputilo, kiu funkciis bone antaŭ dek minutoj. La reflekso estas kulpigi la VPN-on. Plej ofte la tunelo sanas kaj unu el tri aliaj aferoj rompiĝis: mankas vojo reen al la propra adreso de la enkursigilo, eniga politiko forĵetas la peton, aŭ retservo ne aŭskultas la adreson, kiun vi vokas. Ĉiuj tri aspektas same en la retumilo, kaj tial homoj restartigas la tunelon dum horo kaj lernas nenion.

Jen la mito, kiun indas mortigi unue: funkcianta tunelo ne estas vojo reen enen. Ĝi estas nova reta alkroĉo kun propraj fido-demandoj, kaj ĝi povas silente forigi vian malnovan administran vojon dum ĝi malfermas novan, kiun neniu reviziis.

La tunelo neniam estis la administra vojo

Plusendado kaj enigo estas malsamaj taskoj. "Ĉu kliento povas atingi la NAS-on tra la tunelo?" estas plusenda demando pri pakaĵoj, kiuj pasas tra la enkursigilo. "Ĉu mi povas malfermi la SSH-pordon de la enkursigilo?" estas eniga demando pri pakaĵoj adresitaj al la enkursigilo mem. Permesa regulo verkita por plusendita trafiko faras nenion por la dua, kaj tio estas la plej ofta kialo, kial tunelo, kiu portas trafikon perfekte, tamen rifuzas vian administran seancon.

La kontraŭa eraro estas fidi interfacan nomon. Tunelo estas ĉifrita al la samtavolano, ne al ĉiu servo malantaŭ ĝi, kaj la vorto VPN en interfaca etikedo diras nenion pri tio, kiaj fontoj rajtas ensaluti.

Unua tavolo: ĉu ekzistas vojo al la propra adreso de la enkursigilo?

Komencu sur la kliento kaj demandu la kernon, kien la pakaĵo iros. En Linux ip route get 10.6.0.1 presas la elektitan vojon, la eliran interfacon kaj la fontan adreson. Se ĝi raportas la defaŭltan vojon al via provizanto, la pakaĵo neniam eniras la tunelon, kaj neniu regulo sur la enkursigilo povas savi ĝin.

La tunela flanko havas sian propran version de la demando. WireGuard traktas AllowedIPs kiel kriptoŝlosilan enkursigan tabelon: ĉe ĉiu fino ĝi deklaras, kiujn fontajn adresojn samtavolano rajtas uzi kaj kiuj celoj estas sendataj al tiu samtavolano. Se la klienta enskribo ne inkluzivas la tunelan adreson de la enkursigilo, la kliento havas neniun vojon al ĝi. Se la servila enskribo por tiu kliento ne kovras la tunelan adreson de la kliento, la servilo forĵetas la pakaĵon antaŭ ol konsulti iun ajn fajroŝirman regulon.

Konfirmu la precizan adreson, kiun vi atendas atingi, antaŭ ol sencimigi la politikon. Kaduka DNS-enskribo aŭ kaŝmemorita najbara enskribo de antaŭ la ŝanĝo sendas vin al adreso, kiun la enkursigilo neniam posedis.

Dua tavolo: la eniga politiko, ne la plusenda politiko

Fajroŝirmiloj taksas regulojn sur la interfaco, kie la pakaĵo alvenas. En pfSense kaj OPNsense la interfaca langeto kaj la regula ordo decidas, ĉu trafiko al la propraj servoj de la fajroŝirmilo estas permesita; regulo, kiu lasas LAN-klientojn al la interreto, ne estas regulo, kiu permesas al tunela samtavolano malfermi la retan GUI-on. En OpenWrt kun firewall4 ĉiu zono portas enigan politikon, option input 'ACCEPT' aŭ 'REJECT', kaj tunela interfaco en zono kun enigo REJECT rifuzos administrajn konektojn dum ĝi ankoraŭ plusendas trafikon, se plusendado estas permesita.

Ne malŝaltu la kontraŭŝlosa regulon por igi la novan vojon funkcii. Tiu regulo malhelpas, ke malbona regulo ŝlosu la LAN-administran adreson; ĝi protektas la LAN-subreton, ne la tunelan subreton, kiun vi ĵus kreis. Aldonu unu mallarĝan regulon por la administranta fonto kaj lasu la sekurecan reton trankvila. La pfSense dokumentaro pri administra aliro klarigas, kie tiuj kontroloj troviĝas.

# 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

Tria tavolo: ĉu io ajn aŭskultas sur tiu adreso?

Servo povas funkcii kaj tamen esti neatingebla, ĉar ĝi ligiĝis al unu adreso. La uhttpd de OpenWrt tenas eksplicitajn aŭskultajn enskribojn en /etc/config/uhttpd, ekzemple list listen_http '0.0.0.0:80'; konstruo, kiu ligiĝas nur al la LAN-adreso, akceptas nenion sur la tunela adreso, kaj produktoj, kiuj elmontras agordon pri aŭskulta interfaco, kondutas same. La aŭskultaj komandoj supre respondas tion rekte.

Poste apartigu rifuzon de silento. nc -vz 10.6.0.1 443, kiu redonas rifuzitan konekton, signifas, ke la pakaĵo atingis la enkursigilon kaj io rifuzis ĝin, ĉu fermita pordo ĉu eksplicita rifuza regulo. Pendo ĝis tempolimo signifas, ke la pakaĵo estis forĵetita aŭ neniam enkursigita. Tiu distingo diras al vi, kiun tavolon kontroli poste, kaj ĝi kostas kvin sekundojn.

VPN-interfaco estas limo, ne reakira vojo

Ĉifrado protektas la draton; ĝi diras nenion pri tio, kiu rajtas malfermi la administran paĝon. Post kiam la tunelo funkcias, rezistu la impulson solvi atingeblon permesante ĉion sur la tunela interfaco. Donu al administrantoj regulon ligitan al ilia propra tunela adreso aŭ apartan tunelon nur por administrantoj, kaj tenu ordinarajn uzantojn, la NAS-on, la fotilojn kaj la familiajn tekkomputilojn for de la administra pordo. Samtavolano, kiu bezonas dosierkunhavigon, ne devus esti unu regulo for de la ensaluto de la enkursigilo.

La rolo de la enkursigilo ŝanĝas la respondon. Enkursigilo, kiu finas la tunelon, povas laŭleĝe akcepti administrantojn el ĝi, dum enkursigilo, kiu uzas la tunelon nur kiel interretan eliron, kutime ne devus. En ambaŭ kazoj la subreta permeso ne estas la ensaluto, do tenu kontan aŭtentikigon kaj transportan sekurecon ŝaltitaj.

La kompensa movo, kiun homoj faras post ŝloso, estas pli malbona: ŝalti WAN-administradon aŭ plusendi pordon al la reta GUI. Tio transformas mallongan paneon en daŭran elmeton, kaj la ensaluta paĝo tiam estas atingebla por ĉiu skanilo en la interreto. Testu ankaŭ la rifuzitan flankon, ne nur la permesitan, por ke samtavolano, kiu ne devus havi administran aliron, ricevu tempolimon aŭ rifuzon anstataŭ ensalutan inviton.

Testu ankaŭ per freŝa konekto. Stateca fajroŝirmilo tenas ekzistantajn fluojn en sia stata tabelo, do la SSH-sesio, kiun vi jam havas malfermita, povas postvivi ŝanĝon, kiu blokas ĉiun novan konekton. Tiel ŝloso restas nevidebla ĝis la sekva restartigo aŭ la sekva dormo de la tekkomputilo.

Preparu la vojon reen antaŭ ol tuŝi la politikon

Skribu kvar aferojn antaŭ la unua ŝanĝo: kiel vi atingos la aparaton, se la tunelo mortos, ekzemple per seria konzolo, provizanta konzolo aŭ maŝino en la LAN; kien la nuna agordo estas eksportata; kiun unu regulon aŭ vojon vi baldaŭ modifos; kaj kiel vi restarigos precize tiun eron. En OpenWrt sysupgrade -b /tmp/backup.tar.gz kaptas la agordon, kaj redaktoj restas pritraktataj ĝis uci commit, kio donas al vi malmultekostan malfaron, se vi rimarkas ĝustatempe. pfSense tenas agordan historion, kaj AutoConfigBackup helpas nur se ĝi jam estis ŝaltita. Se la enkursigilo uzas fail-closed regulan aron, konfirmu, ke la planita prizorga vojo ne troviĝas ene de la trafiko, kiun tiu regulo blokas, kaj memoru, ke restartigo reaplikas persistentajn regulojn anstataŭ forigi ilin.

Ŝanĝu unu limon per provo, poste testu el nova konekto anstataŭ el la ŝelo, kiun vi tenas malfermita. Se la testo malsukcesas, restarigu tiun unu ŝanĝon antaŭ ol tuŝi la sekvan tavolon. La tunelo povas resti supren la tutan tempon, sed ĝia verda stata ikono ne estas pruvo, ke vi ankoraŭ povas eniri.

Rapida kontrolo antaŭ ol foriri:

• Ĉu vi povas atingi la enkursigilon el fonto, kiu ne dependas de la regulo, kiun vi ĵus redaktis?
• Ĉu la eniga politiko sur la tunela interfaco permesas nur la administrantan fonton?
• Ĉu la administra servo estas ligita al adreso, kiu ekzistas sur la tunelo?
• Ĉu vi testis unu rifuzitan samtavolanon kaj unu freŝan sesion?
• Ĉu la WAN-administra surfaco ankoraŭ estas fermita?