Com un client OpenVPN darrere de NAT es converteix en la sortida a internet

Tres amfitrions Linux, un disseny: un concentrador OpenVPN accessible públicament, un portàtil de consum i una màquina de sortida darrere d'un encaminador domèstic corrent que no reenvia res cap a dins. La sortida marca el concentrador ella mateixa. El trànsit d'internet del consum entra al túnel al portàtil i surt per l'enllaç ascendent de la sortida. Tot el que sorprèn ve d'un detall: la sortida va iniciar la connexió, així que el camí cap a dins ja existeix i no cal cap redirecció de port.

El que segueix ressegueix el camí del paquet i no l'ordre de configuració, perquè la configuració només té sentit quan saps quin component pren quina decisió. Cada capa pren exactament una decisió, i els errors s'apleguen allà on es prenen dues capes per una.

Dues sessions de transport, un camí interior

Cada amfitrió manté la seva connexió exterior al concentrador, i cap d'aquestes connexions no sap res de l'altra. El trànsit del consum cap a internet és un flux interior separat que es transporta dins del túnel del consum i després es torna a emetre des del túnel de la sortida. És aquest flux el que el concentrador ha d'encaminar i el que la sortida ha de reenviar.

outer: consumer --TLS--> hub
outer: exit     --TLS--> hub
inner: consumer --tun--> hub --internal--> exit --tun--> uplink

Com que les dues connexions exteriors surten del costat del client, l'encaminador de la sortida no veu mai cap SYN d'entrada ni necessita cap regla de NAT de destinació. Només ha de mantenir viu el transport establert, cosa que ja fa per a qualsevol connexió llarga. Res d'internet públic no ha d'arribar primer a la sortida, i per això una adreça dinàmica en aquest enllaç no és cap problema. L'encaminador encara ha de permetre la sessió sortint, però és el mateix permís que ja fa servir un navegador.

Què instal·la realment iroute dins del servidor

El concentrador és l'únic dispositiu que decideix quin parell posseeix quina destinació, i ho fa a la seva taula d'encaminament d'espai d'usuari, no a la del nucli. Una entrada client-config-dir per a la sortida anomenada exit-node pot reclamar-hi el prefix per defecte:

# /etc/openvpn/server/ccd/exit-node
iroute 0.0.0.0 0.0.0.0

Aquesta línia diu al procés del servidor "els paquets interiors amb qualsevol destinació pertanyen a aquest client". No afegeix cap ruta per defecte al sistema operatiu del concentrador ni el converteix en passarel·la d'internet. Referència d'OpenVPN 2.6 manté l'encaminament intern específic del client i l'encaminament del nucli com a mecanismes separats, i aquesta separació és la raó per la qual el disseny funciona sense tocar la ruta per defecte del concentrador.

El consum necessita la instrucció mirall, lliurada com a push, perquè el seu trànsit entri al túnel en lloc de sortir per la passarel·la local. Amb topologia de subxarxa, el pool és una ruta connectada al dispositiu tun de la sortida, així que la tornada no necessita cap push addicional; el que la sortida no ha de rebre és la redirecció de sota, que tornaria el seu trànsit ascendent al túnel que intenta fer servir. Envia-la només al consum i llegeix les rutes aplicades al client en lloc de confiar que s'ha triat el fitxer CCD.

# /etc/openvpn/server/ccd/consumer-01
push "redirect-gateway def1"

El nucli de la sortida fa el reenviament

Dins de la sortida, un paquet del consum arriba a la interfície tun adreçat a algun amfitrió d'internet. El nucli consulta la seva taula, troba l'enllaç ascendent real com a millor coincidència i aplica dues polítiques independents: si el paquet es pot reenviar i si pot sortir per aquella interfície amb aquella adreça d'origen. El reenviament és un sysctl i ve desactivat per defecte a moltes distribucions.

Així, la sortida necessita el reenviament IPv4 actiu de manera persistent, una regla que admeti els orígens del túnel del consum cap a l'enllaç ascendent i el camí de resposta pel tun. Activar el reenviament per a tot l'amfitrió també canvia el comportament de qualsevol altra cosa que encamini a través seu, i per això la regla hauria de nomenar orígens i interfícies en lloc d'acceptar-ho tot.

La traducció d'origen és el que compra el camí de tornada

Un amfitrió d'internet no té cap ruta cap a una adreça 10.90.0.x, així que les respostes es descartarien abans d'arribar a la sortida. Reesciure l'origen mentre el paquet surt per l'enllaç ho resol, i el seguiment de connexions desfà la reescriptura a la tornada.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.90.0.0/24 -o enp1s0 -j MASQUERADE
ip -4 route get 10.90.0.9   # run on the exit: must point at the tun

La regla de dalt és un punt de partida per a una interfície ascendent, no una política de tallafoc. Estreny l'origen a les assignacions que has autoritzat i mantén la política d'entrada de la sortida separada perquè l'emmascarament no exposi silenciosament serveis locals. En un amfitrió amb adreça ascendent dinàmica, l'emmascarament també t'estalvia de seguir l'adreça a mà.

On el concentrador pot aplicar normes i on no

Amb client-to-client i el camí de dades tradicional d'espai d'usuari, el concentrador passa paquets interiors entre parells dins del procés del servidor. Mai no travessen la cadena FORWARD del nucli, així que una regla del nucli allà no pot restringir el trànsit entre parells, per acuradament que estigui escrita. L'aplicació ha de viure a la política del servidor: qui pot connectar-se, quin fitxer CCD rep i si la propietat per defecte de la sortida es concedeix.

Per això un iroute per defecte és una decisió àmplia de confiança. La sortida ha d'acceptar legítimament trànsit de tornada d'adreces arbitràries, i ha de ser una màquina que controles, pedaces i supervisis. Concedir la mateixa propietat a un parell a qui no lliuraries un encaminador és l'error que aquest disseny convida a cometre.

La pertinença és el control real. Qualsevol client que pugui configurar les seves rutes pot intentar usar la sortida, així que restringir qui pot connectar-se, o a quins parells servirà, forma part del disseny i no és una idea posterior.

Fallar de manera segura quan la sortida desapareix

Desconnecta la sortida i la propietat per defecte interior desapareix amb la seva sessió. El que no ha de passar és que el concentrador es converteixi en silenci en la sortida substituta: cap ruta per defecte del pool de VPN cap a l'enllaç ascendent, i cap regla àmplia d'emmascarament que reenviaria de bon grat el mateix trànsit. Prova aquesta fallada deliberadament i després la recuperació amb un flux nou i no amb una pàgina ja oberta.

# on the consumer, with the exit up and then down
ip -4 route get 1.1.1.1
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Si el trànsit del consum encara arriba a internet després que la sortida hagi desaparegut, alguna altra cosa el transporta i el límit que volies no existeix. Tracta DNS i IPv6 com a decisions separades: una ruta IPv4 més emmascarament no diu res del trànsit AAAA, i un resolutor empès pel concentrador respondrà des d'on surti realment la consulta.