Paghahatid ng OpenVPN sa TCP at UDP mula sa isang host
Isang proseso ang nagbibitbit ng isang transport bago ang 2.7. Ihambing ang tulay na pares ng TAP, dalawang subnet ng TUN at isang pinagsasaluhang pool, pagkatapos itugma ang bawat profile sa tagapakinig nito.
Ang mga network na TCP 443 lang ang pinapayagan ay kasamang umiiral ng mga network na malayang nagpapadaan ng UDP, at isang server ang dapat maghatid sa dalawa. Ang profile na may proto udp ay tumutugon sa pangalawang grupo at nabibigo sa una, at ang pag-edit ng parehong configuration upang sabihing proto tcp ay hindi lumilikha ng pangalawang tagapakinig. Ang direktiba ay pumipili ng isang transport para sa isang proseso. Lahat ng iba ay sumusunod sa paghihigpit na iyon.
Maaaring magpatakbo ka ng higit sa isang proseso, o magpatakbo ka ng bersyong kayang magbigkis ng ilang socket nang sabay.
Isang proseso ang nagbibitbit ng isang transport bago ang 2.7
Ang OpenVPN ng komunidad ay nagbibigkis ng socket na inilalarawan ng proto, at pinipili ng direktibang iyon ang isang transport para sa instance. Ang TCP at UDP ay magkahiwalay na stack, kaya ang parehong numero ng port ay maaaring sakupin ng dalawa nang sabay, ngunit hindi ng isang proseso. Kaya ang linyang 2.6 ay nagbibigay ng isang transport kada daemon. Inalis ng OpenVPN 2.7 ang paghihigpit na iyon para sa mga server, na kayang magbigkis ng ilang socket sa pamamagitan ng ilang --local pahayag sa isang proseso.
Suriin ang bersyon bago magdisenyo sa paligid ng alinmang sagot, dahil ang kaayusan ng 2.7 ay ibang modelong pang-operasyon na may sariling sintaks ng configuration. Ang gabay na isinulat para sa 2.6 ay naglalarawan ng dalawang proseso kahit hindi nito sinasabi.
Tatlong paraan upang magpatakbo ng dalawang instance
Sa mga interface ng TAP, magpatakbo ng isang instance kada transport at itulay ang dalawang aparatong tap sa host. Parehong napupunta ang dalawang pangkat ng kliyente sa isang broadcast domain, na nagpapahintulot sa isang pool ng address na saklawin sila at pinapanatiling gumagana ang mga protocol na umaasa sa broadcast. Sa TUN ay hindi magagamit ang pagtutulay, kaya ang pinakasimpleng paghahati ay nagbibigay sa bawat instance ng sariling subnet at hinahayaan ng routing na paghiwalayin ang dalawang pangkat ng kliyente. Ang ikatlong opsyon ay nagpapanatili ng isang pool sa pamamagitan ng pagpapaalam sa bawat instance na tumawag ng script na learn-address na nagluluklok ng rutang /32 para sa kliyente sa pamamagitan ng aparato ng instance na iyon.
Ang ikatlong kaayusang iyon ang hinihiling ng mga tao at ang pinakanangangailangan ng pag-iingat, dahil ang script ay nagiging bahagi ng landas ng data at dapat hawakan nang tama ang mga kaganapan ng pagdaragdag, pag-update at pagtanggal.
| 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 |
Panatilihing hiwalay ang dalawang instance
Kailangan din ng bawat instance ng hiwalay na port o address, hiwalay na file ng status at hiwalay na destinasyon ng log. Dalawang daemon na nagsusulat sa isang file ng status ay gumagawa ng output na hindi mabasa sa oras ng insidente, at iyon mismo ang sandaling kailangan mo ito. Kung ang ikalawang instance ay nagbigkis ng partikular na address, dapat umiiral ang address na iyon sa host kapag nagsimula ang proseso; kung hindi, lalabas ito na may bigong pagbigkis bago pa sabihin ang anuman tungkol sa mga key.
Pangalanan ang mga unit at profile upang halata ang transport mula sa pangalan ng file. Hindi dapat kailanganin ng susunod na operator na buksan ang configuration para malaman kung alin ang TCP.
Itugma ang profile sa tagapakinig
Ang server na nagpapatakbo ng proto tcp ay umaasa ng profile ng kliyenteng may proto tcp-client, at ang profile na may proto udp pa laban sa tagapakinig na iyon ay nagtatapos sa oras na walang error na maaaring aksyunan ng gumagamit. Panatilihin ang dalawang profile kung inaalok ng deployment ang dalawang transport, at lagyan ng label upang malaman ng suporta kung alin ang sinubukan. Ang numero ng port lamang ay hindi naglalarawan ng transport.
Ang mga patakaran ng firewall ay sumusunod sa parehong paghahati: ang patakaran para sa UDP 1194 ay walang sinasabi tungkol sa TCP 1194, at ang patakaran para sa isang address ay hindi sumasaklaw sa kabilang tagapakinig.
Basahin muna ang pananaw ng server
Magsimula sa ss -lntup sa server at tiyakin na lumilitaw ang parehong tagapakinig na TCP at UDP. Pagkatapos ikonekta ang isang kliyente ng bawat uri at tingnan ang output ng status para sa dalawang entry na may magkaibang address. Kung may mga socket at walang dumarating na kliyente, tinatanggihan ng landas o ng firewall ang mga packet bago pa makita ng daemon.
Ang socket na hindi kailanman lumilitaw ay problema sa configuration o pagbigkis, at ang socket na lumilitaw ngunit hindi kailanman nagtatala ng koneksyon ay problema sa pagsasala. Pareho silang nakikita mula sa kliyente, kaya ang sariling pananaw ng server ang nauuna. Tandaan na ang TCP ay may hadlang sa unahan ng pila, kaya ang pag-aalok nito ay hakbang sa maabot at hindi upgrade para sa mga kliyenteng may malinis na landas ng UDP.