Kërkesa është gjithmonë një variant i së njëjtës fjali: mbaje VPN-në për shfletim, por lëre SSH-në ose një punë rezervë të përdorë lidhjen normale. Këshilla që qarkullon për këtë, të përcjellësh portin me rregulla NAT në iptables, nuk e bën këtë. Një rregull NAT rishkruan adresat dhe portet brenda një rrjedhe; nuk zgjedh kurrë ndërfaqen nga e cila del paketa. Ai vendim i takon kërkimit të rrugës, dhe kërkimi i rrugës ka nevojë për ndihmë që të shohë një port.

Pse një rrugë e thjeshtë nuk mund të përputhet me një port

Linux zgjedh një rrugë duke kërkuar adresën e destinacionit në një tabelë, pasi tabelat kandidate filtrohen nga rregullat e politikës. Këto rregulla mund të përputhen me një shenjë firewall-i, një adresë burimi, një ndërfaqe hyrëse ose një UID. Vetë zëri i rrugës nuk ka fushë porti, sepse rruga zgjidhet përpara se koka e transportit të ketë rëndësi.

iproute2 dhe kernelët e sotëm zgjerojnë zgjedhësin e rregullave: ipproto, sport dhe dport pranohen, prandaj ip rule add ipproto tcp dport 22 table 100 e shpreh qëllimin në një rresht. Ekzekuto ip rule add help në hostin e vërtetë për të parë nëse ndërtimi yt liston dport. Nëse e bën, ke mbaruar me një komandë; nëse jo, rruga me shenjë më poshtë është ekuivalentja.

Në çdo rast rregulli është vetëm një tregues. Tabela 100 ende ka nevojë për një rrugë, dhe kjo është pjesa që njerëzit e harrojnë.

Tri pjesë, ose një

Forma moderne është rregulli i vetëm më sipër plus një rrugë në tabelën alternative. Forma klasike shton netfilter në mes: shëno paketën, pastaj përputh shenjën në një rregull. Të dyja përfundojnë në të njëjtin kërkim; ndryshojnë në vendin ku lexohet porti.

Qasja me shenjë ekziston sepse netfilter e sheh kokën e transportit dhe kodi i rrugëzimit historikisht nuk e shihte. Ky është i gjithë mekanizmi, dhe shpjegon pse rruga rezervë është tri pjesë që bashkëpunojnë, jo një komandë e zgjuar.

Tri pjesët sipas radhës

Së pari, shëno rrjedhat që dëshiron të devijosh, në një zinxhir që ekzekutohet mjaft herët që shenja të ekzistojë përpara vendimit të rrugës:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

Së dyti, dërgo paketat e shënuara në një tabelë të veçantë:

ip rule add fwmark 0x1/0x1 table 100

Së treti, jepi asaj tabele një rrugë të paracaktuar përmes lidhjes fizike. Adresat janë ilustruese; zëvendësoji me të tuat:

ip route add default via 192.168.1.1 dev wlan0 table 100

Kalo hapin e tretë dhe paketa e shënuar nuk gjen rrugë në tabelën 100, prandaj dështon. Simptoma duket sikur rregulli prishi rrjetin, kur në fakt hoqi të vetmen rrugë që i kishte mbetur paketës.

Çfarë e mban në punë pas paketës së parë

Shenjat zbatohen për paketat dalëse. Përgjigja mbërrin në ndërfaqen fizike me adresën që caktoi lidhja, dhe tabela kryesore mund të preferojë ende tunelin për atë destinacion. Dy mekanizma e mbajnë rrugën e përgjigjes të qëndrueshme: një rregull i bazuar në burim për adresën e lidhjes, dhe connection tracking që e ruan vendimin gjatë gjithë jetës së rrjedhës. Ruajtja e shenjës në conntrack dhe rikthimi i saj në përgjigje është mënyra e zakonshme për ta bërë të qëndrueshme një përjashtim me gjendje.

Filtrimi i rrugës së kthimit është vrasësi tjetër i heshtur. Nëse kerneli e vërteton rreptësisht rrugën e kthimit dhe përgjigja mbërrin në një ndërfaqe që tabela kryesore nuk do ta zgjidhte, paketa hidhet pa mesazh. rp_filter vlerat e paracaktuara ndryshojnë sipas shpërndarjes dhe sipas faktit nëse ndërfaqja përcillet, prandaj lexo vlerën efektive në vend që të supozosh se është e fikur.

Mos e shëno transportin e vetë tunelit. Një tunel WireGuard ose UDP OpenVPN nuk është TCP 22, prandaj receta më sipër është e sigurt, por një përjashtim i shkruar si gjithçka përveç destinacionit të tunelit mund të kapë paketat e kriptuara dhe ta prishë tunelin në një mënyrë që duket si lak rrugëzimi.

Verifikoje në vend që të supozosh

Pyet kernelin cilën rrugë do të merrte, për destinacionin dhe për portin, pastaj kryej transferimin e vërtetë:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Nëse shenja ekziston por numëruesit nuk lëvizin kurrë, rregulli nuk përputhet. Numëruesit janë dallimi midis një konfigurimi që e shkrove dhe një politike që kerneli e zbaton.

Kur ky është mjeti i gabuar

Përjashtimet e bazuara në port janë nga natyra të brishta. Shërbimet i zhvendosin portet, HTTP/3 vjen si UDP 443, dhe një aplikacion mund të hapë disa rrjedha të llojeve të ndryshme. Nëse kërkesa e vërtetë është që ky program të përdorë lidhjen normale, shtresa e rrugëzimit është vendi i gabuar; një hapësirë emrash rrjeti ose një proxy për aplikacion përshtatet më mirë.

Nëse kërkesa është që kjo nënrrjet të përdorë lidhjen normale, anashkaloji plotësisht shenjat dhe shto një rrugë më specifike. Është më e thjeshtë, është e dukshme në një tabelë, dhe personi tjetër mund ta auditojë pa lexuar një grup rregullash.

Shkruaj cilën nga tri kërkesat e ke vërtet përpara se të prekësh firewall-in. Mekanizmi më sipër është i saktë, dhe saktësia e zbatuar në shtresën e gabuar është thjesht një ndërprerje më e gjatë.

Artikuj të ngjashëm