OpenVPN кызматын TCP жана UDP аркылуу бир хосттон сунуштоо
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 жолу бар клиенттер үчүн жаңыртуу эмес, жеткиликтүүлүк чарасы.