Обслужване на 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 път.