Două adrese de serviciu pe un singur client OpenVPN: iroute și lo

Aplicația răspunde pe adresa sa de tunel, iar adresa pe care ați documentat-o pentru ea nu duce nicăieri. Nimic din jurnalul OpenVPN nu se plânge, partenerul apare conectat și hubul listează exact un client. Golul este că o a doua adresă pe un client sunt două fapte separate: gazda trebuie să o dețină, iar hubul trebuie să știe ce partener o deține. Rezolvați una fără cealaltă și traficul fie moare la hub, fie ajunge fără rută spre casă.

Aliasul este local, proprietatea este la distanță

O adresă de tunel se negociază, așa că ambele capete o învață în timpul strângerii de mână. O adresă suplimentară de serviciu nu se negociază deloc, de aceea adăugarea ei nu schimbă nimic la hub în sine. Clientul poate deține adresa imediat, iar serverul va trimite în continuare acel trafic pe calea sa implicită sau îl va arunca. Trebuie create două înregistrări, în două locuri diferite.

La client, adresa aparține gazdei, iar loopback este casa naturală pentru o identitate de serviciu care nu ar trebui să apară niciodată pe o legătură fizică. La hub, maparea partenerului la prefix este o declarație separată pe care o citește doar serverul. Niciuna dintre înregistrări nu o implică pe cealaltă.

Păstrați cele două intervale separate și în notele dumneavoastră. Adresele dintr-un exemplu sunt valori de documentare, iar suprapunerea lor cu un LAN real este cea mai rapidă cale de a face o configurație funcțională să pară stricată.

Adăugați adresa pe client în mod persistent

Puneți adresa de serviciu pe loopback cu un prefix de gazdă, astfel încât gazda să o trateze ca intrare locală și nu ca o subrețea de atins. ip address add 10.66.0.10/32 dev lo face asta pentru o adresă, iar repetarea comenzii pentru o a doua adresă modelează două servicii.

Rulați asta ca test unic, apoi mutați-o în ceea ce deține configurația de rețea a gazdei, deoarece o adăugare la rulare dispare la repornire, iar duplicatele se acumulează între reconectări. O unitate systemd ordonată după rețea este o opțiune, iar un manager de rețea al distribuției este alta. Orice ați alege, adresa trebuie să existe înainte ca aplicația să se lege, altfel serviciul pornește pe socketul greșit. Verificați cu ip address show dev lo după o repornire și nu după comanda manuală.

Legarea este o decizie separată de adresare. O aplicație care ascultă pe fiecare adresă acceptă trafic pe interfețe pe care nu le-ați intenționat niciodată, așa că îndreptați-o spre adresa de serviciu specifică. Atunci politica de intrare locală are ceva precis cu care să se potrivească.

Cereți-o în fișierul CCD pe care hubul îl citește cu adevărat

Pe server, declarația de proprietate merge în fișierul per client selectat de numele comun autentificat, în directorul numit de client-config-dir. Linia este iroute 10.66.0.10 255.255.255.255, una pe adresă, și îi spune serverului ce partener trebuie să primească traficul pentru acea destinație.

Două detalii strică asta în liniște. Numele fișierului trebuie să corespundă numelui pe care serverul îl folosește cu adevărat, care diferă când username-as-common-name este în joc. Și iroute produce efect doar în modul TUN cu un director de configurare a clientului configurat, așa că aceeași linie nu face nimic într-o implementare în punte. Adăugați linii fișierului existent în loc să îl înlocuiți, deoarece poate purta deja o adresă fixă sau opțiuni push. Referința OpenVPN 2.6 documentează atât directorul, cât și directiva de proprietate.

Nucleul hubului însuși are nevoie și de o cale către acele destinații, astfel încât traficul generat local să intre în procesul tunelului. route 10.66.0.10 255.255.255.255 din configurația serverului acoperă traficul pe care serverul îl originează, în timp ce alți clienți au nevoie de push "route 10.66.0.10 255.255.255.255" pentru a afla singuri destinația.

Rutarea și autorizarea rămân separate. O rută împinsă îi spune unui client unde să trimită pachetele și nu acordă nimic; serviciul trebuie în continuare să accepte apelantul în propriii termeni.

Verificați politica de intrare și calea de răspuns

Un pachet adresat aliasului ajunge la gazda proprietară ca intrare locală, așa că întrebarea este dacă paravanul local permite acea sursă și acel port. Permiteți portul de serviciu specific din intervalul de surse VPN în loc să deschideți întreaga adresă.

Răspunsurile au nevoie de o cale înapoi la apelant. Pentru un apelant din grupul normal de tunel acea cale există deja, pentru că dispozitivul de tunel o transportă. Un apelant din spatele altei rețele rutate are nevoie și de ruta de întoarcere a acelei rețele, și aici configurațiile asimetrice pierd pachete.

Fiți atenți la un al doilea ascultător pe același port legat la o altă adresă, pentru că nucleul livrează socketului care se potrivește, iar rezultatele par aleatorii. Verificați cu ss -lntp și confirmați că adresa legată este aliasul serviciului. NAT-ul de sursă nu este necesar aici, iar adăugarea lui ascunde identitatea apelantului de care depind jurnalele dumneavoastră.

Testați adresele și proprietatea separat

Testați în doi pași. Mai întâi confirmați că gazda proprietară poate ajunge la serviciu pe aliasul ei de la sine, ceea ce separă problemele de legare și paravan de rutare. Apoi testați de la un apelant VPN real folosind autentificarea aplicației înseși. Când primul trece și al doilea eșuează, piesa lipsă este de partea hubului.

Verificați și modurile de eșec care supraviețuiesc unei conexiuni: aliasul rămâne atribuit când tunelul este oprit, iar hubul își păstrează ruta când partenerul lipsește. Niciun obiect singur nu dovedește că serviciul este accesibil, de aceea testul în doi pași bate un singur ping de pe un laptop.