Að þjóna OpenVPN um TCP og UDP frá einum hýsli
Eitt ferli bindur eina flutningsleið fyrir 2.7. Berðu saman brúað TAP par, tvö TUN undirnet og sameiginlegan laug, og paraðu síðan hverja prófíl við hlustarann sinn.
Net sem leyfa aðeins TCP 443 lifa saman með netum sem hleypa UDP greiðlega í gegn, og einn þjónn verður að þjóna báðum. Prófíl með proto udp svarar seinni hópnum og bregst á þeim fyrri, og að breyta sömu stillingu til að segja proto tcp býr ekki til annan hlustara. Tilskipunin velur eina flutningsleið fyrir eitt ferli. Allt annað leiðir af þeirri takmörkun.
Annaðhvort keyrir þú fleiri en eitt ferli, eða þú keyrir útgáfu sem getur bundið nokkra sokka í einu.
Eitt ferli bindur eina flutningsleið fyrir 2.7
OpenVPN samfélagsins bindur sokkinn sem proto lýsir, og sú tilskipun velur eina flutningsleið fyrir tilvikið. TCP og UDP eru aðskildir staflar, svo sama portnúmerið getur verið upptekið af báðum á sama tíma, en ekki af einu ferli. 2.6 línan gefur þér því eina flutningsleið á hvern daemon. OpenVPN 2.7 fjarlægði þá takmörkun fyrir þjóna, sem geta bundið nokkra sokka gegnum margar --local yfirlýsingar í einu ferli.
Athugaðu útgáfuna áður en þú hannar út frá hvorugu svarinu, því 2.7 fyrirkomulagið er annað rekstrarlíkan með eigin stillingarmerkingarfræði. Leiðarvísir skrifaður fyrir 2.6 lýsir tveimur ferlum jafnvel þótt hann segi það ekki.
Þrjár leiðir til að keyra tvö tilvik
Með TAP viðmótum skaltu keyra eitt tilvik á hverja flutningsleið og brúa tvö tap tæki á hýslinum. Báðir biðlarahópar enda í sama útvarpssvæði, sem leyfir einum netfangalaug að ná yfir þá og heldur prótókollum sem byggja á útvarpi gangandi. Með TUN er brúin ekki tiltæk, svo einfaldasta skiptingin gefur hverju tilviki eigið undirnet og lætur leiðsögu halda biðlarahópunum tveimur aðskildum. Þriðji valkosturinn heldur einum laug með því að láta hvert tilvik kalla learn-address skriftu sem setur /32 leið fyrir biðlarann í gegnum tæki þess tilviks.
Þriðja fyrirkomulagið er það sem fólk biður um og það sem þarf mesta varúð, því skriftan verður hluti af gagnaleiðinni og verður að meðhöndla bæta við, uppfæra og eyða atburði rétt.
| 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 |
Haltu tilvikunum tveimur aðskildum
Hvert tilvik þarf einnig aðskilda port eða vistfang, aðskilda stöðuskrá og aðskilinn log áfangastað. Tveir daemonar sem bæta við sömu stöðuskrá framleiða úttak sem ekki er hægt að lesa í atviki, og það er einmitt þegar þú þarft það. Ef annað tilvik bindur tiltekið vistfang verður það vistfang að vera til á hýslinum þegar ferlið byrjar; annars hættir það með bind mistökum áður en það segir nokkuð um lykla.
Nefndu einingarnar og prófílana þannig að flutningsleiðin sé augljós af skráarnafninu. Næsti rekstraraðili ætti ekki að þurfa að opna stillingu til að vita hvor er TCP.
Paraðu prófílinn við hlustarann
Þjónn sem keyrir proto tcp væntir biðlaraprófíls með proto tcp-client, og prófíl sem enn ber proto udp gagnvart þeim hlustara renna út á tíma án villu sem notandinn getur brugðist við. Haltu tveimur prófílum ef uppsetningin býður báðar flutningsleiðir, og merktu þá svo stuðningur viti hvor var reynd. Portnúmerið eitt og sér lýsir ekki flutningsleiðinni.
Eldveggsreglur fylgja sömu skiptingu: regla fyrir UDP 1194 segir ekkert um TCP 1194, og regla fyrir eitt vistfang nær ekki yfir hinn hlustarann.
Lestu sýn þjónsins fyrst
Byrjaðu á ss -lntup á þjóninum og staðfestu að bæði TCP og UDP hlustari birtist. Tengdu síðan einn biðlara af hvorri gerð og athugaðu stöðuúttakið fyrir tvær færslur með ólíkum vistföngum. Ef sokkarnir eru til og enginn biðlari kemur eru leiðin eða eldveggurinn að hafna pakkum áður en daemoninn sér þá.
Sokkur sem birtist aldrei er stillingar- eða bind vandamál, og sokkur sem birtist en skráir aldrei tengingu er síunarvandamál. Þetta tvennt lítur eins út frá biðlaranum, og þess vegna kemur sýn þjónsins sjálfs fyrst. Hafðu í huga að TCP ber höfuðlínu blokkun, svo að bjóða það er aðgerð um aðgengi en ekki uppfærsla fyrir biðlara með hreina UDP leið.