Clients descendents darrere d'un VPN superior: ruta o NAT?

Una passarel·la executa WireGuard per als vostres dispositius i un client OpenVPN cap a la xarxa d'una altra persona. El reenviament entre les dues interfícies internes funciona, i és fàcil concloure que la subxarxa descendent ja forma part del servei superior. No és així. La ruta que extreu el client diu a la vostra passarel·la on ha d'enviar les peticions; no diu res sobre com la xarxa remota retorna el trànsit a dispositius dels quals no ha sentit mai a parlar. Trieu un model de retorn que el servei superior admeti realment abans d'afegir una sola regla.

Decidiu el model de retorn abans de tocar l'encaminament

En aquest recorregut, els clients descendents fan servir 10.90.0.0/24, l'adreça del túnel superior assignada a la passarel·la és 10.80.0.6, i el recurs remot aprovat és 172.20.0.30. Dues models encaixen en aquesta forma: conservar l'origen descendent i aconseguir que el costat llunyà l'encamini, o traduir l'origen a l'adreça del túnel de la pròpia passarel·la. Tot el que ve després d'aquesta decisió és mecànic, i la decisió mateixa necessita el propietari del servei. Una fila de dalt és un acord d'encaminament amb el costat llunyà; l'altra és un canvi de política local que podeu fer tot sol. Confondre les dues és el que converteix un canvi de deu minuts en una negociació.

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

Trieu una fila i comprometeu-vos-hi. Les files són alternatives, no passos, i barrejar-les produeix un disseny que ningú no pot explicar en la revisió.

Conservació de l'origen amb encaminament

El costat llunyà rep una petició d'una adreça descendent, així que necessita una ruta admesa i la propietat del peer per a aquesta subxarxa, a més d'autorització per acceptar-la. Són paràmetres remots, i cap ruta local de Linux els crea. Demaneu-los explícitament i per escrit, amb el prefix i el peer del túnel que la portarà, i espereu que la resposta depengui de si el servei admet o no arranjaments lloc a lloc.

Si la resposta és sí, la configuració local és petita: reenviament activat, els allowed-ips del peer de WireGuard que cobreixen el rang descendent, i una política de tallafocs que permet el creuament en tots dos sentits.

Traducció d'origen deliberada

Si el servei només retorna el trànsit a l'adreça del client connectat, traduïu l'origen a aquesta adreça a la sortida i manteniu l'estat de conntrack que la reverteix per a les respostes. Limiteu la regla a les fonts descendents previstes, a les destinacions remotes previstes i a la interfície superior. Una regla que tradueix tot el que surt de cada interfície és una política molt més gran que aquest requisit, i us sorprendrà més endavant.

IPv6 necessita un disseny propi; copiar una línia de masquerade d'IPv4 no és una arquitectura. Proveu el camí traduït amb una connexió nova en lloc d'una de memòria cau.

El camí de dades local encara ha de funcionar

La traducció no elimina la feina local: la passarel·la encara necessita una ruta per a les destinacions descendents, la propietat correcta de l'origen del peer de WireGuard, el reenviament activat i una política de tallafocs estreta entre interfícies. Una petició generada a la mateixa passarel·la no exerceix cap d'aquests permisos, i per això les proves a la passarel·la passen i els dispositius descendents encara fallen.

Proveu des d'un dispositiu descendent real, no des de la passarel·la. L'adreça d'origen és el sentit de tot l'exercici.

Un origen significa una identitat de sessió

El servei remot veu la sessió autenticada de la passarel·la i la seva adreça traduïda, no una autenticació independent per a cada dispositiu descendent. Manteniu explícits els permisos per dispositiu i les identitats d'aplicació, i confirmeu amb el propietari del servei que una passarel·la que actua per a diversos dispositius està permesa. La traducció no és una manera de saltar-se el requisit d'alta per dispositiu; si el servei exigeix que cada dispositiu es doni d'alta, feu servir aquest model o negocieu un arranjament lloc a lloc.

Escriviu aquesta confirmació al runbook al costat de la regla, perquè el proper revisor preguntarà si el disseny va ser aprovat o només convenient.

Definiu l'estat desconnectat i després proveu tres peticions

Decidiu què passa quan cau el túnel superior. El trànsit remot autoritzat no ha de seguir silenciosament un retrocés ordinari a WAN on això està prohibit, així que la política de tallafocs que permet el creuament també ha de fallar tancada. Després proveu tres casos des d'un dispositiu descendent real: una petició permesa que funciona, una petició no permesa que falla, i un error superior que atura la permesa.

Registreu la reversió en una línia per regla, perquè el canvi es pugui desfer sense reconstruir la intenció.