Aplicació local, regla VPN: per què la teva cadena FORWARD no s’activa mai

Afegiu una regla per al trànsit VPN a la cadena FORWARD, executeu la petició des de la mateixa màquina Linux i el comptador es queda a zero. La regla és probablement correcta. El paquet no va agafar mai aquest camí, perquè una petició generada a la mateixa màquina no la reenvia ella mateixa. Recórrer la vida del paquet des del socket fins al cable explica per què, i on hauria d’anar la regla.

Trobeu on va néixer el paquet

L’ordre dels hooks de Netfilter separa tres casos, i només un d’ells implica FORWARD:

Una aplicació local comença al camí OUTPUT, perquè el nucli ja ha establert que el paquet s’origina aquí i mai no és candidat a ser reenviat. Crear un túnel no canvia aquesta classificació; el túnel és un dispositiu pel qual el paquet pot sortir, no una etapa que converteixi la sortida local en trànsit.

Dos paquets, una història

Un cop el túnel és actiu, el paquet intern de l’aplicació i el paquet extern xifrat són objectes diferents. El paquet intern porta la destinació i la càrrega que ha triat l’aplicació. El paquet extern porta text xifrat a l’adreça i el port del parell, i és el que creua realment la interfície física.

La vostra política afecta un d’ells, i triar l’equivocat és una causa habitual que una regla sembli no fer res. Una regla que coincideix amb l’adreça externa del parell veu tots els paquets del túnel igual, faci el que faci l’aplicació de dins. Una regla que coincideix amb una destinació interna veu el trànsit que us interessa, i només s’activarà si aquest paquet arriba al hook on heu instal·lat la regla.

Els namespaces mouen la frontera

Un contenidor ho fa més difícil sense canviar el principi. La petició de l’aplicació és sortida local dins del namespace de xarxa del contenidor. L’amfitrió rep aquest trànsit en una interfície Ethernet virtual i el pot reenviar, així que una regla FORWARD a l’amfitrió pot tenir sentit encara que el procés que va generar la petició no hagi tocat mai la cadena OUTPUT de l’amfitrió.

Abans de triar un hook, establiu on viuen realment el conjunt de regles i el túnel. Un túnel dins del contenidor, un túnel a l’amfitrió amb el contenidor encaminat a través seu, i un túnel en un namespace separat són tres topologies diferents amb tres ubicacions de regles diferents. Llegiu les regles dins del namespace que posseeix el dispositiu, no només al predeterminat.

Pregunteu si us cal una marca

Si l’objectiu és enviar un prefix de destinació pel túnel, una ruta per a aquest prefix pot ser suficient. Comproveu primer les rutes efectives, incloent-hi qualsevol cosa que hagi empès el servidor: una ruta predeterminada redirigida envia molt més trànsit pel VPN que la política estreta que teníeu al cap, i cap quantitat de marcatge farà que el resultat coincideixi amb la intenció.

La classificació cal quan la decisió depèn d’alguna cosa que una ruta no pot expressar, com l’origen, l’usuari o el procés. Per al trànsit rebut, el marcatge a PREROUTING funciona. Per al trànsit local, el marcatge ha de passar en una etapa de sortida que pugui desencadenar una nova consulta de ruta després d’establir la marca. Amb nftables això és una cadena de tipus route al hook de sortida; una cadena de filtre de sortida ordinària establirà el valor i deixarà la ruta intacta.

Amb iptables, l’equivalent viu a la disposició mangle OUTPUT, i el mateix requisit s’aplica: la decisió d’encaminament s’ha de revisar després que existeixi la marca. Després, una regla de política ha de consumir la marca i apuntar a una taula que contingui una ruta utilitzable. Establir una marca de conntrack és una tercera operació, separada; desa un valor al flux i no posa per si mateixa aquest valor al paquet actual perquè l’encaminament el llegeixi.

Verifiqueu la consulta i el comptador alhora

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

L’adreça i la marca són il·lustratives, i les dues consultes de ruta responen preguntes diferents. La segona pregunta què faria el nucli si un paquet portés aquella marca; no demostra que el vostre conjunt de regles n’assigni cap. Tracteu-la com una prova d’hipòtesi, no com a evidència que la política funciona.

Després executeu una petició innòcua i observeu dues coses alhora: el comptador del hook que heu triat i la sortida que el paquet ha agafat realment. Si el comptador es mou i el paquet surt per un altre lloc, la marca o la taula són incorrectes. Si no es mou cap dels dos, el paquet no arriba gens a aquest hook, i el namespace o el camí són la pregunta següent.

Finalment, limiteu la prova al que el mecanisme pot expressar. Una ruta per a una adreça no es converteix en una política permanent per a un servei les adreces del qual roten. Decidiu primer l’abast dels paquets i després comproveu si el disseny d’encaminament i marcatge pot mantenir aquest abast després d’una reconnexió.