El servidor web desapareix quan es connecta el client VPN

Un servei que desapareix en el moment que es connecta un client VPN normalment no està bloquejat, sinó que respon per la interfície equivocada. La petició arriba a la targeta de xarxa física, el dimoni escriu una resposta i la taula d’encaminament lliura aquesta resposta al túnel, ja que el túnel ha assumit la ruta per defecte. El client remot no veu mai cap resposta a una connexió que ha obert, així que espera i després informa d’un temps d’espera esgotat. Cap regla de tallafocs no intervé en aquesta seqüència.

El símptoma: peticions endins, respostes per la porta equivocada

La pista és una connexió entrant que falla mentre tota la resta de l’amfitrió funciona. Una altra pista és un amfitrió accessible des de la LAN però no des d’Internet, o un que funciona fins que el túnel es reconnecta i llavors s’atura. En cada cas la direcció d’anada es comportava bé i la de tornada no, cosa que apunta a una asimetria d’encaminament i no a una política.

Confirmeu-ho observant on va la resposta, no observant com arriba la petició.

Captureu alhora a la interfície física i al dispositiu del túnel. Si la petició apareix a la interfície física i la resposta apareix al túnel, el diagnòstic està acabat. Una resposta que no apareix enlloc vol dir que el servei mai no va acceptar la connexió, cosa que és una investigació separada amb una causa separada.

Dues rutes per defecte i una decisió d’encaminament

Un client que instal·la una ruta per defecte afegeix una segona entrada amb una mètrica millor que la del portal de la LAN. Alguns clients instal·len en lloc d’això dues rutes de mig abast, que cobreixen el mateix espai amb més precisió i guanyen la cerca de la mateixa manera. Qualsevol de les dues tècniques deixa que els paquets de sortida ordinaris triïn la interfície del túnel.

Aquesta tria es fa només per destinació. El nucli no pregunta d’on ha vingut un paquet tret que una regla de política li ho ordeni. Així, la resposta a una adreça pública de client es lliura al túnel, l’extrem remot del qual rep un paquet amb una adreça d’origen que no posseeix i el descarta o el reenvia a un lloc inútil. A Linux, el filtratge estricte de camí invers també pot descartar la petició original abans que el vostre servei la vegi, cosa que des de fora sembla idèntica. Tots dos símptomes venen de la mateixa associació absent entre un flux entrant i la seva resposta.

El túnel es comporta correctament en tot moment. Se li va dir que portés la ruta per defecte i fa exactament això.

Repareu el camí de tornada sense trencar el túnel

Existeixen tres formes duradores de reparació, i l’elecció depèn de quant del trànsit propi de l’amfitrió ha de quedar dins del túnel. Excloure la destinació o el port del servei és el canvi més petit. L’encaminament per política segons l’origen o la marca és el més precís. La traducció d’origen és la més grollera i la més fàcil d’explicar dos anys després.

Trieu segons què ha de fer l’amfitrió, no segons quin fragment heu trobat primer.

Excloure una destinació va bé per a un servei amb una adreça pública estable, i lligar el dimoni a l’adreça física en lloc de a totes les adreces fa més segura aquesta exclusió. Una regla de política que tria una taula per origen manté les connexions pròpies de l’amfitrió dins del túnel mentre retorna les respostes del servei pel portal WAN. Fer emmascarament de les respostes a la interfície WAN arriba al mateix camí a costa d’amagar l’adreça del client dels registres del servei. Un canvi ad hoc de la ruta per defecte és un diagnòstic i no una configuració, perquè el client reescriu les rutes a cada reconnexió.

ip rule show
ip route get 203.0.113.9 from 192.0.2.44

Quan l’amfitrió també encamina per a una LAN al darrere

Un salt més enllà, la mateixa asimetria torna amb més peces mòbils. El trànsit arriba al router des d’Internet, es reenvia a un dispositiu intern, i l’únic camí de tornada d’aquest dispositiu és el túnel, així que la resposta arriba al client original des de l’adreça del mateix proveïdor. El seguiment de connexions troba llavors una resposta per a un flux que no ha vist començar, i la descarta. El client, mentrestant, no veu absolutament res.

Dues modificacions ho reparen: traducció de destinació per tal que la connexió entrant arribi al dispositiu intern, i traducció d’origen per tal que la resposta d’aquest dispositiu sembli venir del mateix router.

Al firmware del router l’expressió habitual és una regla de política que fixa el reenviament de ports al costat WAN mentre el trànsit propi del router va pel túnel. Sense traducció d’origen, aquesta resposta s’adreça al client extern i el dispositiu intern simplement no té cap ruta fins a ell. Proveu tres coses per separat, perquè fallen per motius diferents: una connexió que arriba de fora, una que origina el mateix amfitrió i una consulta de nom.