Служење 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 пат.