Dúas direccións de servizo nun cliente OpenVPN: iroute e lo

A aplicación responde no seu enderezo de túnel, e o enderezo que documentou para ela non leva a ningures. Nada no rexistro de OpenVPN se queixa, o par aparece conectado e o concentrador lista exactamente un cliente. O oco é que un segundo enderezo nun cliente son dous feitos separados: o host debe posuílo e o concentrador debe saber que par o posúe. Resolva un sen o outro e o tráfico ou morre no concentrador ou chega sen ruta a casa.

O alias é local, a propiedade é remota

Un enderezo de túnel négase, así que ambos extremos o aprenden durante o handshake. Un enderezo de servizo adicional non se négase en absoluto, por iso engadilo non cambia nada no concentrador por si só. O cliente pode posuír o enderezo de inmediato e o servidor seguirá enviando ese tráfico pola súa ruta predeterminada ou descartarao. Hai que crear dous rexistros, en dous lugares distintos.

No cliente, o enderezo pertence ao host, e loopback é o fogar natural para unha identidade de servizo que nunca debería aparecer nunha ligazón física. No concentrador, a correspondencia de par a prefixo é unha declaración separada que só le o servidor. Ningún dos dous rexistros implica o outro.

Manteña os dous rangos distintos tamén nas súas notas. Os enderezos dun exemplo son valores de documentación, e solapalos cunha LAN real é a forma máis rápida de facer que unha configuración funcional pareza rota.

Engada o enderezo no cliente de forma persistente

Coloque o enderezo de servizo en loopback cun prefixo de host, para que o host o trate como entrada local e non como unha subrede á que chegar. ip address add 10.66.0.10/32 dev lo faino para un enderezo, e repetir o comando para un segundo enderezo modela dous servizos.

Execúteo como unha proba puntual e logo móvao ao que posúe a configuración de rede do host, porque unha adición en tempo de execución desaparece ao reiniciar e os duplicados acumúlanse entre reconexións. Unha unidade systemd ordenada despois da rede é unha opción, e un xestor de rede da distribución é outra. Escolla a que escolla, o enderezo debe existir antes de que a aplicación se ligue, ou o servizo aparece no socket equivocado. Verifique con ip address show dev lo despois dun reinicio e non despois do comando manual.

A ligazón é unha decisión separada do direccionamento. Unha aplicación que escoita en todos os enderezos acepta tráfico en interfaces que nunca pretendía, así que apúntea ao enderezo de servizo concreto. Entón a política de entrada local ten algo preciso con que coincidir.

Reclámeo no ficheiro CCD que o concentrador le de verdade

No servidor, a declaración de propiedade vai no ficheiro por cliente seleccionado polo nome común autenticado, dentro do directorio indicado por client-config-dir. A liña é iroute 10.66.0.10 255.255.255.255, unha por enderezo, e di ao servidor que par debe recibir o tráfico dese destino.

Dous detalles rompen isto en silencio. O nome do ficheiro debe coincidir co nome que o servidor usa realmente, que cambia cando username-as-common-name está en xogo. E iroute só ten efecto en modo TUN cun directorio de configuración de clientes configurado, así que a mesma liña non fai nada nun despregamento en ponte. Engada liñas ao ficheiro existente en lugar de substituílo, xa que pode levar un enderezo fixo ou opcións push. A referencia de OpenVPN 2.6 documenta tanto o directorio como a directiva de propiedade.

O propio núcleo do concentrador tamén necesita unha ruta a eses destinos para que o tráfico xerado localmente entre no proceso do túnel. route 10.66.0.10 255.255.255.255 na configuración do servidor cobre o tráfico que orixina o servidor, mentres que outros clientes necesitan push "route 10.66.0.10 255.255.255.255" para aprender o destino por si mesmos.

O encamiñamento e a autorización seguen separados. Unha ruta empurrada di a un cliente onde enviar paquetes e non concede nada; o servizo aínda ten que aceptar o chamante nos seus propios termos.

Comprobe a política de entrada e a ruta de resposta

Un paquete dirixido ao alias chega ao host propietario como entrada local, así que a pregunta é se o devasas local permite esa fonte e ese porto. Permita o porto de servizo concreto desde o rango de orixe da VPN en lugar de abrir todo o enderezo.

As respostas necesitan unha ruta de volta ao chamante. Para un chamante dentro do grupo de túnel normal esa ruta xa existe, porque a leva o dispositivo de túnel. Un chamante detrás doutra rede encamiñada necesita tamén a ruta de retorno desa rede, e aquí é onde as configuracións asimétricas perden paquetes.

Vixíe un segundo oínte no mesmo porto ligado a un enderezo distinto, porque o núcleo entrega ao socket que coincida e os resultados parecen aleatorios. Compruébeo con ss -lntp e confirme que o enderezo ligado é o alias do servizo. O NAT de orixe non é necesario aquí, e engadilo oculta a identidade do chamante da que dependen os seus rexistros.

Probe enderezos e propiedade por separado

Probe en dous pasos. Primeiro confirme que o host propietario pode alcanzar o servizo no seu alias desde si mesmo, o que separa os problemas de ligazón e devasas do encamiñamento. Logo probe desde un chamante VPN real usando a autenticación da propia aplicación. Cando o primeiro pasa e o segundo falla, a peza que falta está no lado do concentrador.

Comprobe tamén os modos de fallo que sobreviven a unha conexión: o alias segue asignado cando o túnel está caído, e o concentrador conserva a súa ruta cando o par está ausente. Ningún obxecto por si só demostra que o servizo sexa alcanzable, e por iso a proba en dous pasos supera un só ping desde un portátil.