OpenVPN oor TCP en UDP vanaf een enkele gasheer bedien
Voor 2.7 bind een proses een vervoer. Vergelyk ’n oorbrugde TAP-paar, twee TUN-subnette en ’n gedeelde poel, en pas dan elke profiel by sy luisteraar.
Netwerke wat net TCP 443 toelaat, bestaan saam met netwerke wat UDP graag deurlaat, en een bediener moet albei bedien. ’n Profiel met proto udp antwoord die tweede groep en faal op die eerste, en om dieselfde konfigurasie te wysig om proto tcp te sê, skep nie ’n tweede luisteraar nie. Die direktief kies een vervoer vir een proses. Alles anders volg uit daardie beperking.
Óf jy hardloop meer as een proses, óf jy hardloop ’n weergawe wat verskeie sokkels gelyktydig kan bind.
Een proses bind een vervoer voor 2.7
Die gemeenskapsweergawe van OpenVPN bind die sokkel wat proto beskryf, en daardie direktief kies ’n enkele vervoer vir die instansie. TCP en UDP is aparte stelle, so dieselfde poortnommer kan terselfdertyd deur albei beset word, maar nie deur een proses nie. Die 2.6-lyn gee jou dus een vervoer per daemon. OpenVPN 2.7 het daardie beperking vir bedieners verwyder; hulle kan verskeie sokkels deur veelvuldige --local -stellings in een proses bind.
Kontroleer die weergawe voordat jy rondom enige van die twee antwoorde ontwerp, want die 2.7-reëling is ’n ander bedryfsmodel met sy eie konfigurasiesintaksis. ’n Gids wat vir 2.6 geskryf is, beskryf twee prosesse selfs wanneer dit dit nie sê nie.
Drie maniere om twee instansies te hardloop
Met TAP-koppelvlakke, hardloop een instansie per vervoer en brug die twee tap-toestelle op die gasheer. Albei kliëntstelle beland in dieselfde uitsaaidomein, wat een adrespoel hulle laat dek en uitsaaiafhanklike protokolle laat werk. Met TUN is oorbrugging nie beskikbaar nie, so die eenvoudigste verdeling gee elke instansie sy eie subnet en laat routing die twee kliëntstelle apart hou. ’n Derde opsie hou een poel deur elke instansie ’n learn-address -skrip te laat roep wat ’n /32-roete vir die kliënt deur daardie instansie se toestel installeer.
Daardie derde reëling is die een wat mense vra en die een wat die meeste sorg nodig het, want die skrip word deel van die datapad en moet byvoeg-, opdateer- en verwyder-geleenthede korrek hanteer.
| 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 |
Hou die twee instansies apart
Elke instansie benodig ook ’n aparte poort of adres, ’n aparte statuslêer en ’n aparte logbestemming. Twee daemons wat by een statuslêer aanheg, produseer uitset wat nie tydens ’n voorval gelees kan word nie, en dit is juis wanneer jy dit nodig het. As ’n tweede instansie ’n bepaalde adres bind, moet daardie adres op die gasheer bestaan wanneer die proses begin; anders stop dit met ’n bindfout voordat dit iets oor sleutels sê.
Noem die eenhede en die profiele so dat die vervoer duidelik uit die lêernaam is . Die volgende operateur moet nie ’n konfigurasie hoef oop te maak om te leer watter een TCP is nie.
Pas die profiel by die luisteraar
’n Bediener wat proto tcp bedryf, verwag ’n kliëntprofiel met proto tcp-client , en ’n profiel wat nog proto udp dra teen daardie luisteraar verval sonder ’n fout wat die gebruiker kan hanteer . Hou twee profiele as die ontplooiing albei vervoer bied, en benoem hulle sodat ondersteuning kan sien watter een probeer is. Die poortnommer alleen beskryf nie die vervoer nie.
Brandmuurreëls volg dieselfde verdeling: ’n reël vir UDP 1194 sê niks oor TCP 1194 nie, en ’n reël vir een adres dek nie die ander luisteraar nie.
Lees eers die bediener se siening
Begin met ss -lntup op die bediener en bevestig dat beide ’n TCP- en ’n UDP-luisteraar verskyn. Verbind dan een kliënt van elke soort en kyk na die statusuitset vir twee inskrywings met verskillende adresse. As die sokkels bestaan en geen kliënt kom nie, weier die pad of die brandmuur pakkette voordat die daemon hulle sien.
’n Sokkel wat nooit verskyn nie, is ’n konfigurasie- of bindprobleem, en ’n sokkel wat verskyn maar nooit ’n verbinding log nie, is ’n filterprobleem. Dié twee lyk identies van die kliënt af, daarom kom die bediener se eie siening eerste. Onthou dat TCP hoof-van-die-lyn-blokkering dra, so om dit te bied is ’n bereikbaarheidsmaatstaf eerder as ’n opgradering vir kliënte met ’n skoon UDP-pad.