Loka apo, VPN-regulo: kial via FORWARD-ĉeno neniam ekfunkcias

Vi aldonas regulon por VPN-trafiko en la ĉeno FORWARD, lanĉas la peton el la sama Linux-maŝino, kaj la nombrilo restas nulo. La regulo verŝajne estas ĝusta. La pakaĵo neniam iris tiun vojon, ĉar peto generita sur la maŝino mem ne estas plusendata de ĝi. Spuri la vivon de la pakaĵo de la ingo ĝis la drato klarigas kial, kaj kie la regulo anstataŭe apartenas.

Trovu, kie la pakaĵo naskiĝis

La hoka ordo de Netfilter apartigas tri kazojn, kaj nur unu el ili koncernas FORWARD:

Loka aplikaĵo komenciĝas en la vojo OUTPUT, ĉar la kerno jam konstatis, ke la pakaĵo originas ĉi tie kaj neniam estas kandidato por plusendado. Krei tunelon ne ŝanĝas tiun klasifikon; la tunelo estas aparato, tra kiu la pakaĵo povas eliri, ne stadio, kiu transformas lokan eligon en trairon.

Du pakaĵoj, unu historio

Post kiam la tunelo funkcias, la interna pakaĵo de la aplikaĵo kaj la ĉifrita ekstera pakaĵo estas malsamaj objektoj. La interna pakaĵo portas la celon kaj ŝarĝon, kiujn elektis la aplikaĵo. La ekstera pakaĵo portas ĉifrotekston al la adreso kaj pordo de la partnero, kaj ĝi estas tio, kio fakte transiras la fizikan interfacon.

Via politiko koncernas unu el ili, kaj elekti la malĝustan estas ofta kaŭzo, ke regulo ŝajnas fari nenion. Regulo kongruanta kun la ekstera adreso de la partnero vidas ĉiun tunelan pakaĵon egale, kion ajn faras la aplikaĵo interne. Regulo kongruanta kun interna celo vidas la trafikon, kiu gravas al vi, kaj ĝi ekfunkcios nur se tiu pakaĵo atingos la hokon, sur kiu vi instalas la regulon.

Nomspacoj movas la limon

Kontenero malfaciligas tion sen ŝanĝi la principon. La peto de la aplikaĵo estas loka eligo interne de la reta nomspaco de la kontenero. La gastiganto ricevas tiun trafikon sur virtuala Ethernet-interfaco kaj povas plusendi ĝin, do FORWARD-regulo sur la gastiganto povas havi sencon, kvankam la procezo, kiu generis la peton, neniam tuŝis la ĉenon OUTPUT de la gastiganto.

Antaŭ ol elekti hokon, konstatu, kie la reguloaro kaj la tunelo fakte loĝas. Tunelo interne de la kontenero, tunelo sur la gastiganto kun la kontenero enkursigita tra ĝi, kaj tunelo en aparta nomspaco estas tri malsamaj topologioj kun tri malsamaj regulaj lokoj. Legu la regulojn interne de la nomspaco, kiu posedas la aparaton, ne nur en la implicita.

Demandu, ĉu vi entute bezonas markon

Se la celo estas sendi unu celan prefikson tra la tunelo, vojo por tiu prefikso eble sufiĉas. Kontrolu unue la efektivajn vojojn, inkluzive de ĉio, kion la servilo puŝis: redirektita implicita vojo sendas multe pli da trafiko tra la VPN ol la mallarĝa politiko, kiun vi imagis, kaj neniu kvanto da markado igos la rezulton kongrui kun la intenco.

Klasifikado necesas, kiam la decido dependas de io, kion vojo ne povas esprimi, ekzemple la fonto, la uzanto aŭ la procezo. Por ricevita trafiko, markado en PREROUTING funkcias. Por loka trafiko, la markado devas okazi en eliga stadio, kiu povas ekigi novan vojserĉon post kiam la marko estas metita. Ĉe nftables tio estas ĉeno de tipo route sur la eliga hoko; ordinara eliga filtra ĉeno metos la valoron kaj lasos la vojon senŝanĝa.

Ĉe iptables, la ekvivalento loĝas en la mangle OUTPUT-aranĝo, kaj la sama postulo validas: la enkursiga decido devas esti reviziita post kiam la marko ekzistas. Poste politika regulo devas konsumi la markon kaj montri al tabelo enhavanta uzeblan vojon. Meti conntrack-markon estas tria, aparta operacio; ĝi konservas valoron sur la fluo kaj ne metas per si mem tiun valoron sur la nunan pakaĵon, por ke enkursigado legu ĝin.

Kontrolu la serĉon kaj la nombrilon kune

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

La adreso kaj la marko estas ilustraj, kaj la du vojpetoj respondas malsamajn demandojn. La dua demandas, kion la kerno farus se pakaĵo portus tiun markon; ĝi ne montras, ke via reguloaro asignas unu. Traktu ĝin kiel hipotezan teston, ne kiel pruvon, ke la politiko funkcias.

Poste lanĉu sendanĝeran peton kaj observu du aferojn samtempe: la nombrilon sur la hoko, kiun vi elektis, kaj la eliron, kiun la pakaĵo fakte prenis. Se la nombrilo moviĝas kaj la pakaĵo eliras aliloke, la marko aŭ la tabelo estas malĝusta. Se neniu el ili moviĝas, la pakaĵo tute ne atingas tiun hokon, kaj la sekva demando estas la nomspaco aŭ la vojo.

Fine, limigu la teston al tio, kion la mekanismo povas esprimi. Unu vojo por unu adreso ne fariĝas permanenta politiko por servo, kies adresoj rotacias. Decidu unue la amplekson de la pakaĵoj, poste kontrolu, ĉu la enkursiga kaj markada dezajno povas teni tiun amplekson post rekonekto.