Per què un client VPN a la LAN de l’oficina perd totes les respostes

Un portàtil seu a la /24 de l’oficina per Ethernet i també s’uneix a un servidor OpenVPN que viu en aquesta mateixa /24. Un company fa ping a l’adreça del túnel; la petició arriba clarament i no en torna res. El registre del túnel és net i la navegació encara funciona, així que el túnel és el sospitós equivocat. La validació d’origen IPv4 a la màquina que rep llença el paquet abans que res el llegeixi.

El descart passa abans que res llegeixi el paquet

La validació d’origen fa una pregunta sobre cada paquet entrant: si aquest amfitrió respongués a aquell origen, la resposta sortiria per la interfície per on acaba d’arribar el paquet? Quan la resposta és no, el nucli llença el paquet en arribar. Ni cap sòcol ni cap camí de reenviament el veuen mai, i per això una captura al túnel encara registra una petició que l’aplicació no rep mai.

El client d’aquí té 10.66.0.9 al seu túnel, i el servidor OpenVPN respon a 192.168.80.10 dins del prefix de l’oficina. Un company a 192.168.80.25 fa ping a l’adreça del túnel, així que la petició travessa la LAN, el servidor l’encamina cap al túnel i arriba a la interfície del túnel del client amb una adreça d’origen de l’oficina. A la taula d’encaminament d’aquella màquina el prefix de l’oficina pertany al dispositiu Ethernet, no al túnel. La validació compara la interfície d’arribada amb la ruta, troba una discrepància i descarta el paquet, així que el company veu una pèrdua total mentre els dos extrems informen d’un túnel sa.

La direcció mirall té la mateixa forma: quan el client inicia cap a l’oficina, les respostes es poden descartar al costat de l’oficina pel mateix motiu. Una correcció verificada només en una direcció sol tornar com a segon tiquet.

Demostreu el mode vigent abans de tocar cap sysctl

Llegiu els valors efectius en comptes de confiar en un valor per defecte de la distribució, perquè el paràmetre per interfície és només la meitat de la decisió. El mode vigent és el més alt entre el valor de la interfície i el valor d’all, així que un zero a la interfície del túnel no vol dir res mentre all val un. La decisió del mode estricte és una decisió d’encaminament, així que executeu la consulta que executa el nucli i compareu-ne la resposta amb la interfície per on el paquet va arribar realment.

tcpdump -ni tun0 icmp and host 192.168.80.25
ip route get 192.168.80.25
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.tun0.rp_filter

Després repetiu el ping mentre mireu el comptador d’errors. Un comptador que puja al costat d’una petició que la captura ja mostra és la signatura d’aquest descart, no la d’una ruta absent. Activeu el registre de paquets marcians mentre hi sou, perquè el nucli anomeni l’origen i la interfície que ha rebutjat. Junts descarten el xifratge, el tallafoc i un iroute absent com a explicacions.

Anoteu la línia base abans de canviar res: els dos valors, el dispositiu que ha triat la consulta i el comptador que heu mirat. Aquest registre és el que us dirà després si el canvi ha fet el que penseu.

Què accepta realment cada mode d’rp_filter

El nucli exposa tres valors per interfície, i no són tres matisos d’una mateixa regla. Zero desactiva la comprovació. Un és estricte i exigeix que l’origen es torni a encaminar per la interfície d’arribada. Dos és lax i només exigeix que existeixi alguna ruta cap a l’origen a la taula, apunti on apunti.

La fila que importa aquí és la lax, i què continua rebutjant. Un origen falsificat que sigui encaminable en qualsevol lloc de la vostra taula passa, mentre que un origen sense cap ruta encara es refusa. En un portàtil és una concessió estreta; en un encaminador que reenvia trànsit d’altres persones és àmplia. El mode pertany a l’amfitrió, així que el mateix número té un pes diferent als dos llocs.

Quina fila necessita aquesta topologia es dedueix de la taula i no del costum. El paquet és legítim i el seu origen és encaminable, així que el lax l’accepta i l’estricte no. Res del cas no demana zero, i triar zero trauria una comprovació que aquí no costa res.

Trieu el canvi més petit que elimina l’ambigüitat

El mode lax és el canvi més petit que encaixa, i és una reducció real del rigor, no un interruptor innòcu. Hi ha una opció millor sempre que la topologia ho permet: traieu la superposició i l’ambigüitat desapareix.

On el prefix de l’oficina només cal per Ethernet, traieu-lo de les rutes que estira el perfil i l’adreça esdevé abastable per un sol camí. Quan els dos camins han de coexistir de debò, fixeu l’origen i el dispositiu amb una regla de política en lloc d’afluixar la validació a cada interfície. Això manté el filtratge estricte per a tota la resta de la màquina i documenta l’excepció on el proper enginyer la buscarà.

Sigui quin sigui el camí que trieu, anoteu-lo en un drop-in de sysctl i no en una ordre en viu. Definiu les claus all i default juntes, perquè una reconnexió no pugui restaurar el mode estricte en silenci.

# /etc/sysctl.d/99-rp-filter.conf
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.all.rp_filter = 2
sysctl --system

Què cedeix el mode lax, i on

El mode lax encara rebutja un origen que cap ruta no podria assolir, i deixa de rebutjar un origen falsificat que resulti encaminable. En un portàtil és una concessió estreta. En un dispositiu que reenvia trànsit que no posseeix, la mateixa tria és molt més àmplia. Per tant, el mateix paràmetre té dos significats molt diferents segons on s’executa.

Apagar la comprovació del tot, en un amfitrió que reenvia trànsit per a altres persones, és l’única reparació que cal evitar. Zero llença la validació que el mode lax té cura de mantenir. Si l’amfitrió reenvia per a altres, defenseu en canvi l’opció de la regla de política de la secció anterior.

Deixeu una nota que anomeni les dues interfícies, el prefix superposat i la prova exacta que ara té èxit. Això és més útil per al proper enginyer que una línia que digui que s’ha ajustat el filtratge.