OpenVPN pakalpošana TCP un UDP no viena resursdatora
Viens process pirms 2.7 piesaista vienu transportu. Salīdziniet tiltā savienotu TAP pāri, divus TUN apakštīklus un kopīgu baseinu, pēc tam saskaņojiet katru profilu ar tā klausītāju.
Tīkli, kas atļauj tikai TCP 443, pastāv līdzās tīkliem, kas UDP bez problēmām izlaiž, un vienam serverim jāapkalpo abi. Profils ar proto udp atbild otrajai grupai un neizdodas pirmajā, un tās pašas konfigurācijas rediģēšana uz proto tcp neizveido otru klausītāju. Direktīva izvēlas vienu transportu vienam procesam. Viss pārējais izriet no šī ierobežojuma.
Vai nu palaidiet vairāk nekā vienu procesu, vai palaidiet versiju, kas var piesaistīt vairākas ligzdas vienlaikus.
Viens process pirms 2.7 piesaista vienu transportu
Kopienas OpenVPN piesaista ligzdu, ko apraksta proto, un šī direktīva instancei izvēlas vienu transportu. TCP un UDP ir atsevišķi steki, tāpēc to pašu porta numuru vienlaikus var aizņemt abi, bet ne viens process. Tāpēc 2.6 līnija dod vienu transportu katram dēmonam. OpenVPN 2.7 atcēla šo ierobežojumu serveriem, kas var piesaistīt vairākas ligzdas, izmantojot vairākus --local paziņojumus vienā procesā.
Pārbaudiet versiju pirms projektēšanas ap jebkuru atbildi, jo 2.7 izkārtojums ir cits operatīvais modelis ar savu konfigurācijas sintaksi. Ceļvedis, kas rakstīts 2.6, apraksta divus procesus arī tad, kad to nesaka.
Trīs veidi, kā darbināt divas instances
Ar TAP saskarnēm darbiniet vienu instanci katram transportam un savienojiet abas tap ierīces ar tiltu resursdatorā. Abas klientu kopas nonāk vienā apraides domēnā, kas ļauj vienam adrešu baseinam tās noklāt un saglabā apraidē atkarīgo protokolu darbību. Ar TUN tilts nav pieejams, tāpēc vienkāršākais sadalījums katrai instancei dod savu apakštīklu un maršrutēšana uztur abas klientu kopas atsevišķi. Trešā iespēja saglabā vienu baseinu: katra instance izsauc learn-address skriptu, kas klientam instalē /32 maršrutu caur šīs instances ierīci.
Šis trešais izkārtojums ir tas, ko cilvēki prasa, un tas, kam nepieciešama vislielākā rūpība, jo skripts kļūst par datu ceļa daļu un tam pareizi jāapstrādā pievienošanas, atjaunināšanas un dzēšanas notikumi.
| 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 |
Turiet abas instances atsevišķi
Katrai instancei vajadzīgs arī atsevišķs ports vai adrese, atsevišķa statusa datne un atsevišķs žurnāla mērķis. Divi dēmoni, kas pievieno vienai statusa datnei, rada izvadi, ko incidenta laikā nevar nolasīt, un tieši tad tā jums ir vajadzīga. Ja otrā instance piesaista konkrētu adresi, šai adresei jābūt resursdatorā, kad process startē; pretējā gadījumā tas iziet ar piesaistes kļūdu, pirms pasaka ko par atslēgām.
Nosauciet vienības un profilus tā, lai transports būtu redzams no faila nosaukuma. Nākamajam operatoram nevajadzētu atvērt konfigurāciju, lai uzzinātu, kurš ir TCP.
Saskaņojiet profilu ar klausītāju
Serveris, kas darbina proto tcp, sagaida klienta profilu ar proto tcp-client, un profils, kas joprojām satur proto udp, pret šo klausītāju beidzas ar taimautu bez kļūdas, ar ko lietotājs var rīkoties. Turiet divus profilus, ja izvietojums piedāvā abus transportus, un marķējiet tos, lai atbalsts zina, kurš tika izmēģināts. Tikai porta numurs transportu neapraksta.
Ugunsmūra noteikumi ievēro to pašu sadalījumu: noteikums UDP 1194 neko nesaka par TCP 1194, un noteikums vienai adresei neaptver otru klausītāju.
Vispirms izlasiet servera skatu
Sāciet ar ss -lntup serverī un apstipriniet, ka parādās gan TCP, gan UDP klausītājs. Pēc tam pievienojiet pa vienam katras grupas klientam un pārbaudiet statusa izvadi, vai tajā ir divi ieraksti ar atšķirīgām adresēm. Ja ligzdas pastāv un neviens klients nenāk, ceļš vai ugunsmūris atsaka paketes, pirms dēmons tās ierauga.
Ligzda, kas nekad neparādās, ir konfigurācijas vai piesaistes problēma, un ligzda, kas parādās, bet nekad nereģistrē savienojumu, ir filtrēšanas problēma. No klienta puses abas izskatās vienādi, tāpēc vispirms tiek ņemts paša servera skats. Ņemiet vērā, ka TCP ietver rindas galvas bloķēšanu, tāpēc tā piedāvāšana ir sasniedzamības pasākums, nevis uzlabojums klientiem ar tīru UDP ceļu.