Două tuneluri OpenVPN pe un singur host Linux: a cui este ruta?

Două profiluri sunt conectate, iar unul dintre ele transportă în tăcere trafic destinat celuilalt. Un host Linux poate rula ambele OpenVPN clienți simultan fără dificultate. Ce nu poate face este să decidă în locul dumneavoastră ce proces poate revendica ce prefix. Această decizie trebuie luată înainte ca al doilea tunel să urce, nu după ce o resursă nu mai răspunde.

Începeți cu munca pe care trebuie să o facă a doua legătură

Un birou accesibil printr-un profil și un laborator accesibil prin altul au nevoie de ambele tuneluri sus și de niciunul care să revendice totul. O singură aplicație încăpățânată care trebuie să iasă prin al doilea profil are nevoie de o regulă de politică, nu de o a doua rută implicită. O legătură de rezervă are nevoie de un singur tunel activ o dată, așa că rezerva nu ar trebui să pornească împreună cu mașina.

Sunt trei configurații diferite și se confundă pentru că toate trei încep la fel: un al doilea profil și o conexiune reușită. Scrieți mai întâi aranjamentul dorit, apoi configurați spre el. O propoziție despre intenție economisește o oră de captură de pachete.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Prima comandă listează instanțele care rulează, inclusiv cele pornite manual din afara managerului. A doua afișează revendicarea implicită curentă, adică starea pe care va trebui să o explicați mai târziu.

Pool-urile suprapuse se strică înainte de rutare

Două servere vor aloca bucuros adrese din același 10.8.0.0/24. Clientul ține atunci două interfețe într-un singur prefix fără nimic care să spună care destinație aparține căreia, iar comportamentul rezultat pare o defecțiune de rutare, dar este de fapt o defecțiune de numerotare. Renumerotarea unui pool costă o editare de configurație; fiecare ocol de rutare ulterior costă un weekend. Verificați pool-ul înainte de a adăuga o rută pentru el.

Uitați-vă și la LAN-ul local. Un LAN de acasă numerotat 192.168.1.0/24 pe care un tunel îl expune și el produce aceeași ambiguitate, iar simptomul este un nume de gazdă care se rezolvă în timp ce conexiunea nu se finalizează niciodată. Asta pare o defecțiune de rezolvare a numelor până când afișați rutele.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Comparați ambele ieșiri cu cele două configurații de server înainte de a atinge clientul. Dacă prefixele se suprapun, opriți-vă și renumerotați, pentru că nicio cantitate de reporniri nu le va separa.

Dați fiecărui profil unitatea lui și fiecărui prefix un proprietar

Fiecare profil primește propriul nume de instanță și propriul fișier de configurare, așa că instanța numită office încarcă office.conf, iar cea numită lab încarcă lab.conf. Confirmați această mapare prin managerul de servicii în loc să vă bazați pe o listare de director, deoarece un drop-in poate schimba ce fișier este încărcat. O mapare greșită înseamnă că reglați profilul care nu rulează.

Apoi stabiliți cine instalează rutele. Când serverele împing seturi incompatibile, fie refuzați împingerea și listați prefixele singur, fie lăsați un profil să păstreze implicitul și direcționați celălalt cu reguli de politică. Două procese care instalează amândouă un implicit ajung cu un câștigător tăcut și fără nicio înregistrare scrisă a deciziei.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Prima arată unitatea cu orice suprascriere care îi schimbă argumentele. A doua arată dacă profilul acceptă deloc rutele împinse, iar acesta este comutatorul care decide tot ce urmează.

Marcajele țin răspunsurile pe interfața de unde au venit

Când fiecare tunel deservește surse diferite, un răspuns poate ieși pe legătura greșită și conexiunea moare după primul pachet. Modelul care rezistă este să marcați pachetele care sosesc după interfața de intrare, să restabiliți marca pe răspuns și să dați fiecărei mărci un tabel cu propria poartă implicită.

Filtrarea laxă a căii inverse trebuie de obicei relaxată pentru interfețele afectate, pentru că un răspuns sosește legitim pe o legătură pe care tabelul principal nu ar alege-o niciodată. Țineți marcile înguste ca să nu prindă niciodată traficul criptat al tunelurilor înseși, ceea ce ar trimite tunelul prin el însuși.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Citiți regulile existente înainte de a adăuga una nouă. Prioritățile duplicate și tabelele uitate sunt motivul obișnuit pentru care o politică de marcaje pare să nu aibă niciun efect.

Dovediți izolarea oprind o legătură

Cu ambele tuneluri sus, notați adresa fiecărei interfețe, ruta către o gazdă din spatele fiecărui tunel și calea pe care o ia o destinație nelegată. Cereți nucleului căutarea în loc să citiți un singur tabel, pentru că un tabel nu arată niciodată decizia finală.

Apoi opriți o instanță și urmăriți cum interfața și rutele ei dispar în timp ce cealaltă continuă. O ruptură la supraviețuitoare înseamnă că cele două încă împart un nume de dispozitiv, o rută sau o regulă de firewall pe care nimeni nu le-a separat.

Aduceți înapoi profilul oprit și repetați aceleași verificări. Când un tunel supraviețuiește doar prima pornire după o repornire, vedeți un defect de ciclu de viață, nu un proiect de rutare.