Por que un cliente VPN na LAN da oficina perde todas as respostas

Un portátil está na /24 da oficina por Ethernet e tamén se une a un servidor OpenVPN que vive nesa mesma /24. Un compañeiro fai ping ao enderezo do túnel; a petición chega con claridade e non volve nada. O rexistro do túnel está limpo e a navegación segue funcionando, así que o túnel é o sospeitoso equivocado. A validación de orixe IPv4 na máquina que recibe tira o paquete antes de que nada o lea.

O descarte ocorre antes de que nada lea o paquete

A validación de orixe fai unha pregunta sobre cada paquete entrante: se este equipo respondese a esa orixe, a resposta sairía pola interface pola que acaba de chegar o paquete? Cando a resposta é non, o núcleo tira o paquete ao chegar. Nin un socket nin unha ruta de reenvío o ven xamais, e por iso unha captura no túnel segue rexistrando unha petición que a aplicación nunca recibe.

O cliente de aquí ten 10.66.0.9 no seu túnel, e o servidor OpenVPN responde en 192.168.80.10 dentro do prefixo da oficina. Un compañeiro en 192.168.80.25 fai ping ao enderezo do túnel, así que a petición cruza a LAN, o servidor encamíñaa ao túnel e chega á interface do túnel do cliente cun enderezo de orixe da oficina. Na táboa de rutas desa máquina o prefixo da oficina pertence ao dispositivo Ethernet, non ao túnel. A validación compara a interface de chegada coa ruta, atopa unha discrepancia e descarta o paquete, así que o compañeiro ve unha perda total mentres os dous extremos informan dun túnel san.

A dirección espello ten a mesma forma: cando o cliente inicia cara á oficina, as respostas poden descartarse no lado da oficina polo mesmo motivo. Unha corrección verificada só nunha dirección adoita volver como un segundo tique.

Demostre o modo vixente antes de tocar un sysctl

Lea os valores efectivos en lugar de confiar nun valor por defecto da distribución, porque o axuste por interface é só a metade da decisión. O modo vixente é o maior entre o valor da interface e o valor de all, así que un cero na interface do túnel non significa nada mentres all sexa un. A decisión do modo estrito é unha decisión de encamiñamento, así que execute a consulta que executa o núcleo e compare a súa resposta coa interface pola que o paquete chegou de verdade.

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

Despois repita o ping mentres vixía o contador de erros. Un contador que sobe xunto a unha petición que a captura xa mostra é a sinatura deste descarte, non a dunha ruta ausente. Active o rexistro de paquetes marcianos mentres está alí, para que o núcleo nomee a orixe e a interface que rexeitou. Xuntos descartan o cifrado, a devasa e un iroute ausente como explicacións.

Anote a liña base antes de cambiar nada: ambos os valores, o dispositivo que escolleu a consulta e o contador que vixiou. Ese rexistro é o que lle dirá despois se o cambio fixo o que vostede cre.

Que acepta realmente cada modo de rp_filter

O núcleo expón tres valores por interface, e non son tres matices dunha mesma regra. Cero desactiva a comprobación. Un é estrito e esixe que a orixe se encamiñe de volta pola interface de chegada. Dous é laxo e só esixe que exista algunha ruta cara á orixe na táboa, apunte onde apunte.

A fila que importa aquí é a laxa, e o que segue rexeitando. Unha orixe falsificada que sexa encamiñable en calquera parte da súa táboa pasa, mentres que unha orixe sen ningunha ruta aínda se rexeita. Nun portátil é unha concesión estreita; nun router que reenvía tráfico doutras persoas é ampla. O modo pertence ao equipo, así que o mesmo número ten distinto peso nos dous sitios.

Que fila necesita esta topoloxía dedúcese da táboa e non do costume. O paquete é lexítimo e a súa orixe é encamiñable, así que o laxo o acepta e o estrito non. Nada do caso pide cero, e escoller cero quitaría unha comprobación que aquí non custa nada.

Escolla o cambio máis pequeno que elimina a ambigüidade

O modo laxo é o cambio máis pequeno que encaixa, e é unha redución real do rigor, non un interruptor inocuo. Existe unha opción mellor sempre que a topoloxía o permita: elimine a superposición e a ambigüidade desaparece.

Onde o prefixo da oficina só se necesita por Ethernet, quíteo das rutas que arrastra o perfil e o enderezo pasa a ser alcanzable por un só camiño. Cando os dous camiños teñen que coexistir de verdade, fixe a orixe e o dispositivo cunha regra de política en lugar de afrouxar a validación en cada interface. Iso mantén o filtrado estrito para todo o demais na máquina e documenta a excepción onde o seguinte enxeñeiro a buscará.

Sexa cal sexa o camiño que escolla, anóteo nun drop-in de sysctl e non nun comando en vivo. Defina as chaves all e default xuntas, para que unha reconexión non poida restaurar o modo estrito en silencio.

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

Que cede o modo laxo, e onde

O modo laxo segue rexeitando unha orixe que ningunha ruta podería alcanzar, e deixa de rexeitar unha orixe falsificada que resulta ser encamiñable. Nun portátil é unha concesión estreita. Nun dispositivo que reenvía tráfico que non posúe, a mesma escolla é moito máis ampla. Por iso o mesmo axuste ten dous significados moi distintos segundo onde se execute.

Apagar a comprobación por completo, nun equipo que reenvía tráfico para outras persoas, é a única reparación que convén evitar. Cero tira a validación que o modo laxo coida de manter. Se o equipo reenvía para outros, defenda no seu lugar a opción da regra de política da sección anterior.

Deixe unha nota que nomee as dúas interfaces, o prefixo solapado e a proba exacta que agora ten éxito. Isto é máis útil para o seguinte enxeñeiro que unha liña que diga que se axustou o filtrado.