Servirea OpenVPN prin TCP și UDP de pe un singur host
Un proces leagă un singur transport înainte de 2.7. Comparați o pereche TAP punte, două subrețele TUN și un pool comun, apoi potriviți fiecare profil cu listenerul său.
Rețelele care permit doar TCP 443 coexistă cu rețelele care lasă UDP să treacă fără probleme, iar un singur server trebuie să le servească pe amândouă. Un profil cu proto udp răspunde celui de-al doilea grup și eșuează pe primul, iar editarea aceleiași configurații ca să spună proto tcp nu creează un al doilea listener. Directiva alege un singur transport pentru un proces. Tot restul decurge din această constrângere.
Fie rulați mai mult de un proces, fie rulați o versiune care poate lega mai multe socketuri deodată.
Un proces leagă un singur transport înainte de 2.7
OpenVPN comunitar leagă socketul pe care îl descrie proto, iar acea directivă alege un singur transport pentru instanță. TCP și UDP sunt stive separate, așa că același număr de port poate fi ocupat de ambele în același timp, dar nu de un singur proces. Linia 2.6 vă oferă deci un transport pe daemon. OpenVPN 2.7 a eliminat această limitare pentru servere, care pot lega mai multe socketuri prin mai multe instrucțiuni --local într-un singur proces.
Verificați versiunea înainte de a proiecta în jurul oricăruia dintre răspunsuri, pentru că aranjamentul 2.7 este un alt model operațional, cu propria sintaxă de configurare. Un ghid scris pentru 2.6 descrie două procese chiar și când nu spune asta.
Trei moduri de a rula două instanțe
Cu interfețe TAP, rulați o instanță pe transport și punteați cele două dispozitive tap pe host. Ambele seturi de clienți ajung în același domeniu de broadcast, ceea ce permite unui singur pool de adrese să le acopere și menține funcționarea protocoalelor dependente de broadcast. Cu TUN, puntea nu este disponibilă, așa că cea mai simplă împărțire dă fiecărei instanțe propria subrețea, iar rutarea ține cele două seturi de clienți separate. O a treia opțiune păstrează un singur pool, făcând fiecare instanță să apeleze un script learn-address care instalează o rută /32 pentru client prin dispozitivul acelei instanțe.
Această a treia configurație este cea pe care oamenii o cer și cea care necesită cea mai multă atenție, pentru că scriptul devine parte din calea datelor și trebuie să gestioneze corect evenimentele de adăugare, actualizare și ștergere.
| Arrangement | Interfaces | Address pool | Cost |
|---|---|---|---|
| Bridged TAP pair | Two tap devices joined by a bridge | One shared pool | Broadcast traffic and bridge maintenance |
| Two TUN subnets | Two tun devices, no bridge | One pool per instance | Routing rules and two plans |
| Shared pool with routes | Two tun devices plus a hook | One pool across both | A script on the data path |
Țineți cele două instanțe separate
Fiecare instanță are nevoie și de un port sau o adresă separată, de un fișier de stare separat și de o destinație de jurnal separată. Două daemonuri care scriu în același fișier de stare produc o ieșire care nu poate fi citită în timpul unui incident, iar exact atunci aveți nevoie de ea. Dacă o a doua instanță leagă o adresă anume, acea adresă trebuie să existe pe host când pornește procesul; altfel iese cu o eroare de legare înainte de a spune ceva despre chei.
Denumiți unitățile și profilurile astfel încât transportul să fie evident din numele fișierului. Următorul operator nu ar trebui să deschidă o configurație ca să afle care este TCP.
Potriviți profilul cu listenerul
Un server care rulează proto tcp așteaptă un profil de client cu proto tcp-client, iar un profil care încă poartă proto udp împotriva acelui listener expiră fără o eroare pe care utilizatorul să poată acționa. Păstrați două profiluri dacă implementarea oferă ambele transporturi și etichetați-le astfel încât suportul să știe care a fost încercat. Doar numărul portului nu descrie transportul.
Regulile de firewall urmează aceeași împărțire: o regulă pentru UDP 1194 nu spune nimic despre TCP 1194, iar o regulă pentru o adresă nu acoperă celălalt listener.
Citiți mai întâi imaginea serverului
Începeți cu ss -lntup pe server și confirmați că apar atât un listener TCP, cât și unul UDP. Apoi conectați câte un client din fiecare tip și verificați ieșirea de stare pentru două intrări cu adrese distincte. Dacă socketurile există și niciun client nu vine, calea sau firewallul resping pachetele înainte ca daemonul să le vadă.
Un socket care nu apare niciodată este o problemă de configurare sau de legare, iar un socket care apare dar nu înregistrează niciodată o conexiune este o problemă de filtrare. Cele două arată identic din partea clientului, de aceea imaginea serverului însuși vine prima. Rețineți că TCP are blocare la capul cozii, așa că oferirea lui este o măsură de accesibilitate, nu o îmbunătățire pentru clienții cu o cale UDP curată.