Un Pi, dues instàncies d’OpenVPN: què llegeix cada unitat

Compteu els processos OpenVPN abans de tocar cap perfil. Un Pi que admet usuaris itinerants i també es connecta a un servei superior executa dos dimonis, i cadascun llegeix un fitxer de configuració triat pel nom d’instància que heu escrit. Després, les plantilles empaquetades donen a cada dimoni el seu propi directori de treball, el seu propi fitxer d’estat d’execució i el seu propi dispositiu de túnel. Si us equivoqueu en aquesta separació, passareu una nit canviant un paràmetre correcte dins d’un fitxer que el procés en marxa no obre mai.

Cada nom d’instància tria el seu propi fitxer

Als fitxers d’unitat que es distribueixen amb OpenVPN 2.6, els arguments d’inici porten un marcador de posició d’instància que s’omple amb el text que hi ha després del signe @. La plantilla del servidor s’executa des del directori de configuració del servidor i resol el seu argument contra %i.conf allà, mentre que la plantilla del client fa el mateix des del directori del client. Així, [email protected] llegeix admits.conf al directori del servidor i [email protected] llegeix uplink.conf al directori del client, i cap dels dos noms no té cap significat a l’altre directori.

Confirmeu la correspondència a la mateixa màquina en lloc de suposar que el paquet ha conservat els valors per defecte. Una excepció de la distribució pot substituir directament el directori de treball o l’argument de configuració.

systemctl cat [email protected]
systemctl cat [email protected]

Llegiu la línia WorkingDirectory i l’argument de configuració d’aquesta sortida, perquè la unitat habilitada és l’única cosa que decideix quin fitxer es carrega. Una excepció que afegeix --config a ExecStart guanya la plantilla fins i tot quan el camí de la plantilla sembla correcte. Demaneu els camins del fragment i de l’excepció quan vulgueu saber si hi ha una substitució local en joc. Si tots dos rols es resolen en un sol fitxer, teniu un sol procés que intenta ser servidor i client, i l’opció posterior d’aquest fitxer guanya en silenci.

El transport local i la càrrega reenviada toquen ganxos diferents

La connexió xifrada del servidor amb cada usuari itinerant es genera al mateix Pi, de manera que les seves respostes exteriors surten pel ganxo de sortida local. La connexió del client amb el seu parell superior també és una sortida generada localment, encara que arriba a una xarxa remota. La càrrega reenviada és una tercera categoria, i el nucli només la fa coincidir després d’haver triat ja un dispositiu de sortida per al paquet.

Una regla que coincideix amb una interfície de sortida dins d’una cadena de reenviament pot permetre o descartar un paquet que l’encaminament ja ha assignat a aquesta interfície, però mai no tria la interfície. Quan un amfitrió acaba un túnel i n’origina un altre, la política que envia la càrrega d’usuari al túnel superior i la política que protegeix les respostes xifrades del Pi són decisions separades. Casualment aterren a la mateixa targeta de xarxa física, i per això es confonen.

Aquesta distinció explica un mig fracàs habitual. Els usuaris es connecten, l’apretada de mà es completa i el seu trànsit continua sortint pel camí equivocat, perquè l’apretada de mà era local i la càrrega era reenviada, i només se n’havia provat una de les dues.

Una ruta importada pot empassar-se les respostes als vostres usuaris

El paràmetre de seguretat del perfil del client decideix què pot empènyer l’extrem superior a la taula d’encaminament del Pi, i una redirecció àmplia és l’opció que converteix un amfitrió de doble rol que funciona en un de trencat. Si la ruta empesa cobreix les adreces públiques dels usuaris itinerants, les respostes que el servidor genera cap a ells poden seguir la ruta nova cap al túnel superior en lloc de sortir per la capa base. La gent sovint confirma que el túnel cap al proveïdor encara funciona i s’atura aquí, perquè aquest trànsit és el transport propi del túnel i continua fluint mentre tota la resta es comporta malament.

La política basada en l’origen o en una marca és com es mantenen separats els dos fluxos. L’opció de marca de Linux d’OpenVPN marca els paquets xifrats propis del dimoni amb una marca de tallafoc, que una regla d’encaminament pot enviar després a una taula dedicada. Les adreces d’origen funcionen igual de bé quan les respostes exteriors del servidor sempre surten d’una única adreça de capa base. Qualsevol dels dos enfocaments necessita rutes vàlides a la taula que tria i una excepció per al punt final del proveïdor, o el túnel mateix deixa de pujar.

Pregunteu al nucli quin camí prendria realment una resposta abans d’escriure cap regla. Les adreces següents són marcadors de posició per a una adreça de capa base del Pi i l’adreça pública d’un usuari itinerant.

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Verifiqueu la separació i després atureu un rol alhora

Proveu tres fluxos per separat, perquè una apretada de mà que funciona no demostra res sobre els altres dos. Accepteu una connexió entrant nova, envieu una aplicació permesa per la sortida superior i confirmeu que tots dos processos encara arriben als seus parells.

Després atureu el rol de client i observeu què conserva el rol de servidor. Aquesta és la manera més barata de trobar una ruta o una regla de marca que es va pensar per a una instància i es va aplicar a totes dues.

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

El que voleu veure és l’oient encara lligat, el dispositiu de túnel encara present i el registre lliure d’errors nous mentre el rol de client està aturat. Si aturar el client també talla les respostes del servidor als usuaris existents, els dos rols comparteixen alguna cosa que hauria d’haver estat limitada a un d’ells. Anoteu quina instància, quin fitxer de configuració i quin propietari de flux va tocar cada canvi, perquè la propera persona que depuri aquest amfitrió, si no, repetirà la mateixa descoberta des de zero.