OpenVPN oer TCP en UDP fan ien host tsjinje
Ien proses bûn ien transport foar 2.7. Fergelykje in brêge TAP-pear, twa TUN-subnetten en in dielde poel, en keppelje dan elk profyl oan syn lústerder.
Netwurken dy't allinnich TCP 443 tastean, besteane njonken netwurken dy't UDP sûnder problemen trochjaan, en ien tsjinner moat beide betsjinje. In profyl mei proto udp beantwurdet de twadde groep en falt by de earste, en deselde konfiguraasje bewurkje om proto tcp te sizzen makket gjin twadde lústerder. De rjochtline kiest ien transport foar ien proses. Al it oare folget út dy beheining.
Of jo rinne mear as ien proses, of jo rinne in ferzje dy't ferskate sockets tagelyk bine kin.
Ien proses bûn ien transport foar 2.7
Community OpenVPN bûn de socket dy't proto beskriuwt, en dy rjochtline kiest ien transport foar it eksimplaar. TCP en UDP binne aparte steapels, sadat itselde poartnûmer tagelyk troch beide beset wurde kin, mar net troch ien proses. De 2.6-rige jout jo dêrom ien transport per daemon. OpenVPN 2.7 helle dy beheining foar tsjinners fuort, dy't ferskate sockets fia meardere --local-útspraken yn ien proses bine kinne.
Kontrolearje de ferzje foardat jo om ien fan beide antwurden hinne ûntwerpe, want de 2.7-opset is in oar operasjoneel model mei syn eigen konfiguraasjesyntaksis. In gids skreaun foar 2.6 beskriuwt twa prosessen, sels as it dat net seit.
Trije manieren om twa eksimplaren te draaien
Mei TAP-ynterfaces draaie jo ien eksimplaar per transport en brêgje jo de twa tap-apparaten op de host. Beide klantsets einigje yn itselde broadcast-domein, wêrtroch ien adrespoel se dekke kin en broadcast-ôfhinklike protokollen bliuwe wurkjen. Mei TUN is brêgjen net beskikber, sadat de ienfâldichste splitsing elk eksimplaar syn eigen subnet jout en routing de twa klantsets apart hâldt. In tredde opsje hâldt ien poel troch elk eksimplaar in learn-address-skript oanroppe te litten dat in /32-route foar de klant ynstallearret fia it apparaat fan dat eksimplaar.
Dy tredde opstelling is dejinge dêr't minsken om freegje en dejinge dy't de measte soarch fereasket, want it skript wurdt diel fan it datapad en moat tafoegje-, bywurkje- en wiskje-eveneminten goed behannelje.
| 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 |
Hâld de twa eksimplaren apart
Elk eksimplaar hat ek in aparte poarte as adres nedich, in apart statusbestân en in aparte logbestimming. Twa daemons dy't oan ien statusbestân taheakje, produsearje útfier dy't by in ynsidint net lêzen wurde kin, en krekt dan hawwe jo dy nedich. As in twadde eksimplaar in spesifyk adres bûn, moat dat adres op de host bestean as it proses start; oars ferlit it mei in bind-flater foardat it eat oer kaaien seit.
Neam de units en de profilen sa dat it transport fanselssprekkend is út de bestânsnamme. De folgjende operator soe gjin konfiguraasje iepenje moatte om te witten hokker ien TCP is.
Keppelje it profyl oan de lústerder
In tsjinner dy't proto tcp draait, ferwachtet in klantprofyl mei proto tcp-client, en in profyl dat noch proto udp fiert tsjin dy lústerder rint út op in timeout sûnder in flater dêr't de brûker wat mei kin. Hâld twa profilen as de ynset beide transports biedt, en labelje se sa dat support sjen kin hokker besocht is. It poartnûmer allinnich beskriuwt it transport net.
Firewall-regels folgje deselde splitsing: in regel foar UDP 1194 seit neat oer TCP 1194, en in regel foar ien adres dekt de oare lústerder net.
Lês earst it byld fan de tsjinner
Begjin mei ss -lntup op de tsjinner en befêstigje dat sawol in TCP- as in UDP-lústerder ferskynt. Ferbyn dan ien klant fan elk soarte en kontrolearje de statusútfier op twa ynfieringen mei ferskate adressen. As de sockets bestean en der komt gjin klant, dan wegeret it paad of de firewall pakketten foardat de daemon se sjocht.
In socket dy't nea ferskynt is in konfiguraasje- of bind-probleem, en in socket dy't ferskynt mar nea in ferbining logt is in filterprobleem. Dy twa sjogge der fan de klant út itselde, en dêrom komt it eigen byld fan de tsjinner earst. Hâld yn gedachten dat TCP head-of-line-blocking hat, sadat it oanbieden derfan in berikberheidsmaatregel is ynstee fan in upgrade foar klanten mei in skjin UDP-paad.