Предисловие
В статье будут рассмотрены три независимых варианта прохождения трафика транзитом с помощью:
У меня провайдер заблокировал мой openvpn. Сначала обычный провайдер, а потом и мобильный тоже. Это был обычный vds сервер за рубежом с openvpn. Использовался исключительно в личных целях. После блокировки я просто решил проверить, а будет ли работать doublevpn, так как у меня был сервер еще и в России. Оказалось, что все отлично работает с помощью double. Суть этой технологии в том, что интернет‑трафик проходит через два сервера вместо одного. Об этом хорошо забытом инструменте и пойдет речь в статье, возможно, кому‑то это будет полезно. Так же я в статье на всякий случай рассмотрел варианты туннелировать трафик и с помощью vtun или socks5 прокси.
Вариант I. DoubleVPN
Конечно, первое, что пришло в голову - это просто соединить два сервера в России и в другой стране с помощью openvpn. И это получилось без проблем. Вот ниже мое решение:
Шаг первый. Установка openVPN на обоих серверах
Все, что я пишу, подходит так или иначе для любых *nix серверов, будь то ubuntu, centos, fedora, rocky и т.д.
Установить можно openvpn готовым скриптом, например, вот таким:
https://github.com/Nyr/openvpn-install
После того как вы запустили скрипт на обоих серверах, можно перейти к настройкам каждого из них.
Шаг два. Настройка на зарубежном VDS
На сервере в стране Х настройка очень простая. После того как вы запустили вышеуказанный скрипт и openvpn установился, все что нужно сделать - это отредактировать файл конфигурации, замените его следующим содержимым.
/etc/openvpn/server/server.conf
port XXXX # Порт на котором у вас работает openvpn
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-crypt tc.key
remote-cert-tls client
server 10.100.39.0 255.255.255.0
keepalive 10 120
persist-key
persist-tun
verb 3
sndbuf 0
rcvbuf 0
push "route 10.100.39.0 255.255.255.0"Далее сделайте рестарт опенвпн сервера:
systemctl restart openvpn-server@server.serviceИ скопируйте клиентский ключ, который был создан при установке на российский VDS. Например, с помощью scp.
На этом всё. Настройка зарубежного сервера завершена.
Шаг три. Настройка российского VDS.
На российском vds после установки openvpn из скрипта уже работает впн-сервер (10.8.0.0/24). Мы его трогать не будем. Все что нам надо сделать - это запустить на российском vds еще и зарубежного open-vpn клиента.
Редактируем /etc/sysctl.conf
Втыкаем следующие строки:
net.ipv4.ip_forward=1
net.ipv4.conf.tun0.rp_filter=0
net.ipv4.conf.tun1.rp_filter=0Строки net.ipv4.conf.tun0.rp_filter=0 и net.ipv4.conf.tun1.rp_filter=0 отключают проверку reverse path filtering для интерфейсов tun0 и tun1 соответственно. Можно ребутнуть сервер или ввести соответствующие команды.
Редактируем файл:
/etc/iproute2/rt_tablesИ добавляем в него строку:
150 vpn_netЗдесь подробное объяснение зачем и что мы делаем (можно не читать)
Файл /etc/iproute2/rt_tables служит для определения имен пользовательских таблиц маршрутизации в Linux-системах.
Таблицы маршрутизации: Представьте, что у вас есть несколько маршрутов, по которым пакеты данных могут перемещаться в вашей сети. Таблицы маршрутизации позволяют организовать эти маршруты в группы, что упрощает управление и настройку сетевых соединений.
-
Зачем нужны пользовательские таблицы:
Разделение трафика: Вы можете направить разные типы трафика по разным маршрутам. Например, весь трафик VPN можно отправить через определенную таблицу, а остальной трафик — через другую.
Управление политиками: Таблицы могут использоваться для реализации различных сетевых политик, таких как маршрутизация на основе качества обслуживания (QoS) или балансировка нагрузки.
Управление несколькими сетевыми интерфейсами: Если у вас несколько сетевых интерфейсов, вы можете использовать разные таблицы для каждого из них.
Что значит число 150 и строка 150 vpn_net?
Число: Это просто уникальный номер, который вы присваиваете своей таблице. Вы можете выбрать любое число, кроме тех, которые уже зарезервированы системой (например, 255, 254, 253, 0).
Строка: Строка в формате "число имя_таблицы" связывает числовой идентификатор с понятным именем. В данном случае, вы создаете таблицу с именем "vpn_net" и присваиваете ей номер 150.
Зачем добавлять такую строку?
Предположим, у вас есть VPN-соединение, и вы хотите, чтобы весь трафик, направленный в VPN, проходил через это соединение. Вы можете создать отдельную таблицу маршрутизации для VPN-трафика и добавить в нее соответствующие маршруты. Затем, используя правила iptables или другие механизмы, вы можете перенаправлять весь трафик, предназначенный для VPN, в эту таблицу.
Теперь нам надо создать два скрипта, которые будут выполняться при старте зарубежного openvpn клиента и при остановке.
/etc/openvpn/server1_up.sh
/sbin/ip rule add from 10.8.0.0/24 table vpn_net
/sbin/ip route add default dev tun1 table vpn_net/etc/openvpn/server1_down.sh
/sbin/ip rule del from 10.8.0.0/24 table vpn_net
/sbin/ip route del default dev tun1 table vpn_netНа оба скрипта вешаем
chmod +x /etc/openvpn/server1_up.sh и chmod +x /etc/openvpn/server1_down.sh
Теперь нам надо взять клиентский конфиг, который мы взяли на зарубежном сервере. Сменить ему расширение: вместо .ovpn написать .conf
mv my_client.ovpn my_client.conf
Положить в папку: /etc/openvpn/client и отредактировать примерно таким образом:
/etc/openvpn/client/my_client.conf
client
dev tun
proto udp
remote XX.XX.XX.XX YY YY # IP и порт зарубежного VDS
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth SHA512
cipher AES-256-CBC
verb 3
script-security 2
up "/etc/openvpn/server1_up.sh"
down /etc/openvpn/server1_down.sh
# До этого место. Дальше не трогаем.
<ca>
-----BEGIN CERTIFICATE-----
wIBAgIJAL0WnyzV8N87MA0
......Указываем, что у нас будут стартовать скрипты при запуске и остановке клиента.
Запускаем опенвпн-клиент
systemctl start openvpn-client@my_client
Добавляем новое правило iptables
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
А старое nat правило, которое добавил установщик Nyr/openvpn-install, удаляем. Сохраняем iptables тем способом, которые есть в вашем *nix, так чтобы они сработали после загрузки. И делаем автостарт нашего клиента:
systemctl enable openvpn-client@my_client
Проверяем, что все работает, с помощью команд
ip route show table all|grep vpn_net
ip rule list| grep vpn_net
ip addressС помощью openvpn-install создаем необходимое кол-во опенвпн ключей.
Вариант II. OpenVPN + Vtun
В первом варианте у нас был openvpn + openvpn, но нам ничего не мешает соединить, например, российский VDS и зарубежный с помощью старого и доброго vtun. И точно так же туннелировать трафик
Шаг первый. Установка vtun на обоих серверах
Vtun можно собрать из исходников. Будем считать, что вы на обоих серверах vtun и openvpn поставили. Форвард пакетов разрешили, см. настройки у варианта № 1.
Шаг второй. Запуск vtun сервера на зарубежном сервере
Для сервера можно взять примерно такой конфиг и положить его в файл /etc/vtund.conf:
/etc/vtund.conf
options {
port 5000;
ifconfig /sbin/ifconfig;
}
# Default session options
default {
proto tcp; # TCP protocol
compress no; # Compression is off
encrypt no; # ssh does the encryption
speed 0; # By default maximum speed
keepalive yes;
stat yes;
}
my_tunnel {
passwd MY_STRONG_PASS; # Password
type tun; # IP tunnel
proto tcp; # TCP protocol
up {
ifconfig "%% 10.3.0.2 pointopoint 10.3.0.1 mtu 1500";
};
down{
ifconfig "%% down";
};
}Открываем порт 5000 и добавляем SNAT правила, где to-source XX.XX.XX.XX это белый IP в стране Х.
-A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT
-A POSTROUTING -s 10.3.0.0/24 -j SNAT --to-source XX.XX.XX.XXЗапускаем:
vtund -sПроверяем, должен появиться интерфейс tun и ip.
ip addressШаг три. Запуск vtun клиента и openvpn в России
Openvpn ставим как обычно, см. вариант 1.
А вот настройки vtun на российском сервере
/etc/vtund.conf
options {
port 5000;
# Path to various programs
ifconfig /sbin/ifconfig;
ip /sbin/ip;
}
# Default session options
default {
compress no;
encrypt no;
speed 0;
keepalive yes;
stat yes;
}
my_tunnel {
passwd PASS; # Password
type tun; # IP tunnel
proto udp; # TCP protocol
up {
# 10.3.0.1 локальный ip
# 10.3.0.2 удаленный ip
ifconfig "%% 10.3.0.1 pointopoint 10.3.0.2 mtu 1500";
ip "rule add from 10.8.0.0/24 table vpn_net";
ip "route add default dev %% table vpn_net";
};
down{
ip "rule del from 10.8.0.0/24 table vpn_net";
ip "route del default dev %% table vpn_net";
ifconfig "%% down";
};
}Запускаем командной:
vtund my_tunnel ip_адрес_вашего_зарубежного_сервераТочно так же как и с опенвпн маскарадим трафик:
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
После этого все должно заработать. Если не работает, то убедитесь, что пинги проходят между 10.3.0.1 и 10.3.0.2 и смотрите логи.
Конфигурация vtun дана для примера. Там по желанию можно и трафик передавать по udp, шифровать, сжимать и т.д.
Вариант III. OpenVPN + tun2proxy
В третьем варианте мы закинем openvpn трафик в socks5 и так же выпустим наружу. Хотя с помощью tun2proxy можно туннелировать и в http прокси, поэтому даже зарубежный VDS не обязателен, достаточно иметь ssh доступ в стране Х или какую-нибудь http-проксю.
https://github.com/tun2proxy/tun2proxy
Tun2proxy - это туннельный интерфейс для HTTP- и SOCKS-прокси на Linux, Android, macOS, iOS и Windows:
HTTP‑прокси (без аутентификации, базовая и дайджест‑аутентификация)
Поддержка SOCKS4 и SOCKS5 (без аутентификации, аутентификация по имени пользователя и паролю)
Поддержка SOCKS4a и SOCKS5h (через функцию виртуального DNS)
Минимальная настройка конфигурации для маршрутизации всего трафика
Поддержка IPv4 и IPv6
Механизм обхода GFW для определенных случаев использования
Поддержка SOCKS5 UDP
Встроенная поддержка проксирования DNS через TCP
Установка и настройка
Вся установка и настройка делается на сервере в России. На первом сервере. На втором (зарубежном сервере) лишь нужен ssh аккаунт для создания socks5 прокси.
Я поставил rust последнюю версию
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | shИ далее запустил установку
$HOME/.cargo/bin/cargo install tun2proxyИ он благополучно установился, проверил что все ок:
$HOME/.cargo/bin/tun2proxy --helpПочитал справку по использованию. Дальше я создал для проверки ssh socks5 tcp динамическую проксю такой командой:
ssh -D 14017 -q -C -N my-socks5-user@my-remote-server.comПовесил на порт 14017. По хорошему, надо было бы udp socks5 делать (но мы же не ищем легких путей), и для теста так интереснее.
Далее запустил tun2proxy командой:
$HOME/.cargo/bin/tun2proxy --tun tun1 --proxy "SOCKS5://127.0.0.1:14017"Потом поднял сетевой интерфейс, т.к. по умолчанию он отключен:
ifconfig tun1 upЭто и есть фишка tun2roxy, что он создает сетевой интерфейс. То есть если набрать, например ifconfig, то при включенном tun2roxy можно увидеть еще одну "сетевую карту", которую он создал на основе прокси. А если есть tun1, то можно уже делать все, что мы захотим, почти так же как и в предыдущих вариантах.
Проверил, что все работает такой командой:
curl --interface tun1 ifconfig.meВ ответ получил IP адрес своего зарубежного сервера. Все окей, трафик завернулся в tun1 и вышел из-за рубежа.
Теперь надо заставить openVPN ходить таким же макаром, чтобы выпустить наружу трафик openVPN через tun1 & socks5.
/etc/sysctl.conf
net.ipv4.ip_forward=1
net.ipv4.conf.tun0.rp_filter=0
net.ipv4.conf.tun1.rp_filter=0
net.ipv4.conf.all.route_localnet=1В файл:
/etc/iproute2/rt_tablesДобавил строчку:
150 vpn_netИ ввел команды:
/sbin/ip rule add from 10.8.0.0/24 table vpn_net
/sbin/ip route add default dev tun1 table vpn_netИ дальше прикол, если просто замаскарадить трафик командой iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE , то работать не будут DNS запросы, ведь они идут не по TCP. Как я и писал выше, обычный socks5 tcp прокси не очень-то и подходит. Так что перед тем как маскарадить, мне пришлось поставить dnsproxy и запустить его командой:
./dnsproxy -u 8.8.8.8:53И сам tun2proxy на этот раз запустил командой, что указана выше, но с доп. ключом --dns direct и так же изменил настройку клиентского опенвпн, чтобы он с DNS запросами шел ко мне локально на сервер.
После этого все заработало и openvpn клиент вышел наружу через этот туннель.
Комментарии (93)
VenbergV
22.09.2024 13:42+10Вы уж простите, но есть пара замечаний.
1. Туннелировать трафик надо начинать от клиента. Т.к. фильтрация трафика начинается сразу на стороне провайдера. Просто еще не все провайдеры это исполняют в полном объеме. И у вас возникла ошибка выжившего.
2. При довольно серьезном подходе к написанию статьи все же следовало бы отказаться от устаревших "комбайнов" по установке Openvpn. Ubuntu 24/Debian 12, с настроенным nftables будут сломаны. Ну иdhключи при использованииecкриптографии ненужны. Так же easyrsa уже можно не использовать пару лет. Т.к. возможно обойтись fingerprint.
Rilkener Автор
22.09.2024 13:42+1Туннелировать трафик надо начинать от клиента. Т.к. фильтрация трафика начинается сразу на стороне провайдера. Просто еще не все провайдеры это исполняют в полном объеме. И у вас возникла ошибка выжившего.
А разве провайдеры фильтруют трафик, который идет на российский IP, в рос. датацентр?
M_AJ
22.09.2024 13:42+5Время от времени блокировали. Люди в чатах жаловались на массовый отвал ВПН внутри страны.
aborouhin
22.09.2024 13:42+3Как владелец внутрироссийского OpenVPN, на опыте подтверждаю, - бывало, но эпизодически. Самые системные проблемы были с Калининградом (но туда были только эпизодические командировки, так что тоже длительной статистики нет).
Хуже другое - пользователи VPN тоже имеют привычку пересекать гос. границу, и тогда на пути к российскому серверу на них действуют все трансграничные блокировки. Вручную подключаться к разным серверам из России и из-за границы - неудобный костыль (для технически неграмотных пользователей часто непреодолимый), а раскидывать их на автомате по GeoIP - нетривиальная задачка.
Sap_ru
22.09.2024 13:42Совершенно точно и однозначно да. В большинстве регионов РФ заблокированы и внутрироссийские VPN. Количество таких регионов и провайдеров расширяется. Официально VPN теперь только по белым спискам от организаций.
qenoamej
22.09.2024 13:42+1В большинстве регионов РФ заблокированы и внутрироссийские VPN.
Заблокированы vpn-протоколы или vpn-сервисы?
У меня три офиса в разных регионах РФ соединены через wireguard, ничего не блокировалось даже временно, за доступностью следит zabbix круглосуточно.
Pilotv
22.09.2024 13:42+2А Вы простите уверены в этом утверждении? Ибо выходит что в большинстве регионов полегли корпоративные VPN сервисы , а про это никто и не знает. Про формирование каких то белых списков тоже никто не слышал . Ну у про поломку всякий домашних решений формата VPN дом-дача , тоже нет криков
uuger
22.09.2024 13:42+3Про формирование каких то белых списков тоже никто не слышал
расскажите этим никто про поиск в интернете
О принятии мер в отношении сервисов обхода ограничения доступа к противоправному контенту
О принятии мер в отношении сервисов обхода ограничения доступа к противоправному контенту
3 сентября 2021 года
2 сентября в соответствии с правилами централизованного управления сетью связи общего пользования, утвержденными постановлением Правительства Российской Федерации от 12 февраля 2020 года № 127, было принято решение о блокировке еще 6 нарушающих российское законодательство сервисов VPN (Hola!VPN, ExpressVPN, KeepSolid VPN Unlimited, Nord VPN, Speedify VPN, IPVanish VPN).
Использование сервисов обхода блокировок приводит к сохранению доступа к запрещённой информации и ресурсам, создаёт условия для незаконной деятельности, в том числе связанной с распространением наркотиков, детской порнографии, экстремизма и склонением к суициду.
Для исключения нарушения работы программного обеспечения и приложений, не нарушающих российское законодательство и использующих VPN-сервисы в технологических целях, были сформированы «белые списки» для предотвращения их блокировки.
Роскомнадзором получены сообщения от 64 отраслевых организаций, 27 из которых используют упомянутые VPN-соединения для обеспечения 33 технологических процессов. Представлены более 100 ip-адресов с целью исключения их из политик ограничения доступа.
Ранее Роскомнадзор по тем же основаниям ограничил работу VyprVPN и OperaVPN.
Применение технических средств против сервисов обхода блокировок является эффективным и оправданным механизмом. Включенные в «белые списки» технологические процессы российских компаний продолжили бесперебойную работу при полной блокировке VPN-cервисов, нарушающих законодательство РФ.
Время публикации: 03.09.2021 10:10https://rkn.gov.ru/news/rsoc/news73836.htm
или
https://web.archive.org/web/20231004090648/https://rkn.gov.ru/news/rsoc/news73836.htm
Pilotv
22.09.2024 13:42+1Ваш комментарий какое отношение имеет к этой Вашей фразе "Совершенно точно и однозначно да. В большинстве регионов РФ заблокированы и внутрироссийские VPN." В постановлении на которое Вы ссылаетесь речь идёт про плокировку сервисов ! VPN для обхода блокировок . Какой обход блокировок для внутрироссийских VPN ? И потом Вам уже ре один человек отписал что у них VPN на много толчек во многих регионах работает . Так что совершенно точно , что в большинстве регионов РФ внутрироссийские VPN не заблокированы.
uuger
22.09.2024 13:42+1В постановлении на которое Вы ссылаетесь речь идёт про плокировку сервисов ! VPN для обхода блокировок . Какой обход блокировок для внутрироссийских VPN ?
попробуйте вчитаться внимательнее:
программного обеспечения и приложений, не нарушающих российское законодательство и использующих VPN-сервисы в технологических целях
В переводе с бюрократического на русский: составлены белые списки адресов / диапазонов адресов VPN шлюзов, которые должны оставаться доступными даже в случае ввода жестких блокировок по типу трафика.
Я напомню, что "государственная" база геолокаций IP собирается только 3 недели, а общедоступные сервисы часто содержат неточные данные и веерные блокировки приводят к масштабным сбоям в рунете. Чтобы такого не просиходило, весь крупный бизнес ещё к началу 2022 года подал списки адресов своей "критической инфраструктуры" в РКН. То, что не задевает мелочёвку означает только то, что их адреса достаточно точно мэппятся с российскими координатами
dsoastro
22.09.2024 13:42+3Так от клиента он в openvpn заварачивается до российского сервера, разве нет?
Sap_ru
22.09.2024 13:42РКН блокируют OpenVPN, как протокол, вне зависимости от того, куда подключаетесь.
lex899
22.09.2024 13:42+2Не блокирует. Наблюдали кратковременные проблемы при начале блокировок, но сейчас все работает.
lea
22.09.2024 13:42+1Только что протестил. OpenVPN (proto udp). Пакеты в сторону сервера уходят, обратно - по нулям.
Rilkener Автор
22.09.2024 13:42+1А сервер где физически находится? В России? И как называется дата-центр куда не доходят пакеты?
lea
22.09.2024 13:42+2Сервер не в РФ (название ДЦ говорить не буду, извините).
До 23 августа всё работало без проблем. Затем какое-то время (не меньше недели) наблюдалось такое поведение: vpn подключается, но как только кол-во трафика, полученное клиентом от сервера, превышает 4 килобайта - клиент перестает получать пакеты. Сейчас даже 4 кб входящего трафика нет, режут соединение сразу.
Дальше подробно не следил, т.к. сделал собственный примитивный обфускатор трафика. Через него и продолжаю пользоваться openvpn.
outlingo
22.09.2024 13:42+2Сервер не в РФ
Ну вот сами и ответили. Если клиент и сервер в РФ - все замечательно работает. Да, бывали глюки - но подозреваю скорей из-за самодеятельности провайдеров которые пускали трафик РФ-РФ через внешние каналы.
lex899
22.09.2024 13:42+1У нас 40+ каналов по РФ поднято прямо сейчас (соответственно разные города и провайдеры), за рубеж всего один канал (Германия), с ним тоже проблем нет, протокол udp. Канал с tcp у коллег до Германии резали одно время.
lea
22.09.2024 13:42И вы не обращались в ркн для внесения ваших vpn подключений в белый список? Или провайдер в ваших интересах?
lex899
22.09.2024 13:42+2Мы не обращались, но интернет везде заведён на юрлиц, могу предложить что блокировки каким-то образом нацелены на физиков. Либо нам сильно везёт.
Моя личная линия openvpn (тоже Германия, ip физлица) тоже работает, Америка с домашнего провайдера работает, с мобильного блокируется.
Мне кажется что мелких vpn сетей у бизнеса на Руси в том или ином виде довольно много, повально их резать может быть вредно.
arachnid
22.09.2024 13:42+3на тспу уже спланировано выделить еще 60 миллиардов - так что охватят всех. тем более, что режут по сигнатурам протоколов, а не по адресам
arachnid
22.09.2024 13:42+3ЛО, ростело. блокируются протоколы openvpn, wg - и неважно, куда. за границу или внутри страны. видел уже не одно сообщение, что у все большего количества домовых провайдеров появляется тспу
lex899
22.09.2024 13:42+1Навскидку проверил ростелеком - Курган, Пермь, ХМАО, Новосибирск, Томск, Салехард, Тюмень работают. В ЛО у нас нет площадки, надо поспрашивать у коллег. Возможно для физиков и юриков по разному работает.
arachnid
22.09.2024 13:42+2скорее, просто пока у государства нет такого количества тспу для охвата всех провайдеров. у меня openvpn отвалился примерно месяц назад. именно как протокол
andersong
22.09.2024 13:42Интересно, сколько нужно ТСПУ для полного охвата?
arachnid
22.09.2024 13:42+1все зависит от пропускной способности сей коробочки. судя по тому, что нет никаких характеристик - "тайна сия велия есть". но полагаю, что пока на всё не хватает. иначе бы в критических ситуация не включали их в работу по белым спискам
uuger
22.09.2024 13:42+1просто пока у государства нет такого количества тспу для охвата всех провайдеров
при этом, само государство утверждает обратное:
РКН: все узлы связи в России на 100% оборудованы средствами противодействия угрозам на базе оборудования ТСПУarachnid
22.09.2024 13:42+1ну кто мы такие, что бы не верить государству. хотя на что тогда оно же планирует потратить 60 лярдов?
uuger
22.09.2024 13:42+2есть подозрение, что не все
йогурты одинаково полезныузлы ТСПУ одинаково производительны - на первых этапах развертывания было достаточно уметь блокировать по реестру, затем потребовалось уметь работать с сигнатурами на основе заголовков пакетов, потом дошло дело до анализа паттернов в полном трафике. Предполагаю, что 60 ярдов планируют потратить на обновление парка железа до последнего (на текущий момент) поколенияarachnid
22.09.2024 13:42+1соглашусь. только добавлю, что посольку неизвестно ничего, то наши предположения, к сожалению, имеют очень вероятностный характер...
HomeMan
22.09.2024 13:42Полностью с Вами согласен.
И не понимаю зачем им нужен OVPN для каких-то обходов? В количестве 2-ух штук.
OVPN прекрасен своей маршрутизацией, и прочими CCD. Для работы это просто идеал.
Кстати, там в скрипте ключ DH просто гвоздями прибит.
А для обхода кочек есть прекрасный три икса рей на одном VPS.
HomeMan
22.09.2024 13:42# Create the DH parameters file using the predefined ffdhe2048 group echo '-----BEGIN DH PARAMETERS----- MIIBCAKCAQEA//////////+t+FRYortKmq/cViAnPTzx2LnFg84tNpWp4TZBFGQz +8yTnc4kmz75fS/jY2MMddj2gbICrsRhetPfHtXV/WVhJDP1H18GbtCFY2VVPe0a 87VXE15/V8k1mE8McODmi3fipona8+/och3xWKE2rec1MKzKT0g6eXq8CrGCsyT7 YdEIqUuyyOP7uWrat2DX9GgdT0Kj3jlN9K5W7edjcrsZCwenyO4KbXCeAvzhzffi 7MA0BM0oNC9hkXL+nOmFg/+OTxIy7vKBg8P+OxtMb61zO7X8vC7CIAXFjvGDfRaD ssbzSibBsu/6iGtCOGEoXJf//////////wIBAg== -----END DH PARAMETERS-----'этот DH вот из того скрипта.
Я в чём то ошибся?
mayorovp
22.09.2024 13:42+2Это не ключ, а набор параметров. Ключей как входных данных в DH вообще нет.
undefined400
22.09.2024 13:42+6Можно же обойтись встроенной функцией tun2proxy --dns virtual? Когда поступит dns пакет с запросом в tun, Tun2proxy прорезолвит адрес, назначив его из приватного пространства 198.18.0.0/15 в ответном днс пакете.
В дальнейшем, при запросе соединения на полученный адрес, он будет сопоставлять его с реальным адресом по своей внутренней таблице.
xsash
22.09.2024 13:42+4Тоже пришлось использовать промежуточный VPS, но сделал проще. Настроил UDP редирект с VDS1 на VDS2
Rilkener Автор
22.09.2024 13:42Спасибо. А как делали редирект? Просто DNAT? Можете рассказать?
xsash
22.09.2024 13:42+6Проще, собрал бинарь и запустил как сервис
https://github.com/justinb01981/tiny-webrtc-gw/blob/master/udp_redirect.c./udp_redirect 0.0.0.0 1234 xxx.xxx.xxx.xxx 1234Кроме смены IP на VDS еще пришлось "пофиксить" MTU в конфиге OpenVPN. Добавил
mssfix 1200
avelor
22.09.2024 13:42+1Мне кажется два правила в айпитаблях - dnat и snat проще. Пример из интернетов
iptables -t nat -A PREROUTING -p tcp --dport 3000 -j DNAT --to-destination хост2:3000 iptables -t nat -A POSTROUTING -p tcp -d хост2 --dport 3000 -j SNAT --to-source хост1
gudvinr
22.09.2024 13:42+1Но зачем...
У вас так трафик ходит из ядра в юзерспейс и наоборот, когда можно просто через маршрутизацию. Тогда он вообще из ядра не будет выходить, так намного эффективнее и пропускная способность будет выше
xsash
22.09.2024 13:42+1Нужно было любое рабочее решение в тот момент, iptables сразу не взлетел в тот момент. Надо найти время и поковырять его еще раз
undefined400
22.09.2024 13:42+1Можно еще проще: на промежуточном поставить аналог gdpi... Но, если сделали blackhole <IP> на уровне провайдера - тогда зарубежный VPS
artsavel
Просто трафик с вашего цода в РФ пока не попадает под фильтрацию, но Вы молодец, расскажите об этом им)
Rilkener Автор
Ха)
На мой взгляд, даже если датацентру стукнет в голову начать заниматься этой ерундой, то запаряться они фильтровать вариант № 3. Особенно если будет много socks5 + балансировщик.
Gansterito
Ни дата-центр, ни вышестоящие операторы не принимают решения о блокировке трафика по ФЗ-90. Кого, когда и в какой порт ТСПУ включать решает местный ГРЧЦ. И дата-центры через ТСПУ ШПД не включаются, а именно там режется существенная часть протоколов и замедляется Youtube.
undefined400
Я, конечно, не знаю, но на на моём VPS в российском ДЦ (крупный хостинг), все замедлялось/блокировалось без соответсвующих утилит (firefox + ssh -D 1080 ). С утилитой все начинало работать
Gansterito
Значит у этого хостинга есть аплинк, ВЕСЬ стоящий за ТСПУ. Вариант менее вероятный - хостинг еще имеет операторскую лицензию и живых абонентов, и его весь заставили ТСПУшится.
Metotron0
У некоторых отдельные адреса то блокируются, то перестают. Тот же рутрекер. Это я не знаю, как объясняется.
DennisP
А вы вообще пробовали выходить в интернет только через ВПН на рос. сервере? Вполне возможно, что внешний сервер вам и не нужен
Gansterito
Нужно разделить фильтрацию по ФЗ-139/149 (что-то там про защиту детей от вредоносного контента) и ФЗ-90 (так называемый суверенный интернет).
VPN, т.е. “application” по сигнатурам блокируется по ФЗ-90 на ТСПУ, точнее - на ТСПУ ШПД. ЦОДы в РФ этим ТСПУ не закрываются, так что схема будет жить, пока не заблокируют или не замедлят российское или зарубежное плечо.
UranusExplorer
Законопроект № 1214072-7:
Gansterito
Не увидел упоминания ЦОДов.
UranusExplorer
ЦОДы подключены к точкам обмена трафиком.
Gansterito
Все ЦОДы???
mayorovp
А куда ещё ЦОД может быть подключен? Или точка обмена трафиком, или обычный провайдер. И там, и там ТСПУ.
Gansterito
К сожалению, это Ваши заблуждение. Не в том, куда подключены ЦОДы, в другом.
ГРЧЦ, как и многие гос учреждения, сильно оторваны от реальности. Обязав операторов устанавливать ТСПУ ШПД в сторону абонентских сегментов, они с удивлением обнаружили, что огромная часть трафика абонентов через ТСПУ не проходит. Выяснилось, что через точки обмена трафиком абоненты получают трафик Google, CloudFlare и еще пары зарубежных контентщиков. Получалось так: некий оператор берет IP-транзит у Ростелеком, и там, наверху, стоит ТСПУ. Но осталась лазейка для трафика.
Именно поэтому вдогонку делали требования для IX, чтобы увидеть весь трафик.
А причем тут ЦОДы? Не при чем. Поставить ТСПУ - это полдела, нужно на нем получить конкретный порт под конкретного участника (для IX) или присоединенного оператора (для IP-транзита) или для своего сегмента (если абоненты свои). Вот под ЦОДы ГРЧЦ портов не выделяет, т.к. основная задача - видеть трафик абонентов, а в ЦОДах их официально нет.
Итого: ЦОДы официально не ТСПУшатся, если их трафик и попадает на ТСПУ, то вместе с другим, абонентским трафиком.