Arribar a un servei de client VPN: túnel invers o DNAT

Fins i tot un portàtil darrere del NAT de l'operador pot servir un company, sempre que el servidor VPN faci de punt de trobada. Hi ha dos mecanismes per arribar-hi: el client marca cap a fora i demana al servidor que mantingui un port d'escolta, o el servidor publica un port i el tradueix dins del túnel. Tots dos resolen el mateix problema d'abast i es comporten de manera diferent davant de fallades, supervisió i registre. Tres condicions decideixen quin encaixa a la vostra configuració.

Dues formes, un punt de trobada

En la primera forma el client obre una sessió SSH cap a fora i demana al servidor que escolti en un port triat, reenviant cada connexió per aquella sessió. Al servidor no es reenvia res i no es produeix cap traducció de paquets, així que els únics requisits són un compte SSH, un reenviament permès i una regla de tallafoc per al port. El servei queda lligat a loopback al client, que normalment és el que voleu.

ssh -N -R 8081:127.0.0.1:8080 -o ExitOnForwardFailure=yes -o ServerAliveInterval=30 [email protected]

En la segona forma el servidor posseeix el port públic i reescriu cada connexió cap a l'adreça del túnel del client. Això requereix el reenviament IP activat, una traducció de destinació a l'entrada i una traducció d'origen a la sortida, i continua funcionant quan no hi ha cap sessió SSH. El port pertany al servidor i no a una sessió, i aquesta és la propietat que decideix la majoria de casos reals.

Cap de les dues formes és més segura per construcció. Totes dues acaben exposant un port de servei a qui pugui arribar a l'adreça pública del servidor, i totes dues depenen de l'autenticació pròpia del servei.

Condició u: ha de sobreviure el port a la sessió

Un reenviament invers viu exactament el que viu la sessió SSH que l'ha creat. Quan cau l'enllaç, l'oient desapareix i el company veu una connexió rebutjada en lloc d'un camí lent. Supervisar l'ordre amb una unitat de systemd i una política de reinici ho arregla, i ExitOnForwardFailure=yes fa visible immediatament un bind fallit en lloc de deixar una sessió que funciona sense reenviament.

Un port traduït sobreviu als reinicis si les regles es conserven, però depèn que el client mantingui la mateixa adreça de túnel. Un pool dinàmic que dona al portàtil una altra adreça després de reconnectar apunta la regla silenciosament a no res. Reserveu primer l'adreça del túnel, després escriviu la regla i tracteu les dues coses com un sol canvi.

Si el servei ha de respondre a les tres de la matinada sense ningú mirant, la forma amb el port publicat pel servidor té menys peces mòbils, perquè l'únic procés que ha de romandre en marxa és el túnel mateix.

Condició dos: qui posseeix el tallafoc i els registres

La forma inversa manté tota la política en dos llocs. sshd decideix si els reenviaments remots estan permesos en absolut mitjançant AllowTcpForwarding, i GatewayPorts decideix si l'oient s'enllaça a loopback o a totes les adreces. Amb el valor per defecte no, un company fora del servidor no pot arribar al port encara que el reenviament hagi reeixit, i això sembla un túnel trencat quan en realitat és una adreça d'enllaç.

sudo ss -ltn '( sport = :8081 )'
sudo grep -E '^(GatewayPorts|AllowTcpForwarding)' /etc/ssh/sshd_config

La forma traduïda necessita el reenviament activat i dues regles, i la segona regla és on fallen la majoria de receptes. Limitar la traducció d'origen amb l'estat de conntrack DNAT fa que només es reescriguin les connexions creades per la regla de destinació, en lloc de cada paquet que el servidor envia dins del túnel.

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8081 -j DNAT --to-destination 10.88.0.6:8080
sudo iptables -t nat -A POSTROUTING -o tun0 -m conntrack --ctstate DNAT -j SNAT --to-source 10.88.0.1

Aquesta reescriptura també destrueix l'atribució. Després, el client veu cada cridador com l'adreça del túnel del servidor, cosa que col·lapsa qualsevol límit de taxa per adreça en un sol lot i amaga qui ha enviat què. Si l'atribució importa, acabeu la connexió al servidor o manteniu-hi la decisió de permís i passeu una identitat en una capçalera en què el servei confiï. Triar entre aquestes dues correccions depèn de si el servei llegeix capçaleres de proxy.

Condició tres: un port o molts, i qui posseeix el nom

Un sol servei en un sol port és el cas en què el reenviament invers guanya en esforç. Cal una ordre, un compte i una regla de tallafoc, i la neteja és matar la sessió. Diversos serveis a la mateixa adreça pública us empenyen cap a la forma publicada pel servidor, perquè cada reenviament invers necessita el seu port de servidor i el conjunt creix amb cada servei.

Els noms ho compliquen més. Un reenviament invers pot seure darrere d'un proxy TCP que encamina per SNI, mentre que un port traduït sol ser un port per servei. Si el servei acaba el TLS ell mateix i necessita el nom d'amfitrió original, l'enfocament del proxy el conserva i l'enfocament DNAT només el conserva si el servei accepta aquell nom en aquell port.

Anoteu quina de les tres condicions ha decidit la forma. Si no, la propera persona que afegeixi un segon servei reobrirà la mateixa comparació amb menys context.

Decidiu, i després proveu des de fora

Proveu el camí des d'una xarxa que no tingui cap ruta al portàtil, i observeu els comptadors del servidor mentre la petició s'executa. Provar des del servidor cap a la seva pròpia adreça pública no demostra res aquí, perquè el paquet es crea localment i no arriba mai al ganxo de traducció d'entrada, així que la prova pot passar mentre el camí real està trencat.

sudo iptables -t nat -L PREROUTING -n -v
sudo tcpdump -ni any 'tcp port 8081' -c 20

Els comptadors que queden plans volen dir que el paquet no va arribar mai a la regla, cosa que assenyala el proveïdor o el tallafoc de l'amfitrió. Els comptadors que es mouen mentre el servei rebutja assenyalen el tallafoc propi del client o l'adreça on escolta el servei. Un túnel que transporta el paquet però no torna res és un problema de ruta o de camí invers, i cap d'aquests tres resultats no s'ha de depurar editant l'adaptador del client. Anoteu quin comptador s'ha mogut abans de canviar res, perquè la prova següent necessita aquesta línia base.

Quan la forma funcioni, anoteu el port, el propietari i el mètode de supervisió al costat de la configuració del túnel. Una correcció d'abast que només existeix a l'historial de shell d'algú és a un reinici d'un incident repetit.