Per què el vostre servei públic de Linux respon a través de la VPN

Res del sòcol no recorda quina interfície va portar la petició, així que una ruta per defecte de VPN de túnel complet pot capturar una resposta que pertany a la WAN. El servei no ignora la interfície d’entrada; Linux encamina una resposta generada localment per destinació i política de font. Una regla basada en la font pot enviar només les respostes del servei per una taula WAN completa, deixant la sortida ordinària al túnel. El port queda obert mentre la resposta surt pel camí equivocat, i per això el símptoma sembla unilateral.

La idea errònia: les respostes segueixen la interfície per la qual han arribat

Sembla lògic que un paquet que arriba per eth0 surti per eth0. Els filtres de paquets sense estat es poden escriure així, i tcpdump al costat d’entrada mostra la petició exactament on s’espera. L’encaminament no funciona així per al trànsit que origina el mateix amfitrió.

Un cop el servei accepta la connexió, la seva resposta és un paquet nou generat localment. El nucli consulta les regles d’encaminament per a la destinació i la font de la resposta, i la ruta per defecte de la VPN és una resposta perfectament vàlida. Res del sòcol no recorda quina interfície va portar la petició.

Per això el símptoma sembla unilateral: les peticions arriben, les respostes desapareixen. Per això també afegir una regla de tallafoc per al port d’entrada no canvia res. El paquet no es bloqueja a l’entrada; s’encamina a un altre lloc a la sortida. Seguiu la resposta amb una consulta qualificada per la font i el desviament es fa visible.

Què encamina realment el nucli: l’adreça de font

El mànec que necessiteu és l’adreça local que el servei fa servir per a les respostes. En un amfitrió amb l’adreça eth0 il·lustrativa 192.0.2.10/24 i la passarel·la 192.0.2.1, aquesta adreça és present a la interfície. En una VM al núvol, l’adreça pública pot ser traduïda aigües amunt i absent del convidat, així que feu servir l’adreça que l’amfitrió realment té.

Inspeccioneu l’estat actual abans de reservar un número de taula o una prioritat de regla. Les regles de política existents poden fer ombra a una de nova, i una taula antiga amb el mateix número pot ja portar rutes no relacionades:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Després seleccioneu una taula per font. La regla coincideix amb les respostes que ja porten 192.0.2.10, exactament el trànsit acabat localment que voleu eximir. El trànsit reenviat i els paquets d’altres adreces locals no coincideixen.

Construïu una taula de retorn completa, no mitja ruta per defecte

Una taula amb només una ruta per defecte no és suficient. El nucli encara ha de resoldre la passarel·la, i aquesta resolució necessita el prefix connectat a la mateixa taula. Una taula a la qual falta aquest prefix falla en la resolució de la passarel·la encara que la seva ruta per defecte sembli correcta. Afegiu les dues coses i després apunteu la regla de font a la taula:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Feu servir el prefix i la passarel·la reals en lloc de copiar l’exemple. Una interfície al núvol configurada com a /32 amb una passarel·la enllaçada necessita una ruta connectada diferent, i una taula construïda amb el prefix equivocat falla al primer salt. L’atribut src indica la font preferida per a aquesta ruta; no substitueix la regla de font.

L’ordre també importa. Una regla àmplia amb un número de prioritat més baix s’avalua primer, així que la regla de font s’ha d’assolir abans de qualsevol regla que tornés aquest trànsit a la taula principal. Comproveu les prioritats amb ip rule show després d’afegir-la, no només a l’arrencada.

Verifiqueu amb una consulta qualificada per la font

Demaneu al nucli que encamini una destinació de prova des de l’adreça del servei. La resposta hauria de nomenar eth0 i la passarel·la WAN, no el túnel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Després establiu una connexió autoritzada nova i observeu les dues direccions. Una consulta que tria la taula correcta mentre la connexió viva encara falla apunta al filtratge de camí invers o a una regla de tallafoc, no a la taula. Comproveu aquests controls abans de desactivar res globalment.

Poseu les rutes finals i la regla sota el gestor de xarxa que posseeix la interfície. Els canvis d’adreça, la renovació de DHCP i les reconnexions de VPN reescriuen tot l’estat del nucli, i una regla afegida a mà desapareix o apunta a una passarel·la obsoleta després del següent esdeveniment.

On s’atura aquesta excepció

La regla eximeix el trànsit acabat localment d’una adreça de font. No cobreix els ports publicats per Docker, el DNAT ni els serveis reenviats a través de l’amfitrió, perquè aquests paquets s’encaminen com a trànsit reenviat i mai no porten la font local de l’amfitrió de la mateixa manera. Aquests dissenys solen necessitar una marca posada a l’entrada i una regla que coincideixi amb la marca.

També no fa aparèixer l’adreça pública de l’amfitrió a la interfície. Quan un NAT aigües amunt posseeix aquesta adreça, la resposta encara ha de sortir pel camí que aquell NAT espera, i per això la taula WAN ha de reflectir la passarel·la i el prefix originals en lloc d’un rang públic endevinat.

Mantingueu l’excepció documentada amb el seu número de taula, la prioritat de la regla i l’adreça de font exacta. El proper canvi a la VPN o a la interfície pot trencar-la silenciosament, i una nota que anomeni els tres valors és més ràpida de comprovar que retrobar el símptoma en un informe de client.

Si el servei encara respon pel camí equivocat després que la consulta qualificada per la font passi, compareu l’adreça de font del sòcol viu amb la de la regla. Un servei lligat a una adreça comodí pot triar una font diferent de l’adreça que heu provat, i aquest desajust és la llacuna restant.