Pse një server pas një klienti VPN përgjigjet përmes tunelit

Lidhjet hyrëse drejt një hosti që ekzekuton gjithashtu një klient VPN dështojnë në një mënyrë shumë specifike: shtrëngimi i duarve arrin, daemoni përgjigjet dhe klienti nuk merr asgjë mbrapsht. Asgjë nuk e bllokon portin. Përgjigja doli përmes tunelit, sepse tuneli zotëron rrugën e paracaktuar dhe kerneli i drejton përgjigjet sipas destinacionit, jo sipas kujtesës se nga erdhi kërkesa. Ky lëshim i vetëm shpjegon çdo simptomë që vijon.

Përgjigja drejtohet, nuk mbahet mend

Një klient VPN që instalon një rrugë të paracaktuar shton një hyrje që tejkalon portën LAN, qoftë me metrikë, qoftë duke e ndarë hapësirën në dy gjysma më të sakta. Paketat dalëse tani zgjedhin ndërfaqen e tunelit. Kerneli nuk pyet kurrë se nga erdhi fillimisht paketa së cilës po i përgjigjet. Ky lëshim i vetëm shpjegon çdo simptomë që vijon.

Drejtimi përpara drejtohet sipas destinacionit, dhe ai i kthimit gjithashtu. Përgjigja i adresohet një klienti publik, të cilin tuneli do ta mbajë me kënaqësi. Fundi i largët merr një paketë burimin e së cilës nuk e zotëron, e hedh atë, dhe klienti origjinal pret derisa të skadojë koha.

Filtrimi i rreptë i rrugës së kthimit mund ta hedhë paketën hyrëse para se daemoni ta lexojë fare. Kontrolloni së pari atë numërues, sepse hedhja nga filtri dhe gabimi i routing-ut duken njësoj nga jashtë.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Komanda e parë tregon cila rrugë e paracaktuar fiton tani. E dyta raporton nëse filtrimi i rreptë zbatohet globalisht apo për çdo ndërfaqe, dhe e treta tregon çdo rregull të zinxhirit të përcjelljes që mund të jetë i përfshirë.

Tre mënyra për të ruajtur rrugën e kthimit

Përjashtimi i destinacionit të shërbimit nga tuneli është opsioni më i ngushtë. Një rrugë hosti e drejtuar drejt portës LAN, plus një daemon i lidhur me adresën fizike në vend të çdo adrese, e mban atë rrjedhë të vetme jashtë tunelit. Ndryshimi është lokal dhe i lehtë për t'u kthyer.

Routing-u me politikë është përgjigja e përgjithshme. Një rregull i lidhur me adresën e burimit ose me një shenjë të murit të zjarrit zgjedh një tabelë, rruga e paracaktuar e së cilës tregon drejt portës WAN, ndërsa lidhjet e vetë hostit vazhdojnë të përdorin tunelin. Mbajeni përparësinë të qartë, që rregulli të mos mbulohet më vonë.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Dy komandat e para ndërtojnë rrugën alternative për përgjigjet me burim në adresën publike. E treta pyet kernelin se cilën rrugë do të merrnin saktësisht ai burim dhe ai destinacion, dhe kështu konfirmoni se rregulli ka ndonjë efekt.

Përkthimi i burimit është opsioni i tretë dhe i vetmi që mbijeton përballë një routeri që tashmë bën NAT përpara shërbimit. Përgjigja duhet të kthehet te ai router, dhe maskimi drejt ndërfaqes WAN e arrin këtë duke e fshehur klientin nga regjistrat e shërbimit. Zëvendësimi me dorë i rrugës së paracaktuar pas lidhjes është diagnostikim, sepse klienti e rishkruan tabelën në rilidhjen tjetër.

Kur kutia rrugëton edhe për një LAN

I njëjti dështim shfaqet një hop më tej kur hosti rrugëton për pajisjet pas tij. Një lidhje hyrëse përcillet te një pajisje e brendshme, rruga e vetme e kthimit e së cilës është tuneli, dhe përgjigja arrin te klienti i jashtëm nga adresa e ofruesit. Pajisja e brendshme punon saktë gjatë gjithë kohës.

Atëherë gjurmimi i lidhjeve sheh një përgjigje për një rrjedhë që nuk e regjistroi kurrë dhe e hedh atë. Përkthimi i destinacionit e dërgon lidhjen hyrëse te pajisja, dhe përkthimi i burimit e bën përgjigjen të duket sikur vjen nga vetë routeri.

Një rrugë politike që e mban portin e përcjellë në WAN ndërsa trafiku i vetë routerit përdor tunelin është ekuivalenti më i pastër. Pa përkthim burimi përgjigja i adresohet klientit të jashtëm, dhe pajisja e brendshme nuk ka fare rrugë drejt asaj adrese.

Tre sonda që i ndajnë shkaqet

Kryeni tre sonda: një lidhje drejt kutisë nga interneti, një lidhje prej saj drejt një hosti publik dhe një kërkim emri. Kur dy të parat nuk përputhen, rruga e kthimit është fajtore. Kur emrat dështojnë në të dy drejtimet, zgjidhësi është një defekt tjetër që thjesht ndan tunelin.

Rregulloni së pari çështjen e routing-ut, pastaj shikoni emrat. Përzierja e të dyjave është mënyra se si një server që punon fajësohet për një zgjidhës të prishur.

Shënoni cilën ndërfaqe përmend përjashtimi dhe mbani konfigurimin nën kontrollin e versioneve. Një rregull i shkruar kundër një ndërfaqeje që riemërtohet pas një përditësimi kalon sot dhe dështon pas rindezjes tjetër.