Posluživanje OpenVPN-a preko TCP-a i UDP-a s jednog hosta
Prije 2.7 jedan proces veže jedan transport. Uporedite premosćeni TAP par, dvije TUN podmreže i zajednički bazen, pa uskladite svaki profil sa njegovim slušaocem.
Mreže koje dopuštaju samo TCP 443 koegzistiraju s mrežama koje UDP propuštaju bez problema, a jedan poslužitelj mora opsluživati obje. Profil s proto udp odgovara drugoj grupi i pada na prvoj, a izmjena iste konfiguracije da kaže proto tcp ne stvara drugi slušalac. Direktiva bira jedan transport za jedan proces. Sve ostalo proizlazi iz tog ograničenja.
Ili pokrećete više od jednog procesa, ili pokrećete verziju koja može vezati nekoliko socketa odjednom.
Prije 2.7 jedan proces veže jedan transport
Community verzija OpenVPN veže socket koji opisuje proto , a ta direktiva bira jedan transport za instancu. TCP i UDP su odvojeni stogovi, pa isti broj porta mogu zauzeti oba istovremeno, ali ne jedan proces. Zato vam linija 2.6 daje jedan transport po daemonu. OpenVPN 2.7 uklonio je to ograničenje za poslužitelje, koji mogu vezati nekoliko socketa kroz više --local u jednom procesu.
Provjerite verziju prije nego što dizajnirate oko bilo kojeg od dva odgovora, jer je raspored 2.7 drugačiji operativni model s vlastitom sintaksom konfiguracije. Vodič napisan za 2.6 opisuje dva procesa čak i kada to ne kaže.
Tri načina da pokrenete dvije instance
S TAP interfejsima pokrenite po jednu instancu na transport i premosite dva tap uređaja na hostu. Oba skupa klijenata završe u istoj broadcast domeni, što jednom bazenu adresa omogućuje da ih pokrije i održava rad protokola zavisnih od broadcasta. S TUN-om premosćivanje nije dostupno, pa najjednostavnija podjela daje svakoj instanci vlastitu podmrežu i prepušta rutiranju da drži dva skupa klijenata odvojeno. Treća opcija zadržava jedan bazen tako što svaka instanca poziva learn-address skriptu koja instalira /32 rutu za klijenta kroz uređaj te instance.
Taj treći raspored je ono što ljudi traže i ono što traži najviše pažnje, jer skripta postaje dio putanje podataka i mora ispravno obrađivati događaje dodavanja, ažuriranja i brisanja.
| 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 |
Držite dvije instance odvojeno
Svakoj instanci treba i odvojen port ili adresa, odvojena statusna datoteka i odvojeno odredište dnevnika. Dva daemona koja dopisuju u jednu statusnu datoteku daju izlaz koji se ne može čitati tokom incidenta, a upravo tada vam treba. Ako druga instanca veže određenu adresu, ta adresa mora postojati na hostu kada proces krene; inače izlazi s greškom vezivanja prije nego što išta kaže o ključevima.
Imenujte jedinice i profile tako da transport bude očigledan iz imena datoteke . Sljedeći operater ne bi trebao otvarati konfiguraciju da bi saznao koja je TCP.
Uskladite profil sa slušaocem
Poslužitelj koji pokreće proto tcp očekuje klijentski profil s proto tcp-client , a profil koji još nosi proto udp prema tom slušaocu istječe bez greške na koju korisnik može reagirati . Zadržite dva profila ako implementacija nudi oba transporta i označite ih tako da podrška može vidjeti koji je isproban. Sam broj porta ne opisuje transport.
Firewall pravila slijede istu podjelu: pravilo za UDP 1194 ne govori ništa o TCP 1194, a pravilo za jednu adresu ne pokriva drugi slušalac.
Prvo pročitajte pogled poslužitelja
Počnite s ss -lntup na poslužitelju i potvrdite da se pojavljuju i TCP i UDP slušalac. Zatim povežite po jednog klijenta svake vrste i provjerite statusni izlaz za dva unosa s različitim adresama. Ako socketi postoje a nijedan klijent ne dolazi, putanja ili firewall odbija pakete prije nego što ih daemon vidi.
Socket koji se nikada ne pojavi problem je konfiguracije ili vezivanja, a socket koji se pojavi ali nikad ne zabilježi vezu problem je filtriranja. S klijentske strane ta dva izgledaju identično, zato pogled samog poslužitelja dolazi prvi. Imajte na umu da TCP nosi blokiranje na čelu reda, pa je njegovo nudenje mjera dostupnosti, a ne nadogradnja za klijente s čistom UDP putanjom.