Poden els clients de dos servidors OpenVPN arribar-se els uns als altres?

Muntar un segon OpenVPN servidor us dona un segon lloc on connectar clients, i res més. No posa aquests clients a la xarxa del primer servidor, i l’opció anomenada client-to-client només canvia el reenviament dins d’un sol procés de servidor. Els dos grups esdevenen una sola xarxa quan encamineu entre ells deliberadament, amb un responsable per a cada sentit. Tot el que segueix assumeix el mode TUN en espai d’usuari amb aquest reenviament intern desactivat, de manera que el nucli pren la decisió.

El mite: una llista de comptes, una xarxa

Autenticació i abast es confonen perquè tots dos viuen a la configuració del servidor. Un usuari que pot iniciar sessió a qualsevol de les dues passarel·les sembla, des de fora, un usuari d’un sol sistema amb dues portes. A dins, cada servidor reparteix adreces del seu propi grup i instal·la rutes només per als clients que acaba. Així, un client de la passarel·la A que envia un paquet a un client de la passarel·la B demana una destinació que el seu servidor no ha sentit mai. El paquet va a la ruta per defecte d’A, surt del túnel i arriba a un tallafoc que mai no havia estat requerit per permetre’l.

Afegir un segon servidor, doncs, no afegeix redundància, descobriment ni un domini de difusió compartit. Afegeix una xarxa encaminada que necessita un pla, i el pla comença per l’adreçament.

Dona a cada passarel·la el seu propi grup i adreça de trànsit

Dos rangs que no poden solapar-se amb res més, més un petit enllaç de trànsit entre els amfitrions, són tot el pla d’adreces. Mantingueu el trànsit en un segment privat que controleu, i escriviu els números abans que cap servidor lliuri un arrendament.

Resistiu la temptació de donar als dos servidors el mateix grup perquè els perfils quedin idèntics. Una ruta del nucli no pot dir quin dels dos amfitrions posseeix ara una adreça arbitrària dins d’un rang compartit, així que la taula d’encaminament apuntaria a una passarel·la i el client podria estar connectat a l’altra. Els noms d’interfície són convencions locals, no estat compartit. Tots dos amfitrions aquí anomenen el dispositiu de túnel tun0 i l’enllaç de trànsit transit0, cosa que està bé perquè cap paquet no porta aquests noms.

Instal·leu la ruta als dos costats

Cada passarel·la necessita una ruta per al grup de l’altra a través de l’adreça de trànsit, i el reenviament ha d’estar actiu perquè qualsevol pugui fer de salt. Confirmeu primer la taula actual, després afegiu l’entrada i persistiu-la a través del gestor de xarxa de l’amfitrió en lloc d’un ganxo de reconnexió.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Reflectiu-ho a l’altre amfitrió amb els grups intercanviats. Afegir repetidament la mateixa ruta des d’un script no relacionat és com un amfitrió acaba amb diverses còpies i un canvi misteriós el proper cop que algú llegeix la taula. Si l’enllaç de trànsit és ell mateix un túnel, la ruta apunta a la topologia d’aquest túnel i el salt ha de sobreviure a la seva reconnexió. Una adreça de trànsit que desapareix durant trenta segons s’endú el camí entre grups, cosa que és una propietat de disseny que val la pena declarar en lloc de descobrir.

Empenyeu la ruta del client sense falsificar la propietat

Els clients necessiten una ruta cap al grup remot, si no el seu propi sistema operatiu envia el paquet a la seva passarel·la per defecte i el túnel no el veu mai. La configuració del servidor és el lloc natural per lliurar-la.

push "route 10.64.20.0 255.255.255.0"

Poseu la línia mirall a la configuració de l’altre servidor, després reconnecteu un client de prova i llegiu la seva taula. Un client que ignora les rutes empenyades necessita la seva pròpia configuració aprovada, i una ruta que no arriba mai no és un control d’accés. No doneu a un client un iroute per a tot el grup de l’altra passarel·la. Aquesta directiva existeix per a una subxarxa darrere d’un client connectat, i fer-la servir per tapar una ruta absent entre passarel·les produeix un servidor que creu posseir adreces que no pot abastar.

Demostreu una petició i refuseu-ne una altra

Trieu una operació real, per exemple HTTPS des d’un client a 10.64.10.21 cap a un servei a 10.64.20.37, i permeteu exactament això als dos amfitrions. Cada tallafoc admet la petició pel seu costat d’entrada i la resposta seguida pel costat de retorn; la política de servei de la destinació encara l’ha d’acceptar.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Amb rutes recíproques, el NAT d’origen és innecessari i aquí activament perjudicial: traduir l’origen amaga quin client va fer la petició i derrota la política basada en origen al costat de la destinació. Comproveu que una regla d’emmascarament existent per a la sortida a internet no atrapi també aquest camí. Després proveu el rebuig. Un servei que ha de quedar local al grup B ha de romandre inaccessible des del grup A, i les parelles de clients de la mateixa passarel·la també s’han de provar, ja que la política de reenviament que acabeu de canviar també els afecta.

Una correcció més al model mental: l’enllaç de trànsit porta paquets interns desxifrats, així que és un límit de confiança i no una garantia privada. Si creua una xarxa que no controleu, protegiu aquest salt amb un túnel xifrat aprovat i encamineu per la seva topologia real. El TLS d’extrem a extrem encara autentica l’aplicació pel seu compte, i per això el servei intern ha de continuar fent-lo servir.