Comments 12
"Нешифрованный туннель openvpn повёл себя довольно странно в обоих случаях" — медленный оказался?
Попробуйте добавить --tun-mtu 60000 --mssfix 0
Ну и для более полного тюнинга:
https://community.openvpn.net/openvpn/wiki/Gigabit_Networks_Linux
В во втором (Gbps) казалось бы с гораздо более качественным соединением упёрся в 12Mbps (для TCP) при тех же параметрах. Выставлять большие --tun-mtu имеет смысл, чтоб за 200-300 Mbps разгонять openvpn, поэтому ожидаемо, что на обычных параметрах больше 200-300 не вышло, но 12 уж слишком мало. Может перепроверю в другое время. Возможно по какой-то причине именно трафик openvpn направлялся по другому сильно медленному маршруту где-то посередине. Я проверял несколько раз, в то же время другие туннели вели себя адекватно. Хотя особо с точностью измерений не заморачивался, просто общую картину хотелось получить.
Идеальный совет! Айписек — палочка-выручалочка
Я бы не называл ipipou костылём, это скорее надстройка над ipip-over-fou.
Для решения одной задачи можно использовать множество способов, IPsec+NAT-T, тоже может подойти, как и OpenVPN, и другие.
Я бы был не прочь подробнее узнать о преимуществах IPsec+NAT-T (и остального набора непонятных мне буков), пока только вот эту статью нашёл с поверхностным описанием.
ipipou (ipip-over-fou) более нишевое решение — только для Linux, с упором на производительность и меньший оверхед, и по моим ощущениям, опередит в этом плане IPsec+NAT-T (ибо основной трафик в ядре, в накладных расходах только заголовок внутреннего IP, и лишь частично бесполезный внешний UDP). У кого есть желание может провести эксперимент. У меня личная трансцендентная неприязнь к IPsec, я с ним плохо знаком, поэтому это буду не я.
IPsec полностью реализован в ядре, потому трафик при cipher и auth == NULL будет только получать заголовок туннельного режима и UDP от NAT-T. То есть все как у вас, только стандартное и работает со всем оборудованием и ПО, что умеет IPsec в туннельном режиме, а не только со свежим Linux.
Насчет неприязни — это за счет сложности устройства этого стека протоколов, зато после понимаешь что он позволяет делать очень гибкие вещи. Ну да и ладно, я просто рассказал, что уже давно есть 1-в-1 альтернатива, которая стандартна и работает.
Про 1-в-1 только из этого комментария понятно стало. В любом случае спасибо за информацию, даже если IPsec окажется лучшим решением стоило создать альтернативу, и написать статью, чтобы об этом узнать.
OpenVPN хоть и тормоз зато универсален, можно настроить и потюнить под очень разные задачи, впрочем как и IPsec, наверно.
Я тут почитал, и как понял, если взять IPsec с NAT-T с cipher и auth=null, то это аналог ipip-over-fou безо всякой аутентификации. С ipipou же можно настроить аутентификацию соединения на том же порту (правило nftables для передачи в nfqueue работает как своего рода демультиплексор для протокола аутентификации и fou).
Тогда уж pwnat, как более совершенная версия, от того же автора, основана на том же методе.
Для прямого соединения между хостами за NAT ещё часто пользуются STUN, например, вот в этой статье автор тоже использовал IPIP-over-FOU вместе со STUN для туннелирования сквозь NAT.
Но это не всегда работает, например с самым непролазным Carrier-grade NAT, хотя при должном упорстве, если время позволяет, и его бывает можно пробить, если долго долбить перебирая порты. Я как-то пробовал и для простых случаев использовать pwnat, но не получилось.
Может дойдут руки добавить методы для обхода NAT в ipipou, пока же нужен хост с публичным IP.
Предлагаемая схема: нарезаем в приватном пространстве ipv6 кусок, резервируем часть оставшихся битов под верхний домен. Берём publicsuffixlist, нумеруем tld и прочее его содержимое, а дальше предлагаем желающим получить место в этом пространстве регать домены вида base32.tld и поднимать там сервер WebRTC и/или WebSocket. Для обычных программ делаем движок, который через драйвер tuntap умеет установить подключение.
ipipou: больше чем просто нешифрованный туннель