Server și client OpenVPN pe același host: de ce cad clienții

Adăugați un profil de client pe o mașină care rulează deja un server VPN, iar serviciul original va fi prima victimă. Tunelul nou poate să nu se stabilească niciodată sau poate urca în timp ce clienții existenți ai serverului încetează în liniște să mai primească răspunsuri. Două coliziuni produc ambele rezultate: un pool de tuneluri deja folosit și o rută implicită instalată de jumătatea client nouă, care acoperă întreaga tabelă. Niciuna nu produce un mesaj de eroare OpenVPN, de aceea defecțiunea este citită ca problemă a serverului.

O mașină, două roluri și două răspunsuri incompatibile despre unde ar trebui să ajungă răspunsurile.

Același pool, două servere: care câștigă

Fiecare instanță de server are nevoie de propria subrețea de tunel. Copierea unei linii precum server 10.8.0.0 255.255.255.0 în a doua configurație le dă celor două instanțe același prefix, iar rezultatul este fie refuzul de a porni, fie o competiție tăcută în care clienții unui server primesc adrese pe care celălalt le consideră și el ale sale. Porturi UDP diferite și nume de dispozitiv diferite nu ajută, pentru că niciunul nu atinge spațiul de adrese. Schimbați al doilea pool și schimbați-l peste tot unde rutele îl menționează.

Enumerați ce este activ înainte de a edita: ip -4 addr show listează dispozitivele de tunel, ss -lunp listează ascultătorii, iar systemctl list-units numește unitățile. O privire la adresele tunelului decide dacă pool-urile se ciocnesc.

Ce adaugă profilul de client la tabelă

Jumătatea client scrie rute imediat ce se conectează. redirect-gateway def1 împarte ruta implicită în 0.0.0.0/1 plus 128.0.0.0/1, ambele rutate prin dispozitivul nou, împreună cu o rută de host către serverul îndepărtat, fixată în mod deliberat pe interfața fizică. Această fixare există pentru ca tunelul să păstreze o cale pentru propriul transport. Tot restul, inclusiv răspunsurile pe care serverul local le datorează propriilor clienți, urmează acum noua rută implicită și iese prin legătura îndepărtată.

Așadar a doua coliziune nu este un tunel stricat. Este un tunel funcțional în locul greșit din tabelă.

Trei moduri de a ține rolurile separate

Corecția cea mai puțin invazivă ține ruta implicită în afara profilului de client: route-nopull plus linii route explicite pentru prefixele îndepărtate, astfel încât tabela locală să se schimbe doar acolo unde ați cerut. Următorul pas este o regulă de politică ce exceptează subrețeaua de tunel locală, lăsând răspunsurile către clienții locali să iasă pe interfața pe care au sosit, chiar dacă există o rută implicită. Cea mai temeinică este un spațiu de nume de rețea separat pentru rolul de client, care elimină complet tabela partajată și costă un al doilea context de rutare de întreținut.

Indiferent de calea aleasă, excepția trebuie să numească subrețeaua de tunel locală, nu LAN-ul. Răspunsul trimis de serverul local are ca destinație o adresă de tunel, așa că o excepție în formă de LAN nu i se potrivește niciodată.

Care dintre cele două instanțe este vinovată

Opriți instanța client și retestați clienții originali. Recuperarea imediată înseamnă rutare, nu server. Readuceți clientul și urmăriți un singur răspuns cu ip route get căruia i se dau atât o adresă sursă, cât și una destinație, ceea ce arată calea pe care kernelul ar alege-o, apoi observați interfața pe care pachetele o folosesc cu adevărat cu tcpdump -ni any port 1194. Fișierul de stare al serverului, scris la fiecare câteva secunde prin directiva status, conține lista clienților conectați și contoarele de octeți în ambele direcții.

Citiți acele contoare unul față de celălalt. Traficul care pleacă și nu se întoarce niciodată este un răspuns de rutare, nu o problemă de handshake.