Ien poarte bûten de VPN hâlde freget beliedsrouting

It fersyk is altyd in fariant fan deselde sin: hâld de VPN foar it browsen, mar lit SSH of in backuptaak de normale ferbining brûke. It advys dat hjir oer rûn giet, de poarte trochstjoere mei iptables NAT-regels, docht dat net. In NAT-regel skriuwt adressen en poarten binnen in stream om; hy kiest nea hokker ynterface it pakket ferlit. Dy beslissing heart by it rûtesykjen, en it rûtesykjen hat help nedich om in poarte te sjen.

Wêrom't in gewoane rûte net mei in poarte oerienkomme kin

Linux kiest in rûte troch it bestimmingsadres yn in tabel op te sykjen, nei't kandidate-tabellen troch beliedsregels filtere binne. Dy regels kinne oerienkomme mei in firewallmark, in boarneadres, in ynkommende ynterface of in UID. De rûte-yngong sels hat gjin poartefjild, om't de rûte keazen wurdt foardat de transportkop der ta docht.

Hjoeddeistige iproute2 en kearnen ferbreedzje de regelkar: ipproto, sport en dport wurde akseptearre, dus ip rule add ipproto tcp dport 22 table 100 sprekt de bedoeling yn ien rigel út. Fier ip rule add help út op de echte host om te sjen oft dyn build dport listet. Docht er dat, dan bist klear mei ien opdracht; docht er dat net, dan is it markpaad hjirûnder it ekwivalint.

Hoe dan ek, de regel is mar in wizer. Tabel 100 hat noch altyd in rûte nedich, en dat is it stik dat minsken ferjitte.

Trije stikken, of ien

De moderne foarm is de iene regel hjirboppe plus in rûte yn 'e alternative tabel. De klassike foarm foeget netfilter yn 'e midden ta: markearje it pakket, en lit de mark dan yn in regel oerienkomme. Beide einigje by itselde sykjen; se ferskille yn wêr't de poarte lêzen wurdt.

De markoogje bestiet om't netfilter de transportkop sjocht en de rûtekoada histoarysk net. Dat is it hiele meganisme, en it ferklearret wêrom't de fallback trije gearwurkjende stikken binne yn plak fan ien tûke opdracht.

De trije stikken yn oarder

Earst markearje de streamen dy'tst omwolst, yn in keatling dy't ier genôch rint om it mark te hawwen foardat de rûtebeslissing falt:

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

Twad, stjoer markearre pakketten nei in aparte tabel:

ip rule add fwmark 0x1/0x1 table 100

Tred, jou dy tabel in standertrûte fia de fysike keppeling. De adressen binne foarbylden; ferfang se troch dyn eigen:

ip route add default via 192.168.1.1 dev wlan0 table 100

Sla do tredde stap oer en it markearre pakket fynt gjin rûte yn tabel 100, dus it mislearret. It symptoom liket as hat de regel it netwurk brutsen, wylst er eins it iennige paad fuorthelle dat it pakket noch hie.

Wat it nei it earste pakket oan 'e gong hâldt

Marken jilde foar útgeande pakketten. It antwurd komt op 'e fysike ynterface binnen mei it adres dat dy keppeling tawiisd hat, en de haadtabel kin foar dy bestimming noch altyd de tunnel ferkieze. Twa meganismen hâlde it antwurdpaad konsekwint: in regel basearre op boarne foar it keppelingadres, en ferbiningstracking dat de beslissing foar de hiele libbensdoer fan 'e stream bewarret. It mark yn conntrack bewarje en by it antwurd weromsette is de gewoane manier om in steatseksje stabyl te meitsjen.

Filtering fan 'e omkearde paad is de oare stille moardner. As de kearn it werompaad strang falidearret en it antwurd komt binnen op in ynterface dat de haadtabel net kieze soe, dan wurdt it pakket sûnder berjocht weilitten. rp_filter standertwearden ferskille per distribúsje en per oft de ynterface trochjûn wurdt, dat lês de effektive wearde yn plak fan oan te nimmen dat er út stiet.

Markearje net it eigen transport fan 'e tunnel. In WireGuard- of UDP OpenVPN-tunnel is gjin TCP 22, dus it resept hjirboppe is feilich, mar in útsûndering skreaun as alles behalve de tunnelbestimming kin de fersifere pakketten fange en de tunnel brekke op in manier dy't as in rûtelus liese.

Kontrolearje it yn plak fan oan te nimmen

Freegje de kearn hokker paad er nimme soe, foar de bestimming en foar de poarte, en fier dan de echte oerdracht út:

ip route get 203.0.113.10
ip rule show
nft list ruleset

As it mark bestiet mar de tellers bewege nea, dan komt de regel net oerien. Tellers binne it ferskil tusken in konfiguraasje dy'tsto skreaun hast en in belied dat de kearn tapast.

Wannear't dit it ferkearde helpmiddel is

Poartebasearre útsûnderingen binne fan natuere brekber. Tsjinsten ferpleatse poarten, HTTP/3 komt as UDP 443, en ien applikaasje kin ferskate streamen fan ferskillende soarten iepenje. As de echte eask is dat dit programma de normale keppeling brûkt, dan is de rûtelaach it ferkearde plak; in netwurknammeromte of in proxy per applikaasje past better.

As de eask is dat dit subnet de normale keppeling brûkt, sla de marken dan hielendal oer en foegje in mear spesifike rûte ta. It is ienfâldiger, it is yn ien tabel sichtber, en de folgjende persoan kin it auditearje sûnder in regelset te lêzen.

Skriuw op hokker fan 'e trije easken do eins hast, foardatst de firewall oanrekket. It meganisme hjirboppe is krekt, en krektens tapast op 'e ferkearde laach is gewoan in langer útfal.