O mesmo IP de servidor, dúas rutas: marcar o fluxo exterior de OpenVPN

A protección de bucle habitual é unha ruta de host: envía o tráfico cara ao enderezo público do servidor VPN pola conexión ascendente para que a sesión cifrada nunca entre no seu propio túnel. Isto funciona xusto ata o momento en que tamén queres chegar a un servizo web no mesmo servidor a través do túnel, porque a exención está ligada ao destino e o destino é idéntico. A saída é deixar de clasificar por destino e comezar a clasificar por que socket enviou o paquete.

Comeza polos dous fluxos que queres separar

Un fluxo é o propio transporte OpenVPN cifrado, que ten que saír pola conexión ascendente, senón o túnel levaría a súa propia conexión exterior. O outro é unha solicitude HTTPS normal ao mesmo enderezo público, que queres dentro do túnel para que chegue ao servizo desde unha fonte de túnel. Mesmo destino, en moitos casos mesmo número de porto, ruta necesaria distinta.

Para este percorrido, supón un cliente en 10.90.0.10 sobre tun1, un enderezo público de servidor de 198.51.100.25 e unha táboa principal intacta cuxa ruta predeterminada apunta á conexión ascendente habitual. O lado do servidor tamén ten que aceptar o servizo web na ruta interior e devolver o tráfico á fonte do túnel; enviar un paquete a un enderezo público non anula o listener nin a política de firewall do servidor.

Antes de cambiar nada, captura as regras actuais do host e escolle valores que ninguén máis use: unha marca, un número de táboa e tres prioridades de regra. Mantén unha vía de volta á máquina que non pase por esta conexión, porque un erro aquí elimina o teu propio acceso remoto en vez de só romper unha pestana do navegador.

Marca o socket que leva o sobre

A configuración do cliente gaña unha marca para os seus paquetes cifrados de saída, e deixa de instalar rutas por si mesma para que a política de substitución sexa o único que decida as rutas:

mark 42
route-noexec
disable-dco

O decimal 42 é hexadecimal 0x2a, e a forma hexadecimal é a que van coincidir as regras de encamiñamento. A referencia das link-options describe mark como algo que se aplica aos paquetes cifrados de saída en Linux, que é exactamente o socket cuxa ruta cómpre controlar. Desactivar o offload do canal de datos mantén este exemplo na ruta do espazo de usuario, onde o comportamento da marca é o que se describe.

route-noexec suprime as adicións e eliminacións automáticas de rutas de OpenVPN. Non instala nada no seu lugar, así que desde este momento o dono das rutas ten que manter todas as rutas que o túnel necesita. Se un destino privado desaparece despois do cambio, iso é a política de substitución que falta, non un fallo na marca.

Non manteñas unha ruta de host na táboa principal para 198.51.100.25 mentres fas isto. Unha ruta así reintroduce exactamente a exención que o deseño intenta estreitar, e gañará para o fluxo HTTPS antes de que se consulte calquera das políticas de abaixo.

Envía todo o demais á táboa do túnel

Unha vez que a interface do túnel existe e ten o seu enderezo, a política queda así:

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

A primeira regra mantén visibles as rutas específicas do host, incluída calquera rede local aprobada, mentres fai invisible a ruta predeterminada da táboa principal para esta busca. Esa distinción importa: suprimir a predeterminada non é o mesmo que ignorar a táboa, e as excepcións locais que aínda necesitas sobreviven por iso. Le esas excepcións unha por unha en vez de supoñer que o resultado é un interruptor de parada universal.

O tráfico non marcado cae entón na táboa do túnel, toma a fonte do túnel e sae pola VPN. O tráfico marcado falla a proba fwmark nas dúas regras seguintes e continúa cara á busca principal habitual máis abaixo na lista, onde aínda está a ruta predeterminada da conexión ascendente. A regra unreachable final é a que impide que un fluxo non marcado caia silenciosamente de volta na conexión ascendente cando falta a ruta do túnel. O selector é a marca de principio a fin, e o enderezo de destino nunca entra na decisión.

Mantén esa garda no seu sitio entre desconexións, e instálaa co resto da política en vez de a man. Unha regra que desaparece coa interface non é unha política, é unha coincidencia. Borrar a política cando cae o túnel cambia o modo de fallo de “bloqueado” a “filtrado”, e unha ruta de túnel obsoleta que caduca despois é un problema moito máis doado de explicar que o tráfico que saíu pola interface incorrecta.

Fai que a ruta de volta vexa a mesma marca

As marcas de saída son só a metade do mecanismo, e esta é a parte que a maioría das reproducións omiten. As respostas á sesión cifrada chegan pola conexión ascendente e están suxeitas á validación da ruta de volta, que pregunta se a fonte encamiñaría de volta polo mesmo camiño polo que veu. Sen axuda, esa busca aplica a túa política de túnel non marcada e conclúe que o paquete está na interface incorrecta.

A corrección pertence ao dono da firewall: garda a marca na conexión de saída, restáuraa nos paquetes entrantes correspondentes e activa o manexo de marcas validado pola fonte para a ruta relevante. Que OpenVPN estableza unha marca de socket non fai ningunha desas tres cousas, e unha receita que só enumera as opcións do cliente está incompleta. Pide esa integración por escrito, porque é a parte menos visible do deseño e a máis doada de perder nunha reconstrución.

A comprobación laxa da ruta de volta tampouco é un substituto. O modo laxo aínda necesita que exista algunha ruta para a fonte, e a garda unreachable que engadiches elimina deliberadamente unha para as buscas non marcadas. Fai que a integración da marca de conexión estea rematada e revisada antes de confiar neste deseño, e trata os filtros de host como unha cuestión aparte: unha marca é un sinal de encamiñamento, non un permiso. Se falta a integración, o síntoma é unha sesión que se establece e despois queda en silencio en canto comezan a chegar as respostas.

Demostra isto con dúas buscas de ruta

Compara o que decide o kernel para os dous contextos, e le os campos dev e src en vez do estado de saída:

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

A primeira busca debería resolver a tun1 coa fonte do túnel, e a segunda á conexión ascendente. Son buscas sintéticas, así que proban a política e non o proceso vivo: confirma a ruta de transporte real do cliente en execución por separado, e despois fai unha solicitude HTTPS real coa verificación de certificados activada.

Anota o que o deseño non cobre antes de declarárelo rematado. DNS, IPv6 e o ciclo de vida das regras precisan cada un a súa propia decisión, e isto é un exemplo de encamiñamento IPv4 en vez dunha configuración de privacidade completa. O seu valor é o selector: o sobre recibe a exención da conexión ascendente, e un servizo normal no mesmo enderezo non ten por que herdala.