Dos clients OpenVPN en un sol amfitrió Linux: qui posseeix la ruta?

Tots dos perfils informen que estan connectats i un d’ells porta silenciosament trànsit destinat a l’altre. Dos clients en un sol amfitrió és una disposició admesa; dos clients sense propietari per a cada prefix no ho és. La feina tracta menys de pujar el segon túnel i més de decidir quin procés pot reclamar quina ruta. Seguiu l’ordre de sota i la configuració es desprèn de les respostes.

Comenceu preguntant per a què serveix el segon túnel

Tres situacions semblen idèntiques a la línia d’estat i necessiten dissenys diferents. La divisió per destinacions envia un prefix pel perfil d’oficina i un altre pel perfil de laboratori, sense que cap reclami una ruta per defecte. La divisió per aplicació normalment manté un túnel complet i dirigeix trànsit concret amb regles de política. La commutació per error manté exactament un túnel actiu alhora, cosa que significa que el segon no s’ha d’iniciar automàticament.

Escriviu el cas abans d’obrir qualsevol fitxer de configuració, perquè aquesta resposta decideix tot el que ve després.

La disposició trencada més habitual són dos túnels complets que tots dos han empès una ruta per defecte, on guanya el qui es va connectar últim i el primer continua fent veure. Aquest estat sembla intencionat des de la línia d’estat i malbarata un dia de la taula d’encaminament. Anomenar el cas primer el fa impossible, no només improbable.

Mireu els pools abans que les rutes

Dos servidors poden repartir fàcilment adreces d’un sol rang privat, i quan ho fan, el client acaba amb dues interfícies dins d’un sol prefix. Llavors cap destinació no es pot atribuir a una interfície per adreça, perquè totes dues semblen igual de correctes. Renombreu un pool en lloc d’inventar una regla per desfer l’empat.

Comproveu també la xarxa local, perquè una LAN de casa o d’oficina que se superposi amb un rang de túnel crea la mateixa ambigüitat des de l’altre costat. Compareu les adreces de l’amfitrió amb les dues configuracions de servidor abans de culpar el client. Un canvi de pool en un servidor de laboratori és una correcció de cinc minuts, mentre que una solució d’encaminament per política per a un prefix superposat és un impost permanent per a tothom qui llegeixi la configuració després. Decidiu quin dels dos voleu abans de triar on intervenir.

Dues famílies d’adreces volen dir dues rondes d’aquesta comprovació. Els pools IPv6 xoquen tan silenciosament com els IPv4.

Doneu a cada perfil un propietari

Una instància per perfil, un fitxer de configuració per instància i un nom que identifiqui la parella. En l’empaquetament a l’estil Debian, el nom després del signe @ selecciona el fitxer, i per això dos perfils que comparteixen un nom d’instància mai no poden funcionar tots dos. Confirmeu la correspondència des de la unitat instal·lada, no des d’un tutorial.

systemctl cat [email protected]
ip -4 addr show

Després decidiu qui instal·la les rutes, que és una qüestió de política i no de sintaxi.

Quan els dos servidors empenyin conjunts incompatibles, o bé afegiu route-nopull i llisteu només els prefixos que cada perfil necessita, o bé deixeu que un conservi la seva ruta per defecte i dirigiu la resta amb una regla de política. Dos processos que tots dos instal·len una ruta per defecte acaben amb un sol guanyador i ningú no pot dir per què. Quan els dos túnels porten trànsit de fonts diferents, una resposta pot sortir pel túnel equivocat, i el patró que aguanta és una marca de connexió restaurada a les respostes i dirigida a la seva pròpia taula. Limiteu les marques perquè els paquets xifrats propis dels túnels no hi coincideixin mai.

Verifiqueu per túnel, després atureu-ne un

Quan tots dos són actius, preneu tres lectures: l’adreça de cada dispositiu de túnel, la ruta cap a un amfitrió que visqui darrere de cadascun i el camí que prendria una destinació fora de tots dos. Un llistat de rutes corrent deixa de descriure la consulta final tan bon punt hi entren regles, així que pregunteu al nucli què triaria realment. Després atureu una instància i mireu què desapareix. Si aturar la primera pertorba la segona, encara hi ha alguna cosa compartida entre elles: una ruta, un nom de dispositiu o una regla de tallafoc que ningú no ha separat.

ip rule show
ip route get 203.0.113.9

Torneu a aixecar el perfil aturat i repetiu les mateixes comprovacions, perquè un túnel que funciona un cop després d’un reinici i mai més és un error de cicle de vida disfressat d’encaminament.

Anoteu a les notes de desplegament quin perfil posseeix quin prefix, al costat dels rangs de pools. Dos túnels són una disposició deliberada, i el proper lector necessita veure la frontera abans de tocar qualsevol perfil. Sense aquesta nota, la frontera la redescobreix qui estigui de guàrdia quan el prefix compartit finalment es trenqui.