La peto ĉiam estas variaĵo de la sama frazo: konservu la VPN por retumi, sed lasu SSH aŭ sekurkopion uzi la normalan konekton. La konsilo cirkulanta pri tio, plusendi la pordon per iptables NAT-reguloj, ne faras tion. NAT-regulo reverkas adresojn kaj pordojn ene de fluo; ĝi neniam elektas, per kiu interfaco la paketo eliras. Tiu decido apartenas al la vojiga serĉo, kaj la vojiga serĉo bezonas helpon por vidi pordon.

Kial ordinara vojo ne povas kongrui kun pordo

Linux elektas vojon serĉante la celan adreson en tabelo, post kiam kandidataj tabeloj estas filtritaj per politikaj reguloj. Tiuj reguloj povas kongrui kun fajrmura marko, fonta adreso, envenanta interfaco aŭ UID. La voja enskribo mem havas neniun pordan kampon, ĉar la vojo elektiĝas antaŭ ol la transporta kaplinio gravas.

Nunaj iproute2 kaj kernoj larĝigas la elekton de la regulo: ipproto, sport kaj dport estas akceptataj, do ip rule add ipproto tcp dport 22 table 100 esprimas la intencon en unu linio. Rulu ip rule add help sur la reala gastiganto por vidi ĉu via konstruaĵo listigas dport. Se jes, vi finis per unu komando; se ne, la marka vojo sube estas la ekvivalento.

Ĉiel ajn, la regulo estas nur montrilo. Tabelo 100 ankoraŭ bezonas vojon, kaj tion homoj forgesas.

Tri pecoj, aŭ unu

La moderna formo estas la unuopa regulo supre plus vojo en la alternativa tabelo. La klasika formo aldonas netfilter meze: marku la paketon, poste kongruigu la markon en regulo. Ambaŭ finiĝas ĉe la sama serĉo; ili diferencas en tio, kie la pordo legiĝas.

La marka aliro ekzistas ĉar netfilter vidas la transportan kaplininon kaj la vojiga kodo historie ne vidis ĝin. Tio estas la tuta mekanismo, kaj ĝi klarigas kial la rezerva vojo estas tri kunlaborantaj pecoj anstataŭ unu lerta komando.

La tri pecoj laŭorde

Unue, marku la fluojn, kiujn vi volas deturni, en ĉeno, kiu kuras sufiĉe frue por ke la marko ekzistu antaŭ la voja decido:

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

Due, sendu markitajn paketojn al aparta tabelo:

ip rule add fwmark 0x1/0x1 table 100

Trie, donu al tiu tabelo defaŭltan vojon tra la fizika ligilo. La adresoj estas ilustraj; anstataŭigu ilin per viaj:

ip route add default via 192.168.1.1 dev wlan0 table 100

Saltu la trian paŝon kaj la markita paketo trovas neniun vojon en tabelo 100, do ĝi malsukcesas. La simptomo aspektas kvazaŭ la regulo rompis la reton, dum ĝi fakte forigis la solan vojon, kiun la paketo ankoraŭ havis.

Kio tenas ĝin funkcianta post la unua paketo

Markoj validas por elirantaj paketoj. La respondo alvenas sur la fizika interfaco kun la adreso, kiun tiu ligilo asignis, kaj la ĉefa tabelo eble ankoraŭ preferas la tunelon por tiu celo. Du mekanismoj tenas la respondan vojon konsekvenca: regulo bazita sur fonto por la ligila adreso, kaj konekta spurado, kiu konservas la decidon dum la tuta vivo de la fluo. Konservi la markon en conntrack kaj restarigi ĝin ĉe la respondo estas la kutima maniero stabiligi stataescepton.

Filtrado de la inversa vojo estas la alia silenta mortiganto. Se la kerno strikte validigas la revenan vojon kaj la respondo alvenas sur interfaco, kiun la ĉefa tabelo ne elektus, la paketo estas forĵetata sen mesaĝo. rp_filter defaŭltoj varias laŭ distribuo kaj laŭ tio, ĉu la interfaco estas plusendata, do legu la efektivan valoron anstataŭ supozi, ke ĝi estas malŝaltita.

Ne marku la propran transporton de la tunelo. WireGuard aŭ UDP OpenVPN-tunelo ne estas TCP 22, do la recepto supre estas sekura, sed escepto skribita kiel ĉio krom la tunela celo povas kapti la ĉifritajn paketojn kaj rompi la tunelon tiel, ke ĝi aspektas kiel vojiga buklo.

Kontrolu ĝin anstataŭ supozi

Demandu la kernon, kiun vojon ĝi prenus, por la celo kaj por la pordo, poste rulu la realan transigon:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Se la marko ekzistas sed la nombriloj neniam moviĝas, la regulo ne kongruas. Nombriloj estas la diferenco inter agordo, kiun vi skribis, kaj politiko, kiun la kerno aplikas.

Kiam ĉi tio estas la malĝusta ilo

Pordbazitaj esceptoj estas delikataj laŭ naturo. Servoj movas pordojn, HTTP/3 venas kiel UDP 443, kaj unu aplikaĵo povas malfermi plurajn fluojn de diversaj specoj. Se la vera postulo estas, ke ĉi tiu programo uzu la normalan ligilon, la vojiga tavolo estas la malĝusta loko; reta nomspaco aŭ prokurilo por ĉiu aplikaĵo pli taŭgas.

Se la postulo estas, ke ĉi tiu subreto uzu la normalan ligilon, tute preterlasu la markojn kaj aldonu pli specifan vojon. Ĝi estas pli simpla, videbla en unu tabelo, kaj la sekva persono povas kontroli ĝin sen legi regularon.

Notu, kiun el la tri postuloj vi vere havas, antaŭ ol tuŝi la fajrmuron. La mekanismo supre estas preciza, kaj precizeco aplikata al la malĝusta tavolo estas nur pli longa interrompo.

Rilataj artikoloj