Pse administrimi i ruterit nuk përgjigjet më pas një ndryshimi VPN

Ndryshove një rrugë ose një rregull muri zjarri për të testuar një tunel në ruter, dhe tani faqja e administrimit nuk përgjigjet nga laptopi që punonte mirë dhjetë minuta më parë. Refleksi është të fajësosh VPN-në. Shumicën e kohës tuneli është i shëndoshë dhe një nga tri gjëra të tjera është prishur: nuk ka rrugë kthimi drejt adresës së vetë ruterit, një politikë hyrjeje e hedh poshtë kërkesën, ose një shërbim web nuk dëgjon në adresën që po thërret. Të tria duken njësoj në shfletues, prandaj njerëzit rinisin tunelin për një orë dhe nuk mësojnë asgjë.

Ja miti që ia vlen të vritet i pari: një tunel që punon nuk është rrugë kthimi brenda. Është një lidhje e re rrjeti me pyetjet e veta të besimit, dhe mund të heqë në heshtje rrugën e vjetër të menaxhimit ndërsa hap një të re që askush nuk e ka shqyrtuar.

Tuneli nuk ishte kurrë rruga e menaxhimit

Përcjellja dhe hyrja janë punë të ndryshme. «A mund të arrijë një klient NAS përmes tunelit?» është pyetje përcjelljeje për paketat që kalojnë nëpër ruter. «A mund ta hap portën SSH të ruterit?» është pyetje hyrjeje për paketat e drejtuara vetë ruterit. Një rregull lejimi i shkruar për trafikun e përcjellë nuk bën asgjë për pyetjen e dytë, dhe kjo është arsyeja më e zakonshme pse një tunel që transporton trafikun në mënyrë të përsosur gjithsesi refuzon sesionin tënd të administrimit.

Gabimi i kundërt është t'i besosh një emri ndërfaqeje. Tuneli kriptohet drejt partnerit, jo drejt çdo shërbimi pas tij, dhe fjala VPN në një etiketë ndërfaqeje nuk thotë asgjë për burimet që duhet të lejohen të hyjnë.

Shtresa e parë: a ka rrugë drejt adresës së vetë ruterit?

Nis në klient dhe pyet bërthamën se ku do të shkojë paketa. Në Linux, ip route get 10.6.0.1 shtyp rrugën e zgjedhur, ndërfaqen e daljes dhe adresën e burimit. Nëse raporton rrugën e paracaktuar drejt ofruesit tënd, paketa nuk hyn kurrë në tunel, dhe asnjë rregull në ruter nuk mund ta shpëtojë.

Ana e tunelit ka versionin e vet të pyetjes. WireGuard e trajton AllowedIPs si një tabelë rrugëtimi me çelës kriptografik: në çdo skaj deklaron cilat adresa burimi mund të përdorë partneri dhe cilat destinacione dërgohen te ai partner. Nëse hyrja e klientit nuk përfshin adresën e tunelit të ruterit, klienti nuk ka rrugë drejt saj. Nëse hyrja e serverit për atë klient nuk mbulon adresën e tunelit të klientit, serveri e hedh paketën përpara se të shohë çdo rregull muri zjarri.

Konfirmo adresën e saktë që pret të arrish përpara se të korrigjosh politikën. Një regjistrim DNS i vjetruar ose një hyrje fqinji e ruajtur në memorje nga përpara ndryshimit të çon në një adresë që ruteri nuk e ka pasur kurrë.

Shtresa e dytë: politika e hyrjes, jo politika e përcjelljes

Muret e zjarrit vlerësojnë rregullat në ndërfaqen ku mbërrin paketa. Në pfSense dhe OPNsense, skeda e ndërfaqes dhe renditja e rregullave vendosin nëse trafiku drejt shërbimeve të vetë murit të zjarrit lejohet; një rregull që lë klientët LAN të dalin në internet nuk është rregull që lejon një partner tuneli të hapë ndërfaqen web. Në OpenWrt me firewall4 çdo zonë mbart një politikë hyrjeje, option input 'ACCEPT' ose 'REJECT', dhe një ndërfaqe tuneli në një zonë me hyrje REJECT do të refuzojë lidhjet e menaxhimit ndërsa vazhdon të përcjellë trafikun nëse përcjellja lejohet.

Mos e çaktivizo rregullin kundër bllokimit që rruga e re të punojë. Ai rregull e pengon një rregull të keq të bllokojë adresën e menaxhimit LAN; mbron nënrrjetin LAN, jo nënrrjetin e tunelit që sapo krijove. Shto një rregull të ngushtë për burimin e administratorit dhe lëre rrjetën e sigurisë në paqe. Dokumentacioni i pfSense për aksesin e administratorit shpjegon ku ndodhen ato kontrolle.

# 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

Shtresa e tretë: a dëgjon ndonjë gjë në atë adresë?

Një shërbim mund të jetë duke punuar dhe gjithsesi i paarritshëm, sepse është lidhur me një adresë të vetme. uhttpd i OpenWrt mban hyrje dëgjimi të shprehura në /etc/config/uhttpd, për shembull list listen_http '0.0.0.0:80'; një ndërtim që lidhet vetëm me adresën LAN nuk pranon asgjë në adresën e tunelit, dhe produktet që ekspozojnë një rregullim ndërfaqeje dëgjimi sillen njësoj. Komandat e dëgjimit më sipër përgjigjen drejtpërdrejt për këtë.

Pastaj ndaj refuzimin nga heshtja. nc -vz 10.6.0.1 443 që kthen një lidhje të refuzuar do të thotë se paketa arriti ruterin dhe diçka e refuzoi, ose një portë e mbyllur ose një rregull i shprehur refuzimi. Mbetja e varur deri në skadim do të thotë se paketa u hodh ose nuk u rrugëtua kurrë. Ky ndryshim të tregon cilën shtresë të shqyrtojë më pas, dhe kushton pesë sekonda.

Një ndërfaqe VPN është kufi, jo rrugë rikuperimi

Kriptimi mbron telin; nuk thotë asgjë për kë mund të hapë faqen e administrimit. Pasi tuneli punon, kundërshtoje shtysën për të zgjidhur arritshmërinë duke lejuar gjithçka në ndërfaqen e tunelit. U jep administratorëve një rregull të lidhur me adresën e tyre të tunelit ose një tunel të veçantë vetëm për administratorë, dhe mbaji përdoruesit e zakonshëm, NAS-in, kamerat dhe laptopët e familjes larg portës së menaxhimit. Një partner që ka nevojë për ndarje skedarësh nuk duhet të jetë një rregull larg hyrjes në ruter.

Roli i ruterit ndryshon përgjigjen. Një ruter që e përfundon tunelin mund të pranojë ligjërisht administratorë prej tij, ndërsa një ruter që e përdor tunelin vetëm si dalje interneti zakonisht nuk duhet. Në të dyja rastet leja e nënrrjetit nuk është hyrja, prandaj mbaji aktive vërtetimin e llogarisë dhe sigurinë e transportit.

Lëvizja kompensuese që njerëzit bëjnë pas një bllokimi është më e keqe: aktivizimi i administrimit përmes WAN ose përcjellja e një porte drejt ndërfaqes web. Kjo e kthen një ndërprerje të shkurtër në një ekspozim të përhershëm, dhe faqja e hyrjes atëherë është e arritshme për çdo skaner në internet. Provo edhe anën e refuzuar, jo vetëm atë të lejuar, që një partner që nuk duhet të ketë akses administratori të marrë skadim ose refuzim në vend të një kërkese hyrjeje.

Provo edhe me një lidhje të re. Një mur zjarri me gjendje i mban rrjedhat ekzistuese në tabelën e vet të gjendjeve, kështu që sesioni SSH që e ke tashmë të hapur mund t'i mbijetojë një ndryshimi që bllokon çdo lidhje të re. Kështu një bllokim mbetet i padukshëm deri në rinisjen tjetër ose gjumin tjetër të laptopit.

Përgatit rrugën e kthimit përpara se të prekësh politikën

Shkruaj katër gjëra përpara ndryshimit të parë: si do ta arrish pajisjen nëse tuneli vdes, për shembull një konsolë serike, konsola e ofruesit ose një makinë në LAN; ku eksportohet konfigurimi aktual; cilin rregull ose rrugë të vetme do të ndryshosh; dhe si do ta kthesh saktësisht atë element. Në OpenWrt, sysupgrade -b /tmp/backup.tar.gz e kap konfigurimin, dhe ndryshimet mbeten në pritje deri në uci commit, gjë që të jep një zhbërje të lirë nëse e vëren në kohë. pfSense mban një histori konfigurimi, dhe AutoConfigBackup ndihmon vetëm nëse ishte aktivizuar më parë. Nëse ruteri ekzekuton një grup rregullash fail-closed, konfirmo që rruga e mirëmbajtjes që ke planifikuar nuk është brenda trafikut që bllokon ai rregull, dhe mos harro që një rinisje i zbaton përsëri rregullat e përhershme në vend që t'i fshijë.

Ndrysho një kufi për provë, pastaj testo nga një lidhje e re në vend të shell-it që mban hapur. Nëse testi dështon, ktheje atë ndryshim të vetëm përpara se të prekësh shtresën tjetër. Tuneli mund të mbetet lart gjatë gjithë kohës, por ikona e tij e gjelbër e gjendjes nuk është provë që mund të hysh ende.

Kontroll i shpejtë përpara se të ikësh:

• A mund ta arrish ruterin nga një burim që nuk varet nga rregulli që sapo redaktove?
• A lejon politika e hyrjes në ndërfaqen e tunelit vetëm burimin e administratorit?
• A është shërbimi i menaxhimit i lidhur me një adresë që ekziston në tunel?
• A ke testuar një partner të refuzuar dhe një sesion të re?
• A është sipërfaqja e administrimit përmes WAN ende e mbyllur?