Que un client OpenVPN faci SSH a un altre sense obrir el conjunt d’adreces

Un client ha d’arribar al servei SSH d’un altre client, i la resta del conjunt ha de romandre tan aïllada com ara. L’interruptor temptador és client-to-client, que activa l’accés entre parells per a tothom alhora i lliura la decisió a OpenVPN en lloc del nucli. Una resposta més estreta manté aquest interruptor desactivat i deixa que l’encaminament i el tallafoc del servidor portin exactament un flux.

El mecanisme importa més que el text de la regla, perquè els dos enfocaments posen el paquet en llocs diferents. Saber quin has triat explica tant la regla que sembla no fer res com el parell que es connecta sense ella.

On client-to-client mou el paquet

Amb client-to-client activat, el servidor retransmet un paquet de parell internament en lloc de tornar-lo a enviar pel dispositiu de túnel, de manera que el paquet no arriba mai al camí de reenviament del nucli. Això és còmode i també vol dir que el teu tallafoc no veu mai el flux que hauria de vigilar. Deixa l’opció desactivada i el servidor encamina el paquet de tornada per la mateixa interfície, cosa que el posa davant de netfilter. Mateixa interfície d’entrada, mateixa de sortida, i la cadena FORWARD té el vot.

L’intercanvi és explícit: guanyes un punt de política i assumeixes l’encaminament i el reenviament que la drecera feia per tu. Aquesta feina és petita per a un sol flux i creix amb cada excepció que afegeixes. Compta les excepcions ara, perquè el conjunt de regles és on viu realment la política entre parells.

El camí que segueix realment un paquet de parell

Suposa un servei OpenVPN 2.6 Community en Linux, processament TUN a l’espai d’usuari en lloc de DCO, topologia de subxarxa, tun0 i un conjunt de 10.44.0.0/24 amb el client A a 10.44.0.21 i el client B a 10.44.0.37. Amb topologia de subxarxa, l’adreça i la màscara que ha rebut A ja cobreixen el conjunt, així que A envia el paquet al dispositiu de túnel sense necessitat d’una ruta empenyuda addicional. Comprova la ruta efectiva a A en lloc de suposar-ne una.

Al servidor, el paquet arriba adreçat a B, que no és una adreça local, així que es reenvia. El reenviament IPv4 ha d’estar activat perquè això passi, i la consulta de ruta ha d’enviar el paquet de tornada per tun0. Per tant, el tallafoc veu un flux reenviat amb la mateixa interfície als dos costats, i aquest és el detall que la majoria de conjunts de regles passen per alt. Aquí no cal cap traducció d’origen, i mantenir intacta l’adreça d’A és el que permet que B apliqui la seva pròpia regla basada en l’origen.

Dues regles al servidor, en aquest ordre

Tres regles porten tota la concessió: el reenviament, l’excepció del parell i un descart per defecte per al parell de túnel. La regla d’acceptació anomena el parell i el servei, així que la concessió sobreviu a un conjunt que creix. Col·loca-la abans de qualsevol denegació global per al trànsit túnel-a-túnel, perquè la primera coincidència guanya:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Aquestes ordres són il·lustratives i pertanyen al mecanisme que faci servir el teu amfitrió per persistir regles; una inserció en temps d’execució desapareix a la propera arrencada. La regla amb estat és la que permet que les respostes de B i l’apretada de mans TCP tornin sense una segona acceptació mirall.

Comprova els comptadors després, no el llistat de regles, perquè una regla que no coincideix mai és idèntica a una que funciona. Si els comptadors es queden a zero, el paquet no segueix el camí que creus.

Què ha de permetre encara B

B executa el servei SSH, així que B decideix si algú escolta a l’adreça del túnel i si el seu propi tallafoc accepta l’origen. Un permís de xarxa al servidor no és permís per a cap compte de B, i la verificació de la clau de l’amfitrió i l’autenticació d’usuari segueixen aplicant-se com des de qualsevol altre lloc.

Prova primer el cas positiu: una connexió SSH nova d’A a l’adreça del túnel de B, acceptada amb la clau d’amfitrió esperada. Després prova un altre parell o un altre port i confirma que es rebutja, perquè una concessió que permet tot en silenci és indistingible d’una que funciona fins que importa. Les dues meitats d’aquesta prova són necessàries, i la segona és la que la gent s’estalvia.

Anota les adreces assignades, les rutes efectives als dos clients i les regles exactes al servidor i a B. Un ping correcte a la passarel·la o un port obert al servidor no demostra res d’això, perquè tots dos poden ser certs mentre el reenviament entre parells encara està bloquejat. Escriu aquests números mentre el túnel estigui aixecat, perquè l’adreça que un client rep després de reconnectar-se pot ser una altra.