Como enviar só unha subrede privada pola VPN

Unha subrede privada polo túnel e todo o demais polo seu camiño habitual é unha petición pequena con moitísimas formas de saír mal. O resultado non o decide a casa chamada split tunneling, senón onde se aplica a decisión: a propia táboa de rutas do cliente, unha ruta que empuxa o servidor ou unha política que negocian os dous extremos. Escolla a capa equivocada e obterá ou un túnel completo que nunca quixo, ou unha ruta cara a un túnel que o outro extremo se nega a aceptar. Eu uso unha proba de tres condicións antes de abrir calquera configuración e logo escollo un dos mecanismos de abaixo.

Tres condicións que fixan o deseño

Primeiro, necesita o prefixo e a máscara exactos do propietario da rede. A rede 10.x non é un prefixo; 10.20.0.0/16 si o é. Confirme que non se solapa coa súa LAN doméstica, cunha ponte de Docker nin con outra VPN que execute, porque un solapamento volve ambigua a ruta e o núcleo escolle a entrada que vostede non pretendía.

Segundo, quen responde ao tráfico de volta. Encamiñar un paquete cara ao túnel só o leva ao servidor VPN. Se a subrede está detrás doutro router que non ten ruta de volta cara ao seu grupo de clientes, o servidor debe enmascarar o tráfico, ou ese router debe aprender o seu grupo. Ningunha ruta do lado do cliente arranxa un camiño de volta que falta.

Terceiro, o punto de aplicación. Algúns clientes instalan unha ruta e o sistema operativo fai o resto. Outros negocian unha política, e unha política que a pasarela non acepta non produce ningún túnel: os paquetes descártanse sen un erro evidente. Avereigüe cal dos dous é o seu antes de escribir nada.

WireGuard: AllowedIPs é a táboa de rutas

No cliente, AllowedIPs enumera os destinos que poden entrar no túnel, e wg-quick converte cada entrada nunha ruta ordinaria. Así que a metade cliente desta tarefa é unha soa liña.

[Peer]
PublicKey = ...
Endpoint = vpn.example.net:51820
AllowedIPs = 10.20.0.0/16

Agora compare a entrada do servidor para ese mesmo cliente. Describe o que o servidor enviará ao cliente, que normalmente é o enderezo de túnel do cliente, non a subrede privada.

[Peer]
PublicKey = ...
AllowedIPs = 10.99.0.2/32

Intercambiar esas dúas é o erro que vexo máis a miúdo. Poñer 10.20.0.0/16 baixo a sección peer do servidor afirma que toda a subrede vive detrás dese cliente, o cal é unha pretensión de sitio a sitio e non un permiso. Os paquetes que non coinciden co AllowedIPs de ningún peer descártanse en silencio, así que unha entrada errada parece exactamente un problema de devasas.

Se xestiona as rutas vostede mesmo, poña Table = off baixo [Interface] e engada a ruta que queira. Entón non se engade nada automaticamente, así que a ruta pertence ao que levanta a interface.

OpenVPN: empuxe a ruta e logo asegúrese de que chega

Nun servidor normal o cambio é unha directiva na configuración do servidor, xunto ao grupo de clientes.

push "route 10.20.0.0 255.255.0.0"

O cliente engádea cando se conecta. O modo de fallo aparece cando o mesmo perfil tamén empuxa redirect-gateway, ou cando alguén xa engadiu route-nopull: o primeiro converte a sesión nun túnel completo, e o segundo descarta todas as rutas empuxadas, incluída a súa.

Un cliente que necesita un comportamento estreito contra un servidor de túnel completo debería ignorar só as partes que non quere. En OpenVPN 2.4 e posteriores, pull-filter existe precisamente para iso.

pull-filter ignore "redirect-gateway"
route 10.20.0.0 255.255.0.0

Manteña as familias de enderezos separadas: unha ruta IPv4 empuxada non fai nada por un servizo interno que se resolve a IPv6, e ese servizo falla polo túnel mentres todo o demais parece correcto.

Cando a subrede privada non está no servidor VPN senón detrás doutro cliente, hai que avisar o servidor. Engada un ficheiro por cliente mediante client-config-dir que conteña iroute 10.20.0.0 255.255.0.0, máis a route correspondente para que os demais clientes aprendan o camiño. Sen iroute o servidor non ten motivo para enviar ese prefixo por ese túnel concreto.

IPsec: os selectores de tráfico teñen que poñerse de acordo

Con IPsec non hai ruta que empuxar. Os dous extremos negocian que enderezos viven dentro do túnel, e o tráfico fóra dos selectores acordados nin se cifra nin se envía por el. Nun cliente strongSwan os selectores son explícitos.

leftsubnet=192.168.1.0/24
rightsubnet=10.20.0.0/16

Se a pasarela está configurada con 0.0.0.0/0 nos dous lados, o estreitamento de IKEv2 adoita reducir a SA filla á intersección das dúas propostas, que é o resultado que vostede quere. Algunhas pasarelas, en cambio, rexeitan unha proposta que non coincide cos seus selectores configurados, e o rexistro mostra entón unha SA filla fallida en lugar dunha queixa de encamiñamento. Cando iso ocorre, o cambio corresponde á pasarela, porque unha ruta no cliente non pode crear un túnel para un selector que o outro lado non aceptará.

En Windows o cliente integrado esconde a mesma decisión detrás de dous axustes. A división do túnel debe estar activada, e o prefixo debe rexistrarse no perfil.

Set-VpnConnection -Name Office -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.20.0.0/16

Rexistrar o prefixo é o que o fai sobrevivir a unha reconexión, cousa que unha ruta engadida a man non fai.

Manteña o extremo e o DNS fóra da decisión

O extremo da VPN debe seguir sendo accesible sen o túnel, ou o túnel derrúbase sobre si mesmo. Cando só se encamiña 10.20.0.0/16 iso é automático, xa que o extremo é un enderezo público. Nun perfil de túnel completo non o é, e o cliente necesita unha ruta de host explícita cara ao extremo antes de que suba o túnel.

O DNS é unha segunda decisión que o empuxe de rutas non toma por vostede. Os nomes internos adoitan resolverse mediante un resolutor ao que só pode chegar a rede privada. Se o servidor empuxa un servidor DNS, cada nome pasa por el; se non o fai, os nomes internos ou fallan ou se resolven publicamente a algo que vostede non pretendía. O DNS dividido mantén un dominio de busca no resolutor interno, pero depende do soporte do cliente, así que tráteo como unha tarefa propia e non como un efecto secundario do encamiñamento.

Verifique, reinicie e volva verificar

Tres probas cobren a cuestión do encamiñamento. Pregunte ao núcleo a onde iría un enderezo remoto, descargue algo desde dentro da subrede e logo confirme que unha petición pública ordinaria segue saíndo pola súa conexión normal.

ip route get 10.20.5.7
curl -sS http://10.20.5.7/health
curl -sS https://ifconfig.me

A primeira liña nomea unha interface. Se nomea a súa interface física, a ruta nunca chegou. En Windows, Find-NetRoute -RemoteIPAddress 10.20.5.7 responde á mesma pregunta, e a última proba debería seguir mostrando o seu enderezo habitual e non o do servidor VPN.

Despois reinicie. As rutas engadidas a man desaparecen, mentres que as rutas do perfil, dunha configuración empuxada ou de AllowedIPs volven. Se o acceso estreito funciona antes do reinicio e falla despois, o fallo está en como arrinca o túnel, non na ruta mesma.

Antes de dalo por terminado, confirme catro cousas: o prefixo veu do propietario da rede e non se solapa con nada local, o camiño de volta existe ou unha regra de enmascaramento o substitúe, o mecanismo que configurou é o que aplica o encamiñamento na súa plataforma, e as mesmas probas pasan tras un reinicio limpo. As notas de reenvío de strongSwan merecen unha lectura se o camiño de volta é a parte que non deixa de fallar.