VPN connectat però el tallafoc encara bloqueja: com saber quin dels dos

El client diu connectat, el recurs encara refusa, i el següent pas habitual és desactivar alguna cosa. Els dos controls d'aquesta frase fan feines diferents: la VPN construeix un camí per al trànsit cobert, i el tallafoc decideix per connexió si el trànsit pot passar. Un túnel que funciona amb una política que refusa sembla exactament un túnel trencat des de la cadira de l'usuari, així que la feina és trobar quina capa respon. Aquest és l'ordre que segueixo, amb la lectura que et diu que t'aturis.

Separa el camí de la política

Comença per la forma de la fallada, perquè és informació gratuïta. Una caiguda de paquet produeix un temps d'espera: el client reintenta, no torna res i l'ordre penja fins que es rendeix. Un rebuig produeix una negativa o un reinici: alguna cosa va respondre i va dir que no. Un servei que no escolta refusa al mateix amfitrió, sense cap tallafoc pel mig.

Aquests tres resultats apunten a capes diferents. El temps d'espera vol dir que alguna política en algun lloc descarta en silenci, o que la ruta no deixa mai la màquina. Refusat vol dir que vas arribar a l'amfitrió i la seva pila o el seu tallafoc local ho va declinar. Silenci total, amb la interfície del túnel activa i sense ruta a la destinació, vol dir que el camí és erroni i cap regla de tallafoc ho arreglarà.

Llegeix el camí d'una passada

Confirma que el túnel cobreix la destinació abans de mirar ni una sola regla. Un túnel dividit que només porta la subxarxa de l'oficina no encaminarà una petició a un altre rang, i llavors la fallada sembla un bloqueig del tallafoc que no ho és:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

La sortida de la ruta anomena la interfície per la qual el paquet sortirà i l'adreça d'origen que portarà. Si aquesta interfície és la teva targeta de xarxa física i no el túnel, el problema és d'encaminament o dels rangs permesos del túnel, i pertany a la configuració de la VPN i no al tallafoc.

Una trampa específica de la VPN mereix la seva pròpia comprovació. A WireGuard, AllowedIPs d'un parell és alhora una ruta i un filtre criptogràfic: un paquet l'adreça d'origen del qual no coincideix amb el conjunt permès del parell es descarta abans que es consulti cap regla de tallafoc. Així, un tallafoc local perfectament correcte pot estar darrere d'un descart silenciós que sembla una política, i l'arreglament és una línia de configuració de clau i no una regla.

Llegeix la política a la capa que respon

Un cop el camí és correcte, recorre la política des de l'amfitrió cap enfora i mira la única capa els comptadors de la qual es mouen:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

El sòcol que escolta respon una pregunta diferent de la de les regles. Si no hi ha res escoltant al port, el nucli refusa la connexió i cap regla d'entrada no hi té res a veure. Si el sòcol existeix i la connexió des d'un client remot expira, s'està produint un descart en algun punt del camí, i els comptadors de les regles et diuen si passa aquí.

Activa el registre per al perfil o la cadena que sospites en lloc d'endevinar des de fora. Un sol descart registrat que anomena l'origen, la destinació i el port identifica la capa i la regla, i també demostra que el paquet va arribar, cosa que cap prova des del costat del client pot establir.

Llegeix la decisió de la passarel·la quan el túnel hi acaba

En una passarel·la lloc a lloc o d'accés remot, la VPN autentica un usuari i la política autoritza un recurs, i això són concessions separades. Un usuari admès al túnel no és admès automàticament a cada amfitrió intern, i la negativa sovint ve d'una regla de reenviament mentre el túnel mateix és sa. La mateixa separació apareix a IPsec, on la política de seguretat que selecciona el trànsit és diferent del filtre que l'admet, i per això els dos es documenten com a mecanismes diferents a RFC 4301.

Comprova el camí de tornada tan acuradament com el de sortida. El filtratge amb estat ha de veure la resposta, així que l'encaminament asimètric pel túnel en una direcció i al seu voltant en l'altra produeix descarts que semblen aleatoris i només es reprodueixen des d'alguns clients. Si el trànsit arriba a la passarel·la i s'atura, llegeix la regla de reenviament i la ruta de tornada alhora abans d'ampliar res.

La passarel·la és també on una regla de NAT o d'emmascarament pot amagar l'origen real. Si els amfitrions interns veuen l'adreça de la passarel·la en lloc del client, les seves regles de tallafoc local que han de coincidir amb el conjunt de clients no coincidiran mai, i l'arreglament pertany a la passarel·la i no a cada servidor.

Canvia la capa més estreta i després verifica

Resisteix la reparació àmplia. Desactivar el tallafoc local, afegir una regla que ho permeti tot o forçar cada interfície a un perfil de confiança elimina en cada cas el control que feia la seva feina, i el canvi sobreviu a l'incident. Una regla limitada al rang d'origen i al port en qüestió és més fàcil de revisar, més fàcil de treure i deixa la resta de la política de la màquina intacta.

Verifica amb la mateixa prova que va fallar, des del mateix client, i després una vegada més després de reconnectar, perquè una regla que coincideix abans que el túnel renegociï pot deixar de coincidir després:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Abans de tancar-ho:

• La ruta cap a la destinació surt per la interfície del túnel, i l'adreça d'origen coincideix amb el que la política espera.
• Alguna cosa escolta al port, i la negativa o el temps d'espera s'atribueix a una regla nomenada i no se suposa.
• La passarel·la reenvia en tots dos sentits, i la destinació veu l'origen per al qual es van escriure les teves regles.
• Cap control es va desactivar per fer passar la prova, i el canvi que vas fer anomena un sol rang d'origen i un sol port.