La mateixa IP de servidor, dos camins: marcar el flux exterior d'OpenVPN

La protecció de bucle habitual és una ruta d'host: envia el trànsit cap a l'adreça pública del servidor VPN per l'enllaç ascendent perquè la sessió xifrada no entri mai al seu propi túnel. Això funciona just fins al moment que també vols arribar a un servei web en aquest mateix servidor a través del túnel, perquè l'exempció està lligada a la destinació i la destinació és idèntica. La sortida és deixar de classificar per destinació i començar a classificar per quin socket va enviar el paquet.

Comença pels dos fluxos que vols separar

Un flux és el propi transport OpenVPN xifrat, que ha de sortir per l'enllaç ascendent o el túnel portaria la seva pròpia connexió exterior. L'altre és una petició HTTPS corrent a la mateixa adreça pública, que vols dins del túnel perquè arribi al servei des d'una origen de túnel. Mateixa destinació, en molts casos mateix número de port, ruta necessària diferent.

Per a aquest recorregut, suposa un client a 10.90.0.10 sobre tun1, una adreça pública de servidor de 198.51.100.25 i una taula principal intacta la ruta per defecte de la qual apunta a l'enllaç ascendent habitual. El costat del servidor també ha d'acceptar el servei web a la ruta interior i tornar el trànsit a l'origen del túnel; enviar un paquet a una adreça pública no anul·la l'oient ni la política de tallafocs del servidor.

Abans de canviar res, captura les regles actuals de l'host i tria valors que ningú més no faci servir: una marca, un número de taula i tres prioritats de regla. Mantén una via de tornada a la màquina que no passi per aquesta connexió, perquè un error aquí elimina el teu propi accés remot en comptes de només trencar una pestanya del navegador.

Marca el socket que porta el sobre

La configuració del client guanya una marca per als seus paquets xifrats de sortida, i deixa d'instal·lar rutes per si mateixa perquè la política de substitució sigui l'única cosa que decideixi les rutes:

mark 42
route-noexec
disable-dco

El decimal 42 és hexadecimal 0x2a, i la forma hexadecimal és la que faran coincidir les regles d'encaminament. La referència de link-options descriu mark com una cosa que s'aplica als paquets xifrats de sortida a Linux, que és exactament el socket la ruta del qual cal controlar. Desactivar la descàrrega del canal de dades manté aquest exemple a la ruta de l'espai d'usuari, on el comportament de la marca és el que es descriu.

route-noexec suprimeix les addicions i eliminacions automàtiques de rutes d'OpenVPN. No instal·la res al seu lloc, així que des d'aquest moment el propietari de les rutes ha de mantenir totes les rutes que el túnel necessita. Si una destinació privada desapareix després del canvi, això és la política de substitució que falta, no un error en la marca.

No mantinguis una ruta d'host a la taula principal per a 198.51.100.25 mentre fas això. Una ruta així reintrodueix exactament l'exempció que el disseny intenta estrènyer, i guanyarà per al flux HTTPS abans que es consulti qualsevol de les polítiques de sota.

Envia tota la resta a la taula del túnel

Un cop la interfície del túnel existeix i té la seva adreça, la política queda així:

ip -4 route add default dev tun1 src 10.90.0.10 table 47100
ip -4 rule add priority 20000 lookup main suppress_prefixlength 0
ip -4 rule add priority 20001 not fwmark 0x2a lookup 47100
ip -4 rule add priority 20002 not fwmark 0x2a unreachable

La primera regla manté visibles les rutes específiques de l'host, inclosa qualsevol xarxa local aprovada, mentre fa invisible la ruta per defecte de la taula principal per a aquesta cerca. Aquesta distinció importa: suprimir la per defecte no és el mateix que ignorar la taula, i les excepcions locals que encara necessites sobreviuen per això. Llegeix aquestes excepcions una per una en comptes de suposar que el resultat és un interruptor d'aturada universal.

El trànsit no marcat cau llavors a la taula del túnel, pren l'origen del túnel i surt per la VPN. El trànsit marcat falla la prova fwmark a les dues regles següents i continua cap a la cerca principal habitual més avall a la llista, on encara hi ha la ruta per defecte de l'enllaç ascendent. La regla unreachable final és la que impedeix que un flux no marcat caigui en silenci de tornada a l'enllaç ascendent quan falta la ruta del túnel. El selector és la marca de principi a fi, i l'adreça de destinació no entra mai en la decisió.

Mantén aquesta guarda al seu lloc entre desconnexions, i instal·la-la amb la resta de la política en comptes de a mà. Una regla que desapareix amb la interfície no és una política, és una coincidència. Esborrar la política quan cau el túnel canvia el mode de fallada de “bloquejat” a “filtrat”, i una ruta de túnel obsoleta que caduqui després és un problema molt més fàcil d'explicar que el trànsit que va sortir per la interfície incorrecta.

Fes que la ruta de tornada vegi la mateixa marca

Les marques de sortida són només la meitat del mecanisme, i aquesta és la part que la majoria de reproduccions ometen. Les respostes a la sessió xifrada arriben per l'enllaç ascendent i estan subjectes a la validació de ruta de tornada, que pregunta si l'origen encaminaria de tornada pel mateix camí pel qual va venir. Sense ajuda, aquesta cerca aplica la teva política de túnel no marcada i conclou que el paquet és a la interfície incorrecta.

La correcció pertany al propietari del tallafocs: desa la marca a la connexió de sortida, restaura-la als paquets entrants corresponents i activa el maneig de marques validat per origen per a la ruta pertinent. Que OpenVPN estableixi una marca de socket no fa cap d'aquestes tres coses, i una recepta que només llista les opcions del client està incompleta. Demana aquesta integració per escrit, perquè és la part menys visible del disseny i la més fàcil de perdre en una reconstrucció.

La comprovació laxa de ruta de tornada tampoc no és un substitut. El mode lax encara necessita que existeixi alguna ruta per a l'origen, i la guarda unreachable que vas afegir elimina deliberadament una per a les cerques no marcades. Fes que la integració de la marca de connexió estigui acabada i revisada abans de confiar en aquest disseny, i tracta els filtres d'host com una qüestió a part: una marca és un senyal d'encaminament, no un permís. Si falta la integració, el símptoma és una sessió que s'estableix i després queda en silenci tan bon punt comencen a arribar les respostes.

Demostra-ho amb dues cerques de ruta

Compara què decideix el nucli per als dos contextos, i llegeix els camps dev i src en comptes de l'estat de sortida:

ip -4 route get 198.51.100.25
ip -4 route get 198.51.100.25 mark 0x2a

La primera cerca hauria de resoldre a tun1 amb l'origen del túnel, i la segona a l'enllaç ascendent. Són cerques sintètiques, així que proven la política i no el procés viu: confirma la ruta de transport real del client en execució per separat i després fes una petició HTTPS real amb la verificació de certificats activada.

Anota què no cobreix el disseny abans de declarar-lo acabat. DNS, IPv6 i el cicle de vida de les regles necessiten cadascun la seva pròpia decisió, i això és un exemple d'encaminament IPv4 en comptes d'una configuració de privadesa completa. El seu valor és el selector: el sobre rep l'exempció de l'enllaç ascendent, i un servei normal a la mateixa adreça no ha d'heretar-la.