Pse shërbimi juaj publik Linux përgjigjet përmes VPN-së

Asgjë në socket nuk kujton se cili ndërfaqe e transportoi kërkesën, kështu që një rrugë e parazgjedhur VPN me tunel të plotë mund të kapë një përgjigje që i përket WAN-it. Shërbimi nuk e injoron ndërfaqen hyrëse; Linux e drejton një përgjigje të krijuar lokalisht sipas destinacionit dhe politikës së burimit. Një rregull i bazuar në burim mund të dërgojë vetëm përgjigjet e shërbimit përmes një tabele të plotë WAN, duke e lënë daljen e zakonshme në tunel. Porta mbetet e hapur ndërsa përgjigja del në rrugën e gabuar, dhe për këtë arsye simptoma duket e njëanshme.

Keqkuptimi: përgjigjet ndjekin ndërfaqen ku mbërritën

Duket logjike që një paketë që mbërrin në eth0 të dalë në eth0. Filtrat e paketave pa gjendje mund të shkruhen kështu, dhe tcpdump në anën hyrëse e tregon kërkesën pikërisht aty ku pritet. Rrugëtimi nuk funksionon kështu për trafikun që gjeneron vetë host-i.

Pasi shërbimi e pranon lidhjen, përgjigja e tij është një paketë e re e krijuar lokalisht. Kernel-i konsulton rregullat e rrugëtimit për destinacionin dhe burimin e përgjigjes, dhe rruga e parazgjedhur e VPN-së është një përgjigje plotësisht e vlefshme. Asgjë në socket nuk kujton se cili ndërfaqe e transportoi kërkesën.

Për këtë arsye simptoma duket e njëanshme: kërkesat vijnë, përgjigjet zhduken. Për këtë arsye edhe shtimi i një rregulli firewall për portën hyrëse nuk ndryshon asgjë. Paketa nuk bllokohet në rrugën hyrëse; ajo drejtohet diku tjetër në rrugën dalëse. Ndiqni përgjigjen me një kërkim të kualifikuar sipas burimit dhe devijimi bëhet i dukshëm.

Çfarë drejton në të vërtetë kernel-i: adresa e burimit

Doreza që ju nevojitet është adresa lokale që shërbimi përdor për përgjigjet. Në një host me adresën ilustruese eth0 192.0.2.10/24 dhe portën 192.0.2.1, ajo adresë është e pranishme në ndërfaqe. Në një VM në cloud, adresa publike mund të jetë përkthyer më lart dhe të mungojë në mysafir, prandaj përdorni adresën që host-i ka vërtet.

Inspektoni gjendjen aktuale përpara se të rezervoni një numër tabele ose një prioritet rregulli. Rregullat ekzistuese të politikës mund të mbulojnë një të re, dhe një tabelë e vjetër me të njëjtin numër mund të mbajë tashmë rrugë të palidhura:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Pastaj zgjidhni një tabelë sipas burimit. Rregulli përputhet me përgjigjet që mbajnë tashmë 192.0.2.10, pikërisht trafiku i përfunduar lokalisht që dëshironi të përjashtoni. Trafiku i përçuar dhe paketat nga adresa të tjera lokale nuk përputhen.

Ndërtoni një tabelë kthimi të plotë, jo gjysmë rruge të parazgjedhur

Një tabelë me vetëm një rrugë të parazgjedhur nuk mjafton. Kernel-i ende duhet të zgjidhë portën, dhe ai zgjidhje kërkon prefiksin e lidhur në të njëjtën tabelë. Një tabelë që i mungon ai prefiks dështon në zgjidhjen e portës edhe kur rruga e saj e parazgjedhur duket e saktë. Shtoni të dyja, pastaj drejtojeni rregullin e burimit te tabela:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Përdorni prefiksin dhe portën e vërtetë në vend që të kopjoni shembullin. Një ndërfaqe cloud e konfiguruar si /32 me portë on-link kërkon një rrugë të lidhur tjetër, dhe një tabelë e ndërtuar nga prefiksi i gabuar dështon në hapin e parë. Atributi src tregon burimin e preferuar për atë rrugë; ai nuk e zëvendëson rregullin e burimit.

Rendi ka rëndësi gjithashtu. Një rregull i gjerë me numër prioriteti më të ulët vlerësohet i pari, prandaj rregulli i burimit duhet të arrihet para çdo rregulli që do ta kthente këtë trafik në tabelën kryesore. Kontrolloni prioritetet me ip rule show pas shtimit, jo vetëm në nisje.

Verifikoni me një kërkim të kualifikuar sipas burimit

Kërkojini kernel-it të drejtojë një destinacion testi nga adresa e shërbimit. Përgjigja duhet të përmendë eth0 dhe portën WAN, jo tunelin:

ip -4 route get 198.51.100.25 from 192.0.2.10

Pastaj krijoni një lidhje të re të autorizuar dhe vëzhgoni të dy drejtimet. Një kërkim që zgjedh tabelën e saktë ndërsa lidhja e drejtpërdrejtë ende dështon tregon filtrimin e rrugës së kundërt ose një rregull firewall, jo tabelën. Kontrolloni ato kontrolle përpara se të çaktivizoni diçka globalisht.

Vendosni rrugët përfundimtare dhe rregullin nën menaxherin e rrjetit që zotëron ndërfaqen. Ndryshimet e adresës, rinovimi i DHCP dhe rilidhjet e VPN rishkruajnë të gjithë gjendjen e kernel-it, dhe një rregull i shtuar me dorë zhduket ose tregon një portë të vjetruar pas ngjarjes së radhës.

Ku ndalon ky përjashtim

Rregulli përjashton trafikun e përfunduar lokalisht nga një adresë burimi. Ai nuk mbulon portat e publikuara nga Docker, DNAT ose shërbimet e përçuar përmes host-it, sepse ato paketa drejtohen si trafik i përçuar dhe nuk e mbajnë kurrë burimin lokal të host-it në të njëjtën mënyrë. Dizajne të tilla zakonisht kërkojnë një shenjë të vendosur në hyrje dhe një rregull që përputhet me shenjën.

As nuk e bën adresën publike të host-it të shfaqet në ndërfaqe. Kur një NAT i sipërm e zotëron atë adresë, përgjigja duhet të dalë ende në rrugën që pret ai NAT, dhe për këtë arsye tabela WAN duhet të pasqyrojë portën dhe prefiksin origjinal, jo një interval publik të hamendësuar.

Mbani përjashtimin të dokumentuar me numrin e tabelës, prioritetin e rregullit dhe adresën e saktë të burimit. Ndryshimi i ardhshëm në VPN ose në ndërfaqe mund ta thyejë në heshtje, dhe një shënim që përmend tre vlerat kontrollohet më shpejt sesa rizbulimi i simptomës nga një raport klienti.

Nëse shërbimi ende përgjigjet në rrugën e gabuar pasi kërkimi i kualifikuar sipas burimit ka kaluar, krahasoni adresën e burimit të socket-it aktiv me atë në rregull. Një shërbim i lidhur me një adresë të përgjithshme mund të zgjedhë një burim të ndryshëm nga adresa që keni testuar, dhe ai mospërputhje është boshllëku i mbetur.