Päring on alati sama lause variant: jäta VPN sirvimiseks alles, aga lase SSH-l või varundustööl kasutada tavalist ühendust. Selle kohta ringlev nõuanne, porti iptables NAT-reeglitega edasi suunata, ei tee seda. NAT-reegel kirjutab ümber aadresse ja porte voo sees; see ei vali kunagi, millise liidese kaudu pakett väljub. See otsus kuulub marsruudiotsingu juurde ja marsruudiotsing vajab abi, et porti näha.

Miks tavaline marsruut ei saa pordiga sobida

Linux valib marsruudi, otsides sihtaadressi tabelist, pärast seda kui kandidaattabelid on poliitikareeglitega filtreeritud. Need reeglid võivad sobida tulemüüri märgise, lähteaadressi, sissetuleva liidese või UID-iga. Marsruudikirjel endal pordivälja pole, sest marsruut valitakse enne, kui transpordi päis loeb.

Praegused iproute2 ja tuumad laiendavad reegli valijat: ipproto, sport ja dport võetakse vastu, seega ip rule add ipproto tcp dport 22 table 100 väljendab kavatsust ühes reas. Käivitage ip rule add help päris hostis, et näha, kas teie ehitis loetleb dport. Kui loetleb, olete ühe käsuga valmis; kui ei, on allolev märgise tee samaväärne.

Igal juhul on reegel ainult osuti. Tabel 100 vajab ikka marsruuti ja just selle osa inimesed unustavad.

Kolm tükki või üks

Nüüdisaegne vorm on üksik reegel ülal pluss marsruut alternatiivses tabelis. Klassikaline vorm lisab keskele netfilteri: märgista pakett, seejärel sobitage märgis reeglis. Mõlemad lõpevad sama otsinguga; erinevus on selles, kust porti loetakse.

Märgise lähenemine on olemas, sest netfilter näeb transpordi päist ja marsruutimiskood ajalooliselt ei näinud. See on kogu mehhanism ja see selgitab, miks varuvariant on kolm koostöötavat tükki, mitte üks nutikas käsk.

Kolm tükki järjekorras

Esiteks märgistage voog, mille tahate kõrvale juhtida, ahelas, mis jookseb piisavalt vara, et märgis oleks olemas enne marsruudiotsust:

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

Teiseks saatke märgistatud paketid eraldi tabelisse:

ip rule add fwmark 0x1/0x1 table 100

Kolmandaks andke sellele tabelile vaikimisi marsruut füüsilise lingi kaudu. Aadressid on näitlikud; asendage need enda omadega:

ip route add default via 192.168.1.1 dev wlan0 table 100

Jätke kolmas samm vahele ja märgistatud pakett ei leia tabelist 100 marsruuti, seega see ebaõnnestub. Sümptom näeb välja, nagu oleks reegel võrgu katki teinud, kuigi tegelikult eemaldas see ainsa tee, mis paketil veel alles oli.

Mis hoiab seda töös pärast esimest paketti

Märgised kehtivad väljuvate pakettide kohta. Vastus saabub füüsilisele liidesele aadressiga, mille see link määras, ja põhitabel võib selle sihtkoha jaoks ikka tunnelit eelistada. Kaks mehhanismi hoiavad vastusetee järjekindlana: allikal põhinev reegel lingi aadressi jaoks ja ühenduste jälgimine, mis säilitab otsuse kogu voo eluea jooksul. Märgise salvestamine conntracki ja selle taastamine vastusel on tavaline viis muuta olekupõhine erand stabiilseks.

Tagasitee filtreerimine on teine vaikne tapja. Kui tuum valideerib tagasitee rangelt ja vastus saabub liidesele, mida põhitabel ei valiks, visatakse pakett ilma teatest kõrvale. rp_filter vaikeväärtused erinevad distributsiooni ja selle järgi, kas liidest edastatakse, seega lugege tegelikku väärtust, selle asemel et eeldada, et see on väljas.

Ärge märgistage tunneli enda transporti. WireGuard või UDP OpenVPN tunnel ei ole TCP 22, seega ülalolev retsept on ohutu, kuid erand, mis on kirjutatud kui kõik peale tunneli sihtkoha, võib krüpteeritud paketid kinni püüda ja tunneli katki teha viisil, mis näeb välja nagu marsruutimissilmus.

Kontrollige, mitte ärge eeldage

Küsige tuumalt, millist teed see valiks, sihtkoha ja pordi jaoks, seejärel käivitage tegelik ülekanne:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Kui märgis on olemas, aga loendurid ei liigu kunagi, siis reegel ei sobi. Loendurid on vahe teie kirjutatud konfiguratsiooni ja tuuma rakendatava poliitika vahel.

Millal on see vale tööriist

Pordipõhised erandid on olemuselt haprad. Teenused liigutavad porte, HTTP/3 saabub UDP 443-na ja üks rakendus võib avada mitme eri liiki voogu. Kui tegelik nõue on, et see programm kasutaks tavalist linki, on marsruutimiskiht vale koht; võrgu nimeruum või rakendusepõhine puhverserver sobib paremini.

Kui nõue on, et see alamvõrk kasutaks tavalist linki, jätke märgised täiesti vahele ja lisage täpsem marsruut. See on lihtsam, ühes tabelis nähtav ja järgmine inimene saab seda auditeerida ilma reeglistikku lugemata.

Pange kirja, milline neist kolmest nõudest teil tegelikult on, enne kui tulemüüri puudutate. Ülalolev mehhanism on täpne ja valele kihile rakendatud täpsus on lihtsalt pikem katkestus.

Seotud artiklid