OpenVPN teikimas per TCP ir UDP iš vieno hosto
Vienas procesas susieja vieną transportą iki 2.7. Palyginkite sujungtą TAP porą, du TUN potinklius ir bendrą adresų baseiną, tada priskirkite kiekvieną profilį jo klausytojui.
Tinklai, leidžiantys tik TCP 443, gyvuoja šalia tinklų, kurie UDP praleidžia be problemų, ir vienas serveris turi aptarnauti abu. Profilis su proto udp atsako antrajai grupei ir žlunga pirmojoje, o tos pačios konfigūracijos redagavimas į proto tcp nesukuria antrojo klausytojo. Direktyva parenka vieną transportą vienam procesui. Visa kita išplaukia iš šio apribojimo.
Arba paleiskite daugiau nei vieną procesą, arba paleiskite versiją, kuri gali susieti kelis lizdus vienu metu.
Vienas procesas susieja vieną transportą iki 2.7
Bendruomenės OpenVPN susieja lizdą, kurį aprašo proto, ir ši direktyva instancijai parenka vieną transportą. TCP ir UDP yra atskiri kaminai, todėl tą patį prievado numerį vienu metu gali užimti abu, bet ne vienas procesas. Todėl 2.6 linija suteikia vieną transportą kiekvienai tarnybai. OpenVPN 2.7 panaikino šį apribojimą serveriams, kurie gali susieti kelis lizdus per kelis --local teiginius viename procese.
Patikrinkite versiją prieš projektuodami pagal bet kurį atsakymą, nes 2.7 išdėstymas yra kitas operacinis modelis su sava konfigūracijos sintakse. Vadovas, parašytas 2.6, aprašo du procesus net kai to nesako.
Trys būdai paleisti dvi instancijas
Su TAP sąsajomis paleiskite po vieną instanciją kiekvienam transportui ir sujunkite du tap įrenginius hoste. Abi klientų grupės atsiduria tame pačiame transliacijos domene, todėl vienas adresų baseinas gali jas padengti ir išlaikomas transliacija pagrįstų protokolų veikimas. Su TUN sujungimas negalimas, todėl paprasčiausias padalijimas kiekvienai instancijai duoda savo potinklį, o maršrutizavimas laiko dvi klientų grupes atskirai. Trečias variantas išlaiko vieną baseiną: kiekviena instancija iškviečia learn-address scenarijų, kuris įrengia /32 maršrutą klientui per tos instancijos įrenginį.
Šis trečiasis išdėstymas yra tas, kurio žmonės prašo, ir tas, kuriam reikia daugiausia atsargumo, nes scenarijus tampa duomenų kelio dalimi ir turi tinkamai apdoroti pridėjimo, atnaujinimo ir šalinimo įvykius.
| 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 |
Laikykite dvi instancijas atskirai
Kiekvienai instancijai taip pat reikia atskiro prievado ar adreso, atskiro būsenos failo ir atskiro žurnalo tikslo. Du tarnybiniai procesai, rašantys į tą patį būsenos failą, sukuria išvestį, kurios negalima perskaityti incidento metu, o būtent tada jos ir reikia. Jei antroji instancija susieja konkretų adresą, tas adresas turi egzistuoti hoste, kai procesas paleidžiamas; priešingu atveju jis išeina su susiejimo klaida dar nieko nepasakęs apie raktus.
Pavadinkite padalinius ir profilius taip, kad transportas būtų akivaizdus iš failo pavadinimo. Kitas operatorius neturėtų atidarinėti konfigūracijos, kad sužinotų, kuris yra TCP.
Priskirkite profilį klausytojui
Serveris, paleidžiantis proto tcp, tikisi kliento profilio su proto tcp-client, o profilis, vis dar turintis proto udp, prieš tą klausytoją baigiasi laiko limitu be klaidos, dėl kurios vartotojas galėtų imtis veiksmų. Laikykite du profilius, jei diegimas siūlo abu transportus, ir pažymėkite juos, kad palaikymas žinotų, kuris buvo bandytas. Vien prievado numeris transporto neaprašo.
Ugniasienės taisyklės laikosi to paties padalijimo: taisyklė UDP 1194 nieko nesako apie TCP 1194, o vieno adreso taisyklė neapima kito klausytojo.
Pirmiausia perskaitykite serverio vaizdą
Pradėkite nuo ss -lntup serveryje ir patvirtinkite, kad matomas ir TCP, ir UDP klausytojas. Tada prijunkite po vieną kiekvienos rūšies klientą ir patikrinkite būsenos išvestį, ar yra du įrašai su skirtingais adresais. Jei lizdai yra, o klientas neateina, kelias arba ugniasienė atmeta paketus dar prieš tarnybai juos pamatant.
Lizdas, kuris niekada nepasirodo, yra konfigūracijos arba susiejimo problema, o lizdas, kuris pasirodo, bet niekada neužregistruoja ryšio, yra filtravimo problema. Kliento pusėje abu atrodo vienodai, todėl pirmiausia imamas paties serverio vaizdas. Atminkite, kad TCP turi eilės galvos blokavimą, todėl jo siūlymas yra pasiekiamumo priemonė, o ne patobulinimas klientams su švariu UDP keliu.