Përgjigjja e VPN-së nga sajti në sajt nuk kalon në tunel

Kalova një mëngjes me një tunel që u ngrit pastër dhe transportonte trafikun saktësisht në një drejtim: dega arrinte serverin e skedarëve në seli, dhe çdo lidhje e hapur nga selia drejt degës vdiste në SYN-in e parë. SA-të ishin aktive, numëruesit e tunelit po rriteshin, dhe shtrëngimi i duarve nuk ishte kurrë problemi. Përgjigjja po rrugëtohej diku që tuneli nuk e mbulon, dhe ajo zgjedhje i përket anës së largët. Një VPN nga sajti në sajt transporton vetëm paketat që një host ia dorëzon portës, dhe çdo host e bën atë zgjedhje veçmas, në çdo drejtim, nga tabela e vet e rrugëtimit.

Të dy drejtimet rrugëtohen veçmas

IP nuk mban asnjë kujtesë për drejtimin e një bisede. Çdo host që dërgon një paketë kryen kërkimin e vet të prefiksit më të gjatë, zgjedh një hap tjetër dhe e harron vendimin. Kërkesa dhe përgjigjja janë dy paketa të palidhura që rastësisht i përkasin të njëjtës lidhje, dhe tuneli është një hap që secili prej tyre mund ta përdorë ose jo. Asgjë në shkëmbimin IKE nuk i mëson serverit të largët si të arrijë në nënrrjetin tuaj; negociimi bie vetëm dakord se cilët prefikse mund të kriptohen.

Ai marrëveshje është porta e dytë. Në strongSwan selektorët e trafikut janë leftsubnet dhe rightsubnet, dhe një paketë, burimi ose destinacioni i së cilës bie jashtë çiftit të negociuar, nuk kriptohet, çfarëdo që thotë tabela e rrugëtimit. Një prefiks që rrugëtohet në tunel por mungon në selektorë është një dështim i heshtur njëkahësh: rruga duket e saktë, paketa prapë del e hapur ose hidhet, dhe vetëm regjistri i charon ankohet.

Hosti i largët nuk di asgjë për tunelin tuaj

Brenda LAN-it të largët përgjigjja është një paketë e zakonshme drejtuar klientit tuaj. Hosti i destinacionit nuk sheh asnjë kokë IPsec dhe nuk ka arsye të preferojë portën VPN; kërkon prefiksin tuaj, nuk gjen asgjë më të saktë se rruga e tij e paracaktuar dhe e ndjek atë. Nëse e paracaktuara tregon një mur zjarri bazë, muri ose ka një rrugë kthimi në tunel ose nuk ka. Kur nuk ka, merrni një hedhje të heshtur, një ICMP unreachable ose një përgjigje që del nga ndërfaqja e kthyer nga interneti dhe vdes.

Një ndërfaqe e dytë mjafton për ta prishur këtë edhe kur ekziston një rrugë. Një NAS me lidhje administrimi në një VLAN tjetër, një server me uplink rezervë, një rregull politike që dërgon një interval burimesh në një tabelë të dytë: cilado prej tyre mund ta kapë përgjigjjen. Në Linux, ip rule show dhe ip route show table all shfaqin rregulla dhe tabela që lista e paracaktuar i fsheh.

Lexoni vendimin në makinën që dërgon përgjigjjen

Pyetni kernelin përpara se të ndryshoni diçka, dhe jepini adresën e burimit, sepse rregullat që varen nga burimi e ndryshojnë përgjigjjen.

ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"

Dalja përmend ndërfaqen dalëse dhe hapin tjetër. Nëse ndërfaqja nuk është ajo që shikon drejt portës VPN, e keni gjetur defektin, dhe puna e mbetur është të zgjidhni ku duhet të jetë rruga. Një ping nga porta provon pak këtu: përgjigjet me një adresë që hosti i largët mund ta vendosë, jo me adresën e laptopit tuaj.

Në Windows ekuivalentët janë Find-NetRoute -RemoteIPAddress 10.10.5.10 për vendimin dhe Get-NetRoute për tabelën. Një rrugë e shtuar me New-NetRoute që mban metrikë më të lartë se e paracaktuara humbet në heshtje, prandaj lexoni kolonën e metrikës, jo hyrjen. Pastaj konfirmoni me paketa: tcpdump -ni any "host 10.10.5.10 and tcp port 445" në ndërfaqen LAN të largët tregon kërkesën, dhe i njëjti filtër në anën e tunelit tregon nëse u kthye një përgjigjje. Kërkesa e dukshme pa përgjigjje do të thotë që përgjigjja u rrugëtua diku tjetër ose u hodh; një përgjigjje në ndërfaqen e gabuar ju jep fajtorin përpara se të prekni një rrugë.

Kur porta e serverit nuk është pika fundore e VPN-së

Shumë sajte vendosin një mur zjarri midis serverëve dhe koncentratorit. Ai mur e përçon përgjigjjen, kështu që ka nevojë për një rrugë për prefiksin e klientit tuaj drejt portës VPN, dhe politikë përçimi në të dy drejtimet. Pajisjet me gjendje e përkeqësojnë: kërkesa kaloi murin nga një host LAN që ai e lejoi, përgjigjja tani vjen nga një drejtim tjetër, dhe hyrja e gjurmimit të lidhjes nuk përputhet më, ndaj paketa hidhet si e pavlefshme në vend që të refuzohet. Kjo është arsyeja pse regjistri i politikës duket bosh ndërsa trafiku zhduket.

Porta ka filtrin e vet të dytë. Filtrimi i rrugës së kundërt në Linux hedh paketat, burimi i të cilave nuk është i arritshëm përmes ndërfaqes nga e cila mbërritën, dhe kjo është saktësisht forma e një rruge kthimi asimetrike legjitime. udhëzuesi i përçimit i strongSwan kërkon pikërisht për këtë arsye net.ipv4.ip_forward dhe një net.ipv4.conf.all.rp_filter të liruar. Një vlerë e rreptë 1 në cilëndo portë thyen në heshtje një rrugë të saktë, dhe nstat -az tregon hedhjet nëse dini ku të shikoni.

Rrugëtoni ose përktheni, pastaj verifikoni në të dy drejtimet

Dy riparimet nuk janë ekuivalente. Shtimi i një rrugë e mban adresën e klientit të paprekur, prandaj rregullat e bazuara në burim, regjistrat e auditimit dhe aplikacionet që regjistrojnë telefonuesin vazhdojnë të punojnë; çmimi është që çdo hap që merr vendimin ka nevojë për rrugën, pra më shumë vende për gabim. Maskimi në portën e largët e zvogëlon rrugën e kthimit në një hap, sepse përgjigjja tani drejtohet drejt vetë portës, dhe fsheh cili klient bëri çfarë.

iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADE

Zgjidheni me vetëdije: sapo klientët shfaqen si adresa e portës, ACL-të e bazuara në burim nuk i dallojnë më, dhe conntrack duhet ta mbajë hartëzimin që përgjigjja të rishkruhet përsëri në tunel. Nëse selektorët ende e përjashtojnë prefiksin e klientit, NAT nuk ndryshon asgjë, sepse kërkesa nuk hyri kurrë në tunel.

Përpara se ta shpallni të rregulluar, konfirmoni katër gjëra me radhë: rrugën në hostin që dërgon përgjigjjen, rrugën në çdo hap që e përçon, selektorët që mbulojnë të dy prefikset, dhe një regjistrim që tregon përgjigjjen duke hyrë në tunel me burimin që prisni. Pastaj përsëriteni provën nga sajti tjetër. Një drejtim që kalon është një projekt gjysmë i hapur, dhe drejtimi i dytë zakonisht dështon për një arsye tjetër nga ajo që sapo rregulluat.