Doi clienți OpenVPN pe un singur host Linux: al cui este traseul?

Ambele profiluri raportează conectarea și unul dintre ele transportă în tăcere trafic destinat celuilalt. Doi clienți pe un singur host este o configurație acceptată; doi clienți fără proprietar pentru fiecare prefix nu este. Munca ține mai puțin de ridicarea celui de-al doilea tunel și mai mult de decizia privind procesul care poate revendica ce rută. Urmați ordinea de mai jos și configurația decurge din răspunsuri.

Începeți prin a întreba pentru ce este al doilea tunel

Trei situații arată identic pe linia de stare și necesită proiecte diferite. O împărțire pe destinații trimite un prefix prin profilul de birou și altul prin profilul de laborator, fără ca vreunul să revendice o rută implicită. O împărțire pe aplicație păstrează de obicei un tunel complet și direcționează trafic anume cu reguli de politică. Comutarea la eșec menține activ exact un singur tunel odată, ceea ce înseamnă că al doilea nu trebuie să pornească automat.

Scrieți cazul înainte de a deschide orice fișier de configurare, pentru că acel răspuns decide tot ce urmează.

Cea mai frecventă configurație stricată este două tuneluri complete care au împins amândouă o rută implicită, unde câștigă cel care s-a conectat ultimul, iar primul continuă să se prefacă. Acea stare pare intenționată de pe linia de stare și irosește o zi din tabela de rutare. Dacă numiți cazul mai întâi, el devine imposibil, nu doar improbabil.

Uitați-vă la pooluri înaintea rutelor

Două servere pot distribui cu ușurință adrese dintr-un singur interval privat, iar când o fac, clientul ajunge cu două interfețe într-un singur prefix. Nicio destinație nu mai poate fi atribuită unei interfețe după adresă, pentru că ambele par la fel de corecte. Renumărați un pool în loc să inventați o regulă pentru a rupe egalitatea.

Verificați și rețeaua locală, pentru că o LAN de acasă sau de birou care se suprapune cu un interval de tunel creează aceeași ambiguitate din cealaltă parte. Comparați adresele de pe host cu ambele configurații de server înainte de a da vina pe client. O schimbare de pool pe un server de laborator este o corectare de cinci minute, în timp ce o soluție de rutare pe politică pentru un prefix suprapus este o taxă permanentă pentru oricine citește configurația mai târziu. Decideți care dintre cele două o doriți înainte de a alege unde să interveniți.

Două familii de adrese înseamnă două runde ale acestei verificări. Poolurile IPv6 se ciocnesc la fel de tăcut ca IPv4.

Dați fiecărui profil un proprietar

O instanță pe profil, un fișier de configurare pe instanță și un nume care identifică perechea. În împachetarea în stil Debian, numele de după semnul @ selectează fișierul, motiv pentru care două profiluri care împart un nume de instanță nu pot funcționa niciodată amândouă. Confirmați maparea din unitatea instalată, nu dintr-un tutorial.

systemctl cat [email protected]
ip -4 addr show

Apoi decideți cine instalează rutele, ceea ce este o chestiune de politică, nu de sintaxă.

Când cele două servere împing seturi incompatibile, fie adăugați route-nopull și enumerați doar prefixele de care are nevoie fiecare profil, fie lăsați unul să-și păstreze ruta implicită și direcționați restul cu o regulă de politică. Două procese care instalează amândouă o rută implicită ajung cu un singur câștigător și nimeni nu poate spune de ce. Odată ce cele două tuneluri transportă trafic pentru surse diferite, un răspuns poate ieși prin cel greșit, iar modelul care rezistă este o marcă de conexiune restaurată pe răspunsuri și direcționată în propria tabelă. Limitați mărcile astfel încât pachetele criptate ale tunelurilor înseși să nu se potrivească niciodată cu ele.

Verificați pe tunel, apoi opriți unul

Când amândouă sunt sus, luați trei citiri: adresa de pe fiecare dispozitiv de tunel, ruta către un host care trăiește în spatele fiecăruia și drumul pe care l-ar lua o destinație din afara ambelor. O listă obișnuită de rute încetează să descrie căutarea finală de îndată ce regulile intră în joc, așa că întrebați nucleul ce ar alege de fapt. Apoi opriți o instanță și urmăriți ce dispare. Dacă oprirea primei o deranjează pe a doua, ceva este încă partajat între ele: o rută, un nume de dispozitiv sau o regulă de firewall pe care nimeni nu a separat-o.

ip rule show
ip route get 203.0.113.9

Readuceți profilul oprit și repetați aceleași verificări, pentru că un tunel care funcționează o dată după o repornire și niciodată altă dată este o eroare de ciclu de viață în costum de rutare.

Notați în notele de implementare ce profil deține ce prefix, lângă intervalele poolurilor. Două tuneluri sunt o configurație deliberată, iar următorul cititor trebuie să vadă granița înainte de a atinge vreun profil. Fără acea notă, granița este redescoperită de cel care este de serviciu când prefixul partajat se rupe în cele din urmă.