Servidor i client OpenVPN en un sol host: per què cauen els clients

Afegiu un perfil de client a una màquina que ja executa un servidor VPN i el primer damnificat serà el servei original. El túnel nou pot no arribar a establir-se mai, o pot aixecar-se mentre els clients existents del servidor deixen de rebre respostes sense fer soroll. Dues col·lisions produeixen tots dos resultats: una bassa de túnels que ja és en ús i una ruta per defecte instal·lada per la meitat client nova que cobreix tota la taula. Cap de les dues no genera cap missatge d'error d'OpenVPN, i per això la fallada es llegeix com un problema del servidor.

Una màquina, dos rols i dues respostes incompatibles sobre on han d'anar les respostes.

Mateixa bassa, dos servidors: qui guanya

Cada instància de servidor necessita una subxarxa de túnel pròpia. Copiar una línia com server 10.8.0.0 255.255.255.0 a la segona configuració dóna a les dues instàncies el mateix prefix, i el resultat és o bé una negativa a arrencar o bé una competició silenciosa en què els clients d'un servidor reben adreces que l'altre també creu seves. Ports UDP diferents i noms de dispositiu diferents no ajuden, perquè cap dels dos no toca l'espai d'adreces. Canvieu la segona bassa i canvieu-la a tot arreu on les rutes la esmenten.

Enumerem què hi ha actiu abans d'editar: ip -4 addr show llista els dispositius de túnel, ss -lunp llista els oients i systemctl list-units anomena les unitats. Una ullada a les adreces del túnel decideix si les basses xoquen.

Què afegeix el perfil de client a la taula

La meitat client escriu rutes tan bon punt es connecta. redirect-gateway def1 parteix la ruta per defecte en 0.0.0.0/1 més 128.0.0.0/1, totes dues encaminades pel dispositiu nou, juntament amb una ruta d'host cap al servidor remot que està deliberadament fixada a la interfície física. Aquesta fixació existeix perquè el túnel conservi un camí per al seu propi transport. Tota la resta, incloses les respostes que el servidor local deu als seus propis clients, ara segueix la ruta per defecte nova i surt per l'enllaç remot.

Així doncs, la segona col·lisió no és un túnel trencat. És un túnel que funciona en el lloc equivocat de la taula.

Tres maneres de mantenir els rols separats

La solució menys invasiva manté la ruta per defecte fora del perfil de client: route-nopull més línies explícites route per als prefixos remots, de manera que la taula local només canvia on ho heu demanat. El pas següent és una regla de política que eximeix la subxarxa de túnel local, deixant que les respostes als clients locals surtin per la interfície per la qual van arribar fins i tot quan hi ha una ruta per defecte. La més exhaustiva és un espai de noms de xarxa separat per al rol de client, que elimina del tot la taula compartida i costa un segon context d'encaminament de mantenir.

Prengueu el camí que prengueu, l'excepció ha de nomenar la subxarxa de túnel local i no la LAN. La resposta que envia el servidor local té com a destinació una adreça de túnel, així que una excepció amb forma de LAN no hi encaixa mai.

Quina de les dues instàncies té la culpa

Atureu la instància client i torneu a provar els clients originals. Una recuperació immediata vol dir encaminament, no servidor. Torneu a aixecar el client i resseguiu una sola resposta amb ip route get a qui s'han donat tant una adreça d'origen com de destinació, cosa que mostra el camí que triaria el nucli, i després observeu la interfície que els paquets fan servir realment amb tcpdump -ni any port 1194. El fitxer d'estat del servidor, escrit cada pocs segons mitjançant la directiva status, conté la llista de clients connectats i comptadors de bytes en tots dos sentits.

Llegiu aquests comptadors l'un contra l'altre. El trànsit que surt i no torna mai és una resposta d'encaminament, no un problema de handshake.