VPN është i lidhur, por firewalls ende bllokon: si të dallohet cili

Klienti thotë i lidhur, burimi ende refuzon, dhe hapi tjetër i zakonshëm është të fikësh diçka. Dy kontrollet në atë fjali bëjnë punë të ndryshme: VPN ndërton një rrugë për trafikun e mbuluar, dhe një firewall vendos për çdo lidhje nëse trafiku mund të kalojë. Një tunel që funksionon me një politikë që refuzon duket saktësisht si një tunel i prishur nga karrigia e përdoruesit, prandaj detyra është të zbulosh cili nivel përgjigjet. Kjo është radha që ndjek, me leximin që ju thotë të ndaleni.

Ndani rrugën nga politika

Filloni me formën e dështimit, sepse është informacion falas. Hedhja e një pakete prodhon një afat: klienti riprovoi, asgjë nuk kthehet dhe komanda rri varur derisa të dorëzohet. Refuzimi prodhon një mohim ose një rivendosje: diçka u përgjigj dhe tha jo. Një shërbim që nuk dëgjon refuzon në vetë hostin, pa asnjë firewall.

Këto tre rezultate tregojnë nivele të ndryshme. Afati do të thotë që diku një politikë hedh në heshtje, ose rruga nuk largohet kurrë nga makina. Refuzuar do të thotë që arritët hostin dhe stiva e tij ose firewalls lokal refuzoi. Heshtje e plotë, me ndërfaqen e tunelit aktive dhe pa rrugë drejt destinacionit, do të thotë që rruga është e gabuar dhe asnjë rregull firewalls nuk e rregullon.

Lexoni rrugën me një kalim

Konfirmoni që tuneli mbulon destinacionin përpara se të shikoni edhe një rregull. Një tunel i ndarë që mban vetëm nënrrjetin e zyrës nuk do ta drejtojë një kërkesë në një gamë tjetër, dhe atëherë dështimi duket si bllokim i firewalls që nuk është:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Dalja e rrugës emërton ndërfaqen nga e cila do të dalë paketa dhe adresën burimore që do të mbajë. Nëse ajo ndërfaqe është karta juaj fizike e rrjetit dhe jo tuneli, problemi është në drejtimin e rrugës ose në gamat e lejuara të tunelit, dhe i përket konfigurimit të VPN, jo firewalls.

Një kurth specifik i VPN meriton kontrollin e vet. Në WireGuard, AllowedIPs i një partneri është njëkohësisht rrugë dhe filtër kriptografik: një paketë adresa burimore e së cilës nuk përputhet me grupin e lejuar të partnerit hidhet poshtë përpara se të konsultohet ndonjë rregull firewalls. Prandaj një firewall hosti plotësisht i saktë mund të qëndrojë pas një hedhjeje të heshtur që duket si politikë, dhe rregullimi është një rresht konfigurimi i çelësit, jo një rregull.

Lexoni politikën në nivelin që përgjigjet

Kur rruga është e saktë, kaloni politikën nga hosti drejt jashtë dhe vëreni nivelin e vetëm, numëratorët e të cilit lëvizin:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

Socketa që dëgjon përgjigjet një pyetjeje të ndryshme nga rregullat. Nëse asgjë nuk dëgjon në port, kerneli refuzon lidhjen dhe asnjë rregull hyrës nuk është i rëndësishëm. Nëse socketa ekziston dhe lidhja nga një klient i largët skadon, një hedhje po ndodh diku në rrugë, dhe numëratorët e rregullave ju thonë nëse po ndodh këtu.

Aktivizoni regjistrimin për profilin ose zinxhirin që dyshoni në vend që të hamendësoni nga jashtë. Një hedhje e regjistruar që emërton burimin, destinacionin dhe portin identifikon nivelin dhe rregullin, dhe gjithashtu provon që paketa mbërriti, gjë që asnjë test nga ana e klientit nuk mund ta vërtetojë.

Lexoni vendimin e portës kur tuneli mbaron atje

Në një portë vend-nga-vend ose akses të largët, VPN vërteton një përdorues dhe politika autorizon një burim, dhe këto janë dhënie të ndara. Përdoruesi i lejuar në tunel nuk lejohet automatikisht në çdo host të brendshëm, dhe refuzimi shpesh vjen nga një rregull përcjelljeje ndërsa vetë tuneli është i shëndetshëm. E njëjta ndarje shfaqet në IPsec, ku politika e sigurisë që zgjedh trafikun ndryshon nga filtri që e lejon, dhe prandaj të dyja dokumentohen si mekanizma të ndryshëm në RFC 4301.

Kontrolloni rrugën e kthimit po aq me kujdes sa atë të daljes. Filtrimi me gjendje duhet ta shohë përgjigjen, prandaj drejtimi asimetrik nëpër tunel në një drejtim dhe rreth tij në tjetrin prodhon hedhje që duken të rastësishme dhe riprodhohen vetëm nga disa klientë. Nëse trafiku arrin portën dhe ndalon, lexoni rregullin e përcjelljes dhe rrugën e kthimit së bashku përpara se të zgjeroni diçka.

Porta është gjithashtu vendi ku një rregull NAT ose maskimi mund të fshehë burimin e vërtetë. Nëse hostet e brendshme shohin adresën e portës në vend të klientit, rregullat e tyre të firewalls hosti që duhet të përputhen me grupin e klientëve nuk do të përputhen kurrë, dhe rregullimi i përket portës, jo çdo serveri.

Ndryshoni nivelin më të ngushtë, pastaj verifikoni

Rezistoni riparimit të gjerë. Çaktivizimi i firewalls hosti, shtimi i një rregulli që lejon gjithçka ose detyrimi i çdo ndërfaqeje në një profil të besuar heq çdo herë kontrollin që bënte punën e vet, dhe ndryshimi mbijeton incidentin. Një rregull i kufizuar në gamën burimore dhe portin në fjalë është më i lehtë për t'u rishikuar, më i lehtë për t'u hequr, dhe lë pjesën tjetër të politikës së makinës të paprekur.

Verifikoni me të njëjtin test që dështoi, nga i njëjti klient, dhe pastaj edhe një herë pas rilidhjes, sepse një rregull që përputhej përpara se tuneli të rinegociojë mund të ndalojë së përputhuri pas:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Përpara se ta mbyllni:

• Rruga drejt destinacionit del përmes ndërfaqes së tunelit, dhe adresa burimore përputhet me atë që pret politika.
• Diçka dëgjon në port, dhe refuzimi ose afati i atribuohet një rregulli të emërtuar, nuk supozohet.
• Porta përcjell në të dy drejtimet, dhe destinacioni sheh burimin për të cilin janë shkruar rregullat tuaja.
• Asnjë kontroll nuk u çaktivizua që testi të kalojë, dhe ndryshimi që bëtë emërton një gamë burimore dhe një port.