Нэг хостноос TCP ба UDP-ээр OpenVPN үйлчлэх
2.7-оос өмнө нэг процесс нэг тээврийг холбодог. Гүүрээр холбосон TAP хос, хоёр TUN дэд сүлжээ, хуваалцсан санг харьцуулж, дараа нь профайл бүрийг өөрийн сонсогчтой нь тааруулна уу.
Зөвхөн TCP 443-ыг зөвшөөрдөг сүлжээнүүд UDP-г чөлөөтэй дамжуулдаг сүлжээнүүдтэй зэрэгцэн оршиж, нэг сервер хоёуланд нь үйлчлэх ёстой. proto udp бүхий профайл хоёр дахь бүлэгт хариулж, эхнийх дээр бүтэлгүйтдэг бөгөөд мөн адил тохиргоог proto tcp гэж засах нь хоёр дахь сонсогчийг үүсгэхгүй. Заавар нь нэг процессод нэг тээвэр сонгодог. Бусад бүх зүйл энэ хязгаарлалтаас үүдэлтэй.
Нэгээс олон процесс ажиллуулах, эсвэл нэгэн зэрэг олон сокет холбож чадах хувилбарыг ажиллуулах хэрэгтэй.
2.7-оос өмнө нэг процесс нэг тээврийг холбодог
Нийгэмлэгийн OpenVPN нь proto дүрсэлсэн сокетыг холбодог бөгөөд энэ заавар нь инстанцад нэг тээвэр сонгодог. TCP ба UDP нь тусдаа стек тул ижил портын дугаарыг хоёулаа нэгэн зэрэг эзэлж болох ч нэг процесс эзэлж чадахгүй. Тиймээс 2.6 шугам танд демон бүрт нэг тээвэр өгдөг. OpenVPN 2.7 серверүүдийн хувьд энэ хязгаарлалтыг хасаж, нэг процесс дотор олон --local мэдэгдлээр олон сокет холбох боломжтой болсон.
Аль ч хариултыг тойруулан зохион бүтээхээс өмнө хувилбарыг шалгаарай, учир нь 2.7 зохион байгуулалт нь өөрийн тохиргооны синтакстай өөр үйл ажиллагааны загвар юм. 2.6-д зориулсан гарын авлага хэлээгүй ч хоёр процессын тухай өгүүлдэг.
Хоёр инстанц ажиллуулах гурван арга
TAP интерфэйсийн хувьд тээвэр бүрт нэг инстанц ажиллуулж, хостын хоёр tap төхөөрөмжийг гүүрээр холбоно. Хоёр клиент бүлэг ижил нэвтрүүлэх домэйнд ордог тул нэг хаягийн сан тэднийг хамрах боломжтой бөгөөд нэвтрүүлгээс хамааралтай протоколууд ажилласаар байна. TUN-ийн хувьд гүүр боломжгүй тул хамгийн энгийн хуваалт инстанц бүрт өөрийн дэд сүлжээг өгч, чиглүүлэлт хоёр клиент бүлгийг тусгаарлана. Гурав дахь сонголт нэг санг хадгална: инстанц бүр learn-address скриптийг дуудаж, энэ нь тухайн инстанцын төхөөрөмжөөр дамжуулан клиентэд /32 маршрут суулгана.
Тухайн гурав дахь зохион байгуулалт нь хүмүүсийн хүсдэг бөгөөд хамгийн их анхаарал шаарддаг нь, учир нь скрипт өгөгдлийн замд орж, нэмэх, шинэчлэх, устгах үйл явдлыг зөв зохицуулах ёстой.
| 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 |
Хоёр инстанцыг тусгаар байлга
Инстанц бүрт тусдаа порт эсвэл хаяг, тусдаа төлөвийн файл, тусдаа логын очих газар хэрэгтэй. Нэг төлөвийн файлд нэмдэг хоёр демон ослын үед уншиж болохгүй гаралт үүсгэдэг бөгөөд яг тэр үед танд хэрэгтэй байдаг. Хоёр дахь инстанц тодорхой хаягийг холбож байгаа бол процесс эхлэх үед тэр хаяг хост дээр байх ёстой; эс бөгөөс түлхүүрүүдийн талаар юу ч хэлэхээс өмнө холболтын алдаатайгаар гарч оддог.
Нэгжүүд болон профайлуудыг тээврийг файлын нэрнээс нь харж болохоор нэрлэ. Дараагийн оператор аль нь TCP гэдгийг мэдэхийн тулд тохиргоо нээх шаардлагагүй байх ёстой.
Профайлыг сонсогчтой тааруул
proto tcp ажиллуулж буй сервер proto tcp-client бүхий клиент профайлыг хүлээж байна, харин proto udp хэвээр агуулсан профайл тэр сонсогчийн эсрэг хэрэглэгчийн арга хэмжээ авах боломжтой алдаагүйгээр хугацаа хэтэрч зогсдог. Хэрэв байршуулалт хоёр тээврийг санал болгодог бол хоёр профайл хадгалж, аль нь туршигдсаныг дэмжлэг мэдэхээр шошголно уу. Зөвхөн портын дугаар тээврийг дүрслэхгүй.
Галт ханын дүрэм мөн адил хуваагдана: UDP 1194-ийн дүрэм TCP 1194-ийн талаар юу ч хэлэхгүй, нэг хаягийн дүрэм нөгөө сонсогчийг хамрахгүй.
Эхлээд серверийн харагдах байдлыг унш
Сервер дээр ss -lntup-ээр эхэлж, TCP болон UDP сонсогч хоёулаа харагдаж байгааг батал. Дараа нь төрөл бүрээс нэг клиент холбож, өөр өөр хаягтай хоёр бичлэгийг төлөвийн гаралтаас шалга. Хэрэв сокетууд байгаа бөгөөд клиент ирэхгүй бол демон тэднийг харахаас өмнө зам эсвэл галт хана пакетуудыг татгалзаж байна.
Хэзээ ч харагдахгүй сокет нь тохиргоо эсвэл холболтын асуудал, харин харагдаж байгаа ч хэзээ ч холболт бүртгэдэггүй сокет нь шүүлтийн асуудал. Клиентээс харахад хоёулаа ижил харагддаг тул серверийн өөрийнх нь харагдах байдал эхэндээ ирдэг. TCP нь дарааллын толгойн блоклолтыг агуулдаг тул үүнийг санал болгох нь цэвэр UDP замтай клиентүүдэд сайжруулалт биш, хүртээмжийн арга хэмжээ юм.