Per què l'adreça del túnel VPN no obre cap port d'entrada
Una adreça de túnel identifica el vostre client davant dels parells que hi poden encaminar, i mai no crea cap oient. Reviseu l'enllaç, la ruta de tornada i després la política.
Connecteu-vos a la VPN de l'oficina, inicieu un servei petit al port 8443, envieu l'adreça del túnel a un company i observeu com la connexió falla mentre el client encara informa que està connectat. Al túnel no hi ha res trencat: l'adreça s'ha assignat, la sessió és activa i els paquets que haurien de portar la resposta senzillament no s'admeten mai. Feu les tres comprovacions següents per ordre i atureu-vos a la que falli, perquè cadascuna té una correcció diferent i només una té a veure amb la VPN.
Comenceu per on està realment enllaçat el sòcol
Abans que res s'encamini, alguna cosa ha d'estar escoltant en una adreça que el cridador pugui assolir. Els servidors de desenvolupament són el culpable habitual, perquè molts s'enllacen per defecte a loopback i només accepten connexions que s'originen a la mateixa màquina. Una adreça de túnel no canvia aquest enllaç, i el sistema operatiu rebutjarà la connexió molt abans que la VPN hi intervingui.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Llegiu la columna de l'adreça local en lloc de l'estat. 127.0.0.1:8443 vol dir només loopback, i la correcció és un enllaç a 0.0.0.0 o a la mateixa adreça del túnel. 0.0.0.0:8443 accepta a totes les interfícies, cosa que és més ampli del que la majoria pretén quan la màquina també té una adreça pública; 10.64.7.15:8443 és la versió estreta que només escolta on el company pot arribar. Fixeu-vos també en el nom del procés a la mateixa sortida, perquè una instància perduda d'una prova anterior és una causa habitual que el port sembli obert i respongui amb el contingut equivocat.
Després pregunteu si alguna cosa pot encaminar cap a aquesta adreça
Una adreça de túnel només té sentit per als parells configurats per enviar aquest prefix dins del túnel. La màquina del company té la seva pròpia taula i, si no té una ruta per a la subxarxa del túnel, el paquet va a la porta d'enllaç per defecte i mor en un lloc que no té ni idea que l'adreça existeix. Això és una qüestió d'encaminament al costat del cridador, no un permís al vostre costat.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
El servidor entre els dos clients importa igualment. En el disseny habitual d'accés remot, cada client obre una connexió sortint cap a la porta d'enllaç i aquesta manté l'estat d'aquests fluxos, de manera que les respostes tornen per un camí que ja coneix. Una connexió d'un client a un altre és un flux nou que la porta d'enllaç ha d'acceptar i reenviar, i molts desplegaments ho desactiven deliberadament per mantenir els clients aïllats entre ells. Els serveis VPN de consum solen aïllar per defecte; les portes d'enllaç corporatives de vegades ho permeten per grup.
Comproveu la direcció abans de canviar res a l'amfitrió. Si l'adreça del túnel respon des de la mateixa porta d'enllaç però no des d'un parell, la diferència és el paràmetre de client a client de la porta d'enllaç, i cap edició del tallafoc local no el pot substituir.
Finalment, trobeu la política que permet el flux
Tres capes de política se situen entre un paquet encaminat i un servei que respon: la decisió de reenviament del servidor VPN, el tallafoc de l'amfitrió i qualsevol grup de seguretat del núvol davant de la instància. Totes tres han de coincidir i fallen de maneres diferents, per això el símptoma de la taula anterior és més útil que el missatge d'error del navegador.
El tallafoc de l'amfitrió és la capa que la gent oblida després d'un enllaç correcte, perquè una regla que permet el port a la interfície LAN no el permet automàticament a la interfície del túnel. Les regles limitades per interfície són un disseny correcte i també la causa habitual d'un servei que funciona des de l'oficina i no des de casa. Llegiu l'abast de la regla, no el número de port.
El filtratge amb estat explica el cas invers. Una connexió sortint del vostre portàtil crea estat, i les respostes s'admeten sense cap regla d'entrada. La connexió del company és un flux completament nou sense estat al darrere, així que necessita una autorització explícita. Aquesta asimetria és tota la raó per la qual una sessió de navegador que funciona a la vostra màquina no diu res sobre si el servei és accessible des de fora.
Quan una comprovació falla, canvieu el disseny, no el túnel
Si el requisit és que un company obri el vostre servei local, la resposta honesta sol ser un mecanisme pensat per a l'accés d'entrada. Un túnel SSH invers és el més petit: la vostra màquina es connecta cap enfora a un amfitrió que el company ja pot assolir, i l'oient existeix en aquell amfitrió.
ssh -N -R 8443:127.0.0.1:8443 [email protected]El relé necessita GatewayPorts clientspecified a la configuració del seu servidor SSH, si no l'oient reenviat s'enllaça a loopback al relé i el company troba la mateixa negativa que abans. Per a qualsevol cosa que duri més d'una tarda, un balancejador de càrrega o un ingress amb comprovació de salut i certificat per al nom publicat és el millor instrument, i un túnel lloc a lloc amb rutes per a les dues subxarxes és la resposta correcta quan dues xarxes realment han de parlar.
Cadascun d'aquests dissenys fa explícita l'exposició, i aquest és el punt. Una VPN mou paquets entre xarxes que ja teníeu autoritzades; no publica cap servei ni converteix un portàtil en un amfitrió obert a internet. Decidir quina de les tres capes cal canviar és la feina, i el túnel poques vegades és una d'elles.