Klienti VPN në një server LAN: pse përgjigjet dalin në rrugën e gabuar

Simptomat ndjekin një formë të vetme: një host punon, pastaj lidhet me një VPN si klient dhe tani klientët LAN e arrijnë ndërsa përgjigjet e tij zhduken. Një kapje në host tregon se përgjigjet dalin përmes pajisjes së tunelit në vend të ndërfaqes LAN. Asgjë në tunel nuk është prishur dhe rregullimi është një rutë, jo një rilidhje. Kryeni katër kontrollet më poshtë me radhë dhe ndaloni te i pari që dështon.

Një përgjigje është një paketë e re, jo një kthim mbrapsht

Ndihmon të hiqet dorë nga ideja se një përgjigje kthehet në të njëjtën rrugë që mori një kërkesë. Rrugëtimi vendoset për çdo paketë, për çdo drejtim, në hostin që dërgon. Një kërkesë që erdhi nga 10.64.0.23 brenda tunelit nuk krijon asnjë rrugë kthimi; kur hosti përgjigjet, ajo përgjigje krahasohet me tabelën si paketë e re dhe del në rrugën që fiton.

Kjo është arsyeja pse një klient me tunel të plotë në një makinë që shërben edhe një LAN prodhon një dështim kaq konfuz. Klienti instalon një rutë të paracaktuar, ose dy gjysma ruta të paracaktuara që preferojnë disa klientë, dhe përgjigja ndaj një klienti LAN tani përputhet me tunelin. Shkon te ofruesi, i cili nuk ka arsye ta përcjellë, dhe klienti LAN sheh një skadim kohe edhe pse hosti është aktiv dhe përgjigjet lokalisht. Kapja e bën të qartë dhe tabela e rrugëtimit e shpjegon.

Mbani dy nënrrjeta në mendje ndërsa lexoni pjesën tjetër. Njëra është grupi i adresave VPN nga vijnë klientët e largët, në këtë shembull 10.64.0.0/24. Tjetra është LAN-i që duhet të vazhdojë të punojë, 172.16.24.0/24 me ruterin e tij në 172.16.24.1. Gabimi është se trafiku mes tyre vendoset nga ruta e paracaktuar.

Vërtetojeni me kapjen dhe kërkimin

Përpara se të ndryshoni çdo gjë, konfirmoni cilën pajisje do të përdorë përgjigja. Një kërkim është më i shpejtë se një kapje dhe përgjigjet saktësisht pyetjes së cilës bërthama do t'i përgjigjet kur paketa ndërtohet.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

Lexoni përgjigjen në dy pjesë. Nëse emërton dev tun0, hosti do ta enkapsulojë përgjigjen dhe do t'ia dorëzojë ofruesit, dhe klienti LAN nuk do ta shohë kurrë. Nëse emërton dev eth0 por klienti vazhdon të skadojë, ruta është tashmë e saktë dhe paketa hidhet më vonë, që është një problem tjetër me një rregullim tjetër.

Kapja në të njëjtin hap zgjidh dyshimin që ping nuk mund ta zgjidhë. Një jehonë përgjigjeje që arrin klientin LAN dëshmon se një rrugë e caktuar punon, jo cila ndërfaqe e mbajti, prandaj bëni kapjen në vetë hostin dhe vëzhgoni nga dalin kornizat. Printeri në të njëjtën nënrrjetë vazhdon të përgjigjet, sepse rruga e tij e drejtpërdrejtë është më specifike se ruta e paracaktuar e tunelit. Një port i përcjellë dështon saktësisht si çdo rrjedhë tjetër, sepse ndërfaqen e zgjedh tabela dhe jo lidhja.

Instaloni rutën më të ngushtë që e tejkalon tunelin

Vendos gjatësia e prefiksit, jo metrika, prandaj një rutë për grupin e klientëve përmes ruterit LAN fiton mbi çdo rutë të paracaktuar që instalon klienti VPN. Kirurgjia e metrikës nuk nevojitet dhe ruta e paracaktuar mund të mbetet saktësisht aty ku e vendosi klienti.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

Përdorni replace në vend të add, sepse një klient që rilidhet do të ketë instaluar hyrjen e vet dhe një add i dytë dështon me një gabim rruge ekzistuese që lexohet si problem lejesh. Në një host Windows ekuivalenti është route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p, ku -p e mban hyrjen përgjatë rinisjeve, pasi klienti mund ta rindërtojë tabelën kur tuneli kthehet. Në një host Windows aktual ekuivalenti i mbështetur është New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore, ndërsa komanda më e vjetër route ruhet si formë e trashëguar.

Një detaj vendos nëse kjo është e saktë apo vetëm e besueshme: hopi i ardhshëm duhet të jetë ruteri që zotëron vërtet rrugën e kthimit te klientët. Drejtimi i rutës nga një adresë që arrihet vetë përmes tunelit krijon një lak që shfaqet si humbje me ndërprerje dhe jo si dështim i pastër. Konfirmoni që hopi i ardhshëm është në nënrrjetën LAN përpara se ta vërtetoni rreshtin.

Mbajeni përgjigjen pas një rilidhjeje

Një rutë e shtuar me dorë mbijeton në rastin më të mirë deri në rilidhjen tjetër. Nëse grupi i klientëve është dinamik, fiksojeni në konfigurimin e serverit që prefiksi që rrugëtuat të mbetet prefiksi që marrin klientët; përndryshe hyrja tregon një interval bosh dhe simptoma kthehet javë më vonë pa një shkak të qartë. Shkrimi i rutës në skriptin up të vetë klientit është opsioni tjetër i besueshëm, sepse ekzekutohet pasi klienti ka rishkruar tabelën.

Një firewall me gjendje prapë mund të mposhtë një rutë të saktë. Nëse kapja tani tregon se përgjigja del përmes eth0 dhe klienti vazhdon të skadojë, kontrolloni nëse hosti po e hedh paketën përpara se ta dërgojë. Filtrimi i rreptë i rrugës së kundërt dhe net.ipv4.conf.all.rp_filter i vendosur në 1 hedhin paketat burimi i të cilave nuk do të rrugëtohej prapa përmes ndërfaqes nga e cila mbërritën, dhe ky është pikërisht rasti asimetrik që sapo krijove dhe më pas rregullove, ndërsa gjendja e conntrack tregon të njëjtën histori për portet e përcjella.

Kontrolli i fundit është ai që njerëzit e kapërcejnë: përsëritni kërkimin pasi tuneli ka rënë dhe është ngritur përsëri. Katër vlera duhet të përputhen me atë që shënuat: destinacioni, hopi i ardhshëm, pajisja dhe burimi i zgjedhur. Nëse ndonjëra lëvizi, klienti rishkroi tabelën dhe rregullimi i përket grepave të tij dhe jo historisë së shell.