Un parell VPN fa ping a altres interfícies perquè són locals

Un client WireGuard es connecta i fa ping a una adreça en una interfície completament diferent, i la resposta arriba. Les captures mostren la petició només al túnel. No hi ha res trencat, i la configuració de reenviament que es va desactivar amb cura no hi té res a veure. Aquesta és una comparació entre dos camins que semblen iguals en un diagrama i són completament diferents al nucli.

Un camí reenvia paquets per a algú altre; l’altre els lliura a l’amfitrió mateix.

Un paquet adreçat a l’amfitrió es queda a l’amfitrió

El client remot envia un paquet IP a una adreça que posseeix l’amfitrió. L’encaminament fa una pregunta sobre aquest paquet: aquesta destinació és local? Cada adreça que té l’amfitrió apareix a la taula d’encaminament local, i aquesta taula es consulta abans que la principal, així que el paquet va a la pila pròpia de l’amfitrió en lloc de sortir per una altra interfície. La resposta es genera localment i torna pel túnel perquè és d’on va venir la consulta.

Aquest és tot el mecanisme. No es produeix cap reenviament, no hi intervé cap canvi d’estat de la interfície, i l’adreça en qüestió no cal que sigui abastable des de cap altre lloc.

Per què ip_forward no s’aplica

El reenviament governa els paquets que han de sortir per una interfície diferent de la que van arribar. Un ping a l’amfitrió mateix no pren mai aquest camí: el paquet es consumeix localment i la resposta es genera localment. Per tant, establir net.ipv4.ip_forward=0 no canvia res aquí, i una regla a la cadena de reenviament no veu mai aquest trànsit. El control correcte és al camí d’entrada, limitat per la interfície d’entrada o la font.

Per això, desactivar el reenviament i suposar que l’amfitrió està aïllat produeix una falsa sensació de seguretat.

Llegeix la taula local que va decidir

ip rule show normalment informa d’una regla amb prioritat zero que envia totes les consultes primer a la taula local, i ip route show table local llista les adreces pròpies de l’amfitrió amb abast local. Aquesta taula inclou adreces en interfícies administrativament aturades però encara configurades. Les adreces IPv4 assignades estàticament solen sobreviure a una caiguda de l’enllaç, i és així com un ping a un pont aturat pot encara tenir èxit i sorprendre l’operador.

IPv6 discrepa exactament en aquest punt. Les seves adreces normalment es retiren quan cau l’enllaç, tret que keep_addr_on_down estigui establert. Compareu les famílies en lloc de suposar que una regla cobreix totes dues.

Què arriba a abastar realment un parell

Una resposta des de l’adreça pròpia del router en un segment no diu res sobre les màquines darrere d’aquest segment. El parell no pot arribar a un amfitrió darrere de l’altra interfície per aquest camí; només arriba a les adreces que el router mateix posseeix. Provar un servei en un amfitrió LAN separat, en lloc de fer ping a l’adreça del router, és el que estableix si el reenviament està permès de fet.

Restringir un parell als serveis lligats a l’adreça del túnel és una qüestió de política d’entrada. Permeteu el servei desitjat a la interfície del túnel i restringiu les fonts que el poden usar, perquè el paquet hi arriba de veritat.

Reviseu també les adreces que pensàveu retirar. Treure una adreça d’una interfície és més fiable que apilar regles de tallafoc sobre una adreça obsoleta.