Pse një klient VPN në LAN-in e zyrës humb çdo përgjigje

Një laptop qëndron në /24 e zyrës përmes Ethernet dhe gjithashtu bashkohet me një server OpenVPN që jeton në të njëjtën /24. Një koleg bën ping në adresën e tunelit; kërkesa mbërrin qartë, dhe asgjë nuk kthehet. Regjistri i tunelit është i pastër dhe shfletimi vazhdon të punojë, prandaj tuneli është i dyshuari i gabuar. Validimi i burimit IPv4 në makinën që pranon e hedh paketën para se diçka ta lexojë.

Hedhja ndodh para se diçka ta lexojë paketën

Validimi i burimit bën një pyetje për çdo paketë hyrëse: nëse ky host do t'i përgjigjej atij burimi, a do të dilte përgjigja përmes ndërfaqes nga e cila paketa sapo mbërriti? Kur përgjigja është jo, kernel-i e hedh paketën në mbërritje. Asnjë socket dhe asnjë rrugë përcjelljeje nuk e sheh ndonjëherë, prandaj një kapje në tunel regjistron ende një kërkesë që aplikacioni nuk e merr kurrë.

Klienti këtu mban 10.66.0.9 në tunelin e tij, dhe serveri OpenVPN përgjigjet në 192.168.80.10 brenda prefiksit të zyrës. Një koleg në 192.168.80.25 bën ping në adresën e tunelit, kështu që kërkesa kalon LAN-in, serveri e drejton në tunel, dhe ajo mbërrin në ndërfaqen e tunelit të klientit duke mbajtur një adresë burimi të zyrës. Në tabelën e rrugëzimit të asaj makine prefiksi i zyrës u përket pajisjes Ethernet, jo tunelit. Validimi krahason ndërfaqen e mbërritjes me rrugën, gjen një mospërputhje dhe e hedh paketën, kështu që kolegu sheh humbje totale ndërsa të dy skajet raportojnë një tunel të shëndoshë.

Drejtimi pasqyrë ka të njëjtën formë: kur klienti nis drejt zyrës, përgjigjet mund të hidhen në anën e zyrës për të njëjtën arsye. Një rregullim i verifikuar vetëm në një drejtim zakonisht kthehet si një biletë e dytë.

Provoni regjimin në fuqi përpara se të prekni ndonjë sysctl

Lexoni vlerat efektive në vend që të besoni një parazgjedhje të shpërndarjes, sepse cilësimi për ndërfaqe është vetëm gjysma e vendimit. Regjimi në fuqi është më i larti midis vlerës së ndërfaqes dhe vlerës së all, prandaj një zero në ndërfaqen e tunelit nuk do të thotë asgjë sa kohë all është një. Vendimi i regjimit të rreptë është një vendim rrugëzimi, prandaj ekzekutoni kërkimin që ekzekuton kernel-i dhe krahasoni përgjigjen me ndërfaqen nga e cila paketa ka mbërritur vërtet.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Më pas përsëritni ping-un duke vëzhguar numëruesin e gabimeve. Një numër që rritet pranë një kërkese që kapja e tregon tashmë është firmë e kësaj hedhjeje, jo e një rruge që mungon. Aktivizoni regjistrimin e paketave marsiane ndërsa jeni atje, që kernel-i të emërojë burimin dhe ndërfaqen që refuzoi. Së bashku përjashtojnë shifrën, murin e zjarrit dhe një iroute që mungon si shpjegime.

Shkruani vijën bazë para se të ndryshoni çdo gjë: të dyja vlerat, pajisjen që zgjodhi kërkimi, dhe numëruesin që vëzhguat. Është pikërisht ai regjistrim që ju tregon më vonë nëse ndryshimi bëri atë që mendoni.

Çfarë pranon në të vërtetë secili regjim i rp_filter

Kernel-i ekspozon tre vlera për ndërfaqe, dhe nuk janë tre nuanca të një rregulli. Zero e çaktivizon kontrollin. Një është i rreptë dhe kërkon që burimi të rrugëzohet përsëri përmes ndërfaqes së mbërritjes. Dy është i lirshëm dhe kërkon vetëm që të ekzistojë ndonjë rrugë drejt burimit në tabelë, kudo që të tregojë.

Rreshti që ka rëndësi këtu është ai i lirshëm, dhe ajo që vazhdon të refuzojë. Një burim i falsifikuar që rrugëzohet kudo në tabelën tuaj kalon, ndërsa një burim pa asnjë rrugë refuzohet ende. Në laptop është një lëshim i ngushtë; në router-in që përcjell trafikun e njerëzve të tjerë është i gjerë. Regjimi i përket hostit, prandaj i njëjti numër mban peshë të ndryshme në dy vendet.

Cili rresht i nevojitet kësaj topologjie rrjedh nga tabela dhe jo nga zakoni. Paketa është legitime dhe burimi i saj rrugëzohet, prandaj ai i lirshëm e pranon dhe ai i rreptë jo. Asgjë në këtë rast nuk kërkon zero, dhe zgjedhja e zeros do të hiqte një kontroll që këtu nuk kushton asgjë.

Zgjidhni ndryshimin më të vogël që heq paqartësinë

Regjimi i lirshëm është ndryshimi më i vogël që përshtatet, dhe është një ulje e vërtetë e rreptësisë, jo një çelës i padëmshëm. Një mundësi më e mirë ekziston sa herë topologjia e lejon: hiqni mbivendosjen, dhe paqartësia zhduket.

Aty ku prefiksi i zyrës nevojitet vetëm përmes Ethernet, hiqeni nga rrugët që tërheq profili, dhe adresa bëhet e arritshme me një rrugë të vetme. Kur të dyja rrugët duhet vërtet të bashkëjetojnë, fiksoni burimin dhe pajisjen me një rregull politike në vend që të lëshoni validimin në çdo ndërfaqe. Kjo ruan filtrim të rreptë për gjithçka tjetër në makinë dhe dokumenton përjashtimin atje ku inxhinieri i radhës do ta kërkojë.

Çfarëdo rruge të zgjidhni, regjistrojeni në një drop-in sysctl dhe jo në një komandë të gjallë. Vendosni çelësat all dhe default së bashku, që një rilidhje të mos mund ta kthejë në heshtje regjimin e rreptë.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Çfarë lëshon regjimi i lirshëm, dhe ku

Regjimi i lirshëm refuzon ende një burim që asnjë rrugë nuk do ta arrinte, dhe ndalon së refuzuari një burim të falsifikuar që ndodh të jetë i rrugëzueshëm. Në laptop është një lëshim i ngushtë. Në një pajisje që përcjell trafik që nuk e zotëron, i njëjti zgjedhje është shumë më i gjerë. Prandaj i njëjti cilësim mban dy kuptime shumë të ndryshme në varësi të vendit ku ekzekutohet.

Fikja e plotë e kontrollit në një host që përcjell trafik për njerëzit e tjerë është e vetmja rregullim që duhet shmangur. Zero e hedh validimin që regjimi i lirshëm e ruan me kujdes. Nëse hosti përcjell për të tjerët, argumentoni në vend të kësaj për mundësinë e rregullit politik të seksionit të mëparshëm.

Lini një shënim që emëron të dy ndërfaqet, prefiksin që mbivendoset dhe provën e saktë që tani ka sukses. Kjo është më e dobishme për inxhinierin e radhës sesa një rresht që thotë se filtrimi u rregullua.