El client VPN del vostre servidor web trenca les seves respostes?

El lloc es carrega des d'un portàtil a la mateixa xarxa i es perd per temps des de qualsevol altre lloc, i l'amfitrió també executa un client VPN per al seu propi trànsit de sortida. Aquesta combinació produeix una fallada específica: la connexió entrant arriba, la resposta surt pel camí equivocat i el client de fora no veu mai cap resposta. Les dues meitats apareixen a la mateixa captura de paquets, així que l'ordre dels esdeveniments és la part que val la pena llegir.

Una regla d'encaminament basada en l'origen sovint arregla el símptoma. També acostuma a eximir més trànsit que el lloc que la va motivar, i aquesta és la part que val la pena entendre abans de desar la regla.

El símptoma: respon localment i no des de fora

Dins de la xarxa la resposta no ha de travessar el túnel, així que la pàgina es carrega i el servei sembla sa. Des de fora, la petició arriba a l'amfitrió i la resposta s'encamina cap a la VPN, on l'extrem remot no té cap raó per acceptar-la. El navegador veu un temps d'espera en lloc d'un rebuig, que és la signatura d'un camí d'un sol sentit i no d'un port tancat.

Confirmeu la forma abans de canviar l'encaminament: l'oïdor està actiu, la petició local té èxit i la petició externa no produeix cap resposta. Aquestes tres observacions juntes apunten al camí de retorn i no a la configuració del servidor web. Una asimetria tan neta és més útil que qualsevol línia de registre, perquè descarta l'oïdor abans que llegiu un sol missatge d'error.

Mantingueu un camí d'administració independent obert mentre treballeu. Una regla que trenca la vostra pròpia sessió SSH converteix una correcció de deu minuts en una visita física.

Què coincideix realment un selector d'origen

A l'encaminament de polítiques de Linux, una regla com from 192.168.50.2 coincideix amb paquets la font dels quals és aquesta adreça. No codifica el fet que el paquet continua una conversa que va entrar pel router de casa, i no sap quin procés l'ha creat. L'adreça d'aquest exemple és il·lustrativa; substituïu-la per l'adreça que el vostre amfitrió fa servir realment. Tracteu la línia com una afirmació sobre adreces i res més.

Si la taula seleccionada proporciona una ruta per defecte ordinària, cada paquet que porti aquesta font pot prendre la mateixa excepció. Un altre servei lligat a la mateixa adreça l'hereta, i una aplicació que s'enllaça deliberadament a aquesta adreça també l'hereta. La referència de regles de política llista font, destinació, protocol, port, marca i prioritat com a selectors separats, cosa que recorda que la font sola és la més grollera de les disponibles.

La prioritat decideix el resultat. Les cerques van en ordre i la primera taula que produeix un resultat pot acabar la cerca, així que una regla col·locada massa d'hora pot amagar una ruta més específica que una taula posterior hauria proporcionat. Llegiu tota la llista ordenada en lloc de la línia que heu afegit. Una regla que no coincideix mai no costa res, mentre que una que coincideix massa d'hora canvia silenciosament tot el que hi ha darrere.

Comproveu el camí de retorn i el trànsit que no volíeu

Llegiu les regles i les taules, i després pregunteu al nucli quin camí prendria un parell concret d'origen i destinació. Provar des del mateix amfitrió no és el mateix que provar des de fora, així que feu les dues coses.

ip rule show
ip route show table 100
ip route get 203.0.113.44 from 192.168.50.2
ss -ltnp '( sport = :443 )'

Després accepteu una connexió externa nova i, per separat, una petició que encara ha de sortir per la VPN. Si la segona ara surt directament, l'excepció és més àmplia que el problema que estàveu resolent, i la prova que importa és la que no pensàveu canviar.

Una comprovació d'adreça pública al navegador només informa de les peticions que aquell navegador ha fet. No diu res sobre les respostes del servidor web, sobre la selecció d'origen d'una altra aplicació local ni sobre què passa amb el trànsit de gestió després de la propera reconnexió de la VPN.

Decidiu fins a quin punt pot ser estreta l'excepció

Dos dissenys són defensables i s'han de triar deliberadament. Si l'amfitrió existeix per publicar aquest servei i el seu trànsit de sortida no és important, una adreça local dedicada amb una política només per a WAN és un arranjament raonable sempre que accepteu tot l'abast. Si només han de qualificar-se connexions entrants concretes, la selecció d'adreça és massa grollera i al davant hi ha d'anar un disseny conscient de les connexions.

Registreu el contracte en què us baseu: el mapatge públic, l'adreça de l'amfitrió on es lliura la petició i el camí que la resposta ha de prendre. Un servei entrant publicat a través d'un proveïdor de VPN és un contracte diferent del que es publica a través d'un router de casa, i una excepció copiada d'un exemple sovint és equivocada per a l'altre.

Persistiu la política al component que posseeix l'encaminament en lloc d'enganxar una ordre en un fitxer d'inici. L'ordre de les regles, la neteja després d'un canvi de xarxa i la repetició després d'un reinici han de sobreviure, i un fitxer d'inici no provat sol fallar en el moment que no mireu. Acabeu amb el resultat d'acceptació que podeu defensar: un lloc publicat restaurat i un flux no relacionat sense canvis.