Dues adreces de servei en un sol client OpenVPN: iroute i lo

L’aplicació respon a la seva adreça de túnel, i l’adreça que heu documentat per a ella no va enlloc. Res al registre d’OpenVPN es queixa, el parell es mostra connectat i el concentrador llista exactament un client. El buit és que una segona adreça en un client són dos fets separats: l’amfitrió l’ha de posseir, i el concentrador ha de saber quin parell la posseeix. Resoleu-ne un sense l’altre i el trànsit o mor al concentrador o arriba sense ruta a casa.

L’àlies és local, la propietat és remota

L’adreça del túnel es negocia, així que els dos extrems la coneixen durant l’encaixada de mans. Una adreça de servei addicional no es negocia gens, i per això afegir-la no canvia res al concentrador per si sola. El client pot posseir l’adreça immediatament i el servidor encara enviarà aquest trànsit al seu camí per defecte o el descartarà. Cal crear dos registres, en dos llocs diferents.

Al client, l’adreça pertany a l’amfitrió, i loopback és la llar natural per a una identitat de servei que no hauria d’aparèixer mai en un enllaç físic. Al concentrador, la correspondència de parell a prefix és una declaració separada que només llegeix el servidor. Cap registre no implica l’altre.

Mantingueu els dos rangs separats també a les vostres notes. Les adreces d’un exemple són valors de documentació, i superposar-les amb una LAN real és la manera més ràpida de fer que una configuració funcional sembli trencada.

Afegiu l’adreça al client de manera persistent

Col·loqueu l’adreça de servei a loopback amb un prefix d’amfitrió, perquè l’amfitrió la tracti com a entrada local i no com una subxarxa a la qual arribar. ip address add 10.66.0.10/32 dev lo ho fa per a una adreça, i repetir l’ordre per a una segona adreça modela dos serveis.

Executeu-ho com una prova puntual i després moveu-ho al que posseeix la configuració de xarxa de l’amfitrió, perquè una addició en temps d’execució desapareix en reiniciar i els duplicats s’acumulen entre reconnexions. Una unitat systemd ordenada després de la xarxa és una opció, i un gestor de xarxa de la distribució és una altra. Triïu el que triïu, l’adreça ha d’existir abans que l’aplicació s’hi vinculi, o el servei apareix al sòcol equivocat. Verifiqueu-ho amb ip address show dev lo després d’un reinici i no després de l’ordre manual.

La vinculació és una decisió separada de l’adreçament. Una aplicació que escolta a totes les adreces accepta trànsit en interfícies que no havíeu previst, així que apunteu-la a l’adreça de servei concreta. Aleshores la política d’entrada local té alguna cosa precisa amb què coincidir.

Reclameu-la al fitxer CCD que el concentrador llegeix de veritat

Al servidor, la declaració de propietat va al fitxer per client seleccionat pel nom comú autenticat, dins del directori indicat per client-config-dir. La línia és iroute 10.66.0.10 255.255.255.255, una per adreça, i diu al servidor quin parell ha de rebre el trànsit per a aquesta destinació.

Dos detalls ho trenquen en silenci. El nom del fitxer ha de coincidir amb el nom que el servidor fa servir realment, que canvia quan hi ha username-as-common-name en joc. I iroute només té efecte en mode TUN amb un directori de configuració de clients configurat, així que la mateixa línia no fa res en un desplegament en pont. Afegiu línies al fitxer existent en lloc de substituir-lo, perquè ja pot portar una adreça fixa o opcions push. La referència d’OpenVPN 2.6 documenta tant el directori com la directiva de propietat.

El nucli propi del concentrador també necessita un camí cap a aquestes destinacions perquè el trànsit generat localment entri al procés del túnel. route 10.66.0.10 255.255.255.255 a la configuració del servidor cobreix el trànsit que origina el servidor, mentre que els altres clients necessiten push "route 10.66.0.10 255.255.255.255" per aprendre la destinació ells mateixos.

L’encaminament i l’autorització continuen separats. Una ruta emesa diu a un client on enviar paquets i no concedeix res; el servei encara ha d’acceptar el sol·licitant segons les seves condicions.

Comproveu la política d’entrada i el camí de resposta

Un paquet adreçat a l’àlies arriba a l’amfitrió propietari com a entrada local, així que la pregunta és si el tallafoc local permet aquesta font i port. Permeteu el port de servei concret des del rang d’origen de la VPN en lloc d’obrir tota l’adreça.

Les respostes necessiten un camí de tornada cap al sol·licitant. Per a un sol·licitant dins del pool de túnel normal aquest camí ja existeix, perquè el dispositiu de túnel el transporta. Un sol·licitant darrere d’una altra xarxa encaminada necessita també la ruta de retorn d’aquesta xarxa, i és aquí on les configuracions asimètriques perden paquets.

Vigileu un segon oient al mateix port lligat a una adreça diferent, perquè el nucli lliura al sòcol que coincideixi i els resultats semblen aleatoris. Comproveu-ho amb ss -lntp i confirmeu que l’adreça lligada és l’àlies del servei. Aquí no cal NAT d’origen, i afegir-lo amaga la identitat del sol·licitant de la qual depenen els vostres registres.

Proveu adreces i propietat per separat

Proveu-ho en dos passos. Primer confirmeu que l’amfitrió propietari pot arribar al servei al seu àlies des de si mateix, cosa que separa els problemes de vinculació i tallafoc de l’encaminament. Després proveu-ho des d’un sol·licitant VPN real amb l’autenticació pròpia de l’aplicació. Quan el primer passa i el segon falla, la peça que falta és al costat del concentrador.

Comproveu també els modes de fallada que sobreviuen a una connexió: l’àlies continua assignat quan el túnel està caigut, i el concentrador conserva la seva ruta quan el parell és absent. Cap objecte sol no demostra que el servei sigui abastable, i per això la prova en dos passos supera un sol ping des d’un portàtil.