LINUX.ORG.RU
ФорумAdmin

Не работает OpenVPN на iPhone через сотовые данные, а через wifi проводного интернета работает

 


1

2

Помогите пожалуйста настроить. 3 дня рою интернет, пробую - иссякли варианты.

Проблема: Соединение успешно устанавливается, но тоннель OpenVPN не работает при использовании мобильных данных, даже с раздачи с другого устройства других мобильных данных.

При этом подключаясь используя wifi проводного интернета обычного провайдера - всё работает.

Включал tcpdump на сервере - пакетов нет при подключении через мобильные данные. При подключении через wifi - пакеты вижу.

Не смог ничего путного добиться с MTU. Занижал его, пробовал разные варианты, какие мог нагуглить.

Пробовал делать подбор MTU, находил какие-то значения через Ping, но они не оживляли тоннель. Может быть я неправильно делал, но как находил в гугле, пробовал.

Да, читал про блокировки vpn и т.п. Но мы то с вами люди технически образованные, мы можем настроить, чтобы наши тоннели не блокировали.

Обфускацию трафика, усложнения можно предлагать, но учитывая, что клиент на iPhone, что там стандартное OpenVPN приложение и конфиг.

Другие VPN протоколы, службы не интересуют.

Сервер на digitalocean, Debian.

port 60156
proto udp
dev tun
user nobody
group nogroup
persist-key
persist-tun
# turn on on prod:
#keepalive 10 120
topology subnet
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 94.140.14.14"
push "dhcp-option DNS 94.140.15.15"
push "redirect-gateway def1 bypass-dhcp"
dh none
ecdh-curve prime256v1
tls-crypt tls-crypt.key
crl-verify crl.pem
ca ca.crt
cert server_RgP4w3L3VKHmmnzT.crt
key server_RgP4w3L3VKHmmnzT.key
auth SHA256
cipher AES-128-GCM
ncp-ciphers AES-128-GCM
tls-server
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
client-config-dir /etc/openvpn/ccd
status /var/log/openvpn/status.log
log /var/log/openvpn/openvpn.log
verb 3

tls-timeout 5

sndbuf 0
rcvbuf 0

txqueuelen 1024

#mtu-test

#tun-mtu 1300
#tun-mtu-extra 32
#push "tun-mtu 1300"
#mssfix 1300
#push "mssfix 1300"

#mssfix 1330

#sndbuf 1048576
#rcvbuf 1048576

#txqueuelen 250

#tcp-queue-limit 1024
#tcp-nodelay

клиент:

client
proto udp
# on in prod:
#explicit-exit-notify
remote xxx 65156
dev tun
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
verify-x509-name server_RgP4w3L3VKHmmnzT name
auth SHA256
auth-nocache
cipher AES-128-GCM
tls-client
tls-version-min 1.2
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256
#ignore-unknown-option block-outside-dns
#setenv opt block-outside-dns # Prevent Windows 10 DNS leak
verb 3

#tun-mtu 1300

#mssfix 1330
#sndbuf 1048576
#rcvbuf 1048576
#txqueuelen 2048
#tcp-queue-limit 1024
#tcp-nodelay

Закомментаренные строки - это моим попытки решить проблему. Разные варианты перепробовал, ничего не получается.

лог подключения сравнивал спец средством - расхождений нет при подключения из разных сетей:

[Aug 08, 2023, 17:47:11] Connecting to [xxx]:65156 (xxx) via UDPv4

[Aug 08, 2023, 17:47:11] EVENT: CONNECTING

[Aug 08, 2023, 17:47:11] Tunnel Options:V4,dev-type tun,link-mtu 1521,tun-mtu 1500,proto UDPv4,cipher AES-128-GCM,auth [null-digest],keysize 128,key-method 2,tls-client

[Aug 08, 2023, 17:47:11] Creds: UsernameEmpty/PasswordEmpty

[Aug 08, 2023, 17:47:11] Peer Info:
IV_VER=3.git::081bfebe
IV_PLAT=ios
IV_NCP=2
IV_TCPNL=1
IV_PROTO=30
IV_CIPHERS=AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305
IV_IPv6=0
IV_AUTO_SESS=1
IV_GUI_VER=net.openvpn.connect.ios_3.3.4-5176
IV_SSO=webauth,openurl,crtext


[Aug 08, 2023, 17:47:12] VERIFY OK: depth=1, /CN=cn_9XOUiq9yRzgU5l4m, signature: ecdsa-with-SHA256

[Aug 08, 2023, 17:47:12] VERIFY OK: depth=0, /CN=server_RgP4w3L3VKHmmnzT, signature: ecdsa-with-SHA256

[Aug 08, 2023, 17:47:12] SSL Handshake: peer certificate: CN=server_RgP4w3L3VKHmmnzT, 256 bit EC, curve:prime256v1, cipher: TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD

[Aug 08, 2023, 17:47:12] Session is ACTIVE

[Aug 08, 2023, 17:47:12] EVENT: GET_CONFIG

[Aug 08, 2023, 17:47:12] Sending PUSH_REQUEST to server...

[Aug 08, 2023, 17:47:12] NIP: blocking all IPv6 traffic

[Aug 08, 2023, 17:47:12] Connected via NetworkExtensionTUN

[Aug 08, 2023, 17:47:12] EVENT: CONNECTED 142.93.173.251:60156 (142.93.173.251) via /UDPv4 on NetworkExtensionTUN/10.8.0.5/ gw=[/]

Да, читал про блокировки vpn и т.п. Но мы то с вами люди технически образованные, мы можем настроить, чтобы наши тоннели не блокировали.

Другие VPN протоколы, службы не интересуют.

Противоречащие строки.

keir ★★
()
Ответ на: комментарий от keir

У меня нет противоречий. Но чтобы уточнить, я хотел сказать, что мне надо настроить на OpenVPN тоннель. Shadowsocks, l2tp, wireshark и другие протоколы/vpn не хочу рассматривать в этом топике.

zobrist
() автор топика

Да, читал про блокировки vpn и т.п. Но мы то с вами люди технически образованные, мы можем настроить, чтобы наши тоннели не блокировали.

Вас посетил Кибергулаг. Способы записываться в очередь в пятницу, чтобы в субботу пораньше освободиться можно найти тут:

Пользователи по всей России жалуются на массовый сбой в работе VPN-протоколов OpenVPN и WireGuard

https://ntc.party/t/wireguard/4968/5

И т. д.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от zobrist

Я уточню, что противоречие заключается в том, что вы хотите настроить openvpn, который блокируется. Помочь настроить протокол, который блокируется, врядли кто-то здесь сможет.

keir ★★
()
Ответ на: комментарий от Anoxemian

Могу посоветовать добавить tls-auth, сменить порт на 443, ну и перейти на tls-crypt-v2

Лично мне не помогло кстати. Помогло оборачивание openvpn в ssl или ssh, после чего провайдерский DPI терял к этому трафику интерес, благо мой коммерческий зарубежный VPN провайдер предлагает варианты подключения с обфускацией. Но вот штатный клиент iPhone наверняка такое не умеет.

Jameson ★★★★★
()
Ответ на: комментарий от Anoxemian

Ну и вдогонку, пока режут только прямой трафик от хомяка/ососа забугор. Т.е. для сохранения привычного уровня комфорта достаточно завести еще один vps поближе к дому и гнать трафик через него.

Anoxemian ★★★★★
()
Ответ на: комментарий от Anoxemian

Пробовал, там где 443/tcp работал, 443/udp не работал. Я написал не случайно, только из личного опыта. Точно здесь писал об об этом, у меня именно на подобные случаи второй инстанс ovpn на 443/tcp крутится, не раз уже пригождался. Но бывало и наоборот когда 443/tcp не робит, а NNNN/udp робит.

anc ★★★★★
()
Ответ на: комментарий от Anoxemian

Но бывало и наоборот когда 443/tcp не робит

Поясню, это варианты всяких недоделанных Captive portal + покся + роутер, народ отправляет tcp на страницу авторизации, при этом udp у них робит через masq «гуляй не хочу» :)

anc ★★★★★
()
Ответ на: комментарий от anc

Про фильтрацию мобильными и не только мобильными провайдерами OpenVPN и wireguard туннелей. Мне удалось соединиться с используемым мною коммерческим VPN провайдером выбрав в настройках «фирменного» клиента обфусцированные варианты соединения: ssl-openvpn или ssh-openvpn.

Перебор вариантов без обфускации, а именно разные варианты портов, шифрований, tcp\udp, ipv4\ipv6 и прочие пляски не помогали, соединение устанавливалось и рвалось после нескольких пакетов, всё как ValdikSS писал по ссылкам выше. Его способ пенетрации не пробовал, меня пока устраивает вариант с обфускацией.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Anoxemian

Уже понял по другому комментарию. В моем случае «Васян» админящий сервера это я. Все никак не привыкну к тому, что народ сторонние ovpn стал пользовать. :)

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Конкретно этот коммерческий VPN провайдер в списках Роскомпозора не фигурирует, так что тоннели режутся «на общих основаниях» для пограничного VPN трафика. С какой нибудь самодельной забугорной VPSкой с IP из нероссийской AS и необфусцированным OpenVPN\Wireguard будет так же. Обфускация пока спасает, так что теневые носки или заворот в ssl\ssh наше всё. К сожалению не всякий мобильный клиент так умеет «из коробки».

IMHO это всё только пограничного трафика касается, тоннели внутри Гулага у меня пока работают, аномалий не наблюдал.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

тоннели внутри Гулага у меня пока работают, аномалий не наблюдал

у меня ровно наоборот.

дом-дача (роутер-роутер) OpenVPN через МТС перестал работать недавно.

зато в забугор на VPS с OpenVPN через тот же МТС - работает и сбоев не видел.

Toxo2 ★★★★
()
Ответ на: комментарий от Jameson

Конкретно этот коммерческий VPN провайдер в списках Роскомпозора не фигурирует, так что тоннели режутся «на общих основаниях» для пограничного VPN трафика.

Например по стандартным портам.

anc ★★★★★
()
Ответ на: комментарий от anc

Например по стандартным портам.

Нене, если раньше можно было такое полагать, то теперь точно dpi таки используют, причем видно, что первын пакеты долетают, тому що копия трафика улетает в dpi, где выносится решение о блокировке. Это длительный процесс же.

Anoxemian ★★★★★
()
Ответ на: комментарий от Anoxemian

Но при этом он остается «коммерческий VPN провайдер» так что тут не DPI, а только кол-во байтиков КМК. И плюс как писал выше, стандартные порты.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Сигнатуры менять можно до бесконечности - в этом прелесть обфускации, особенно, когда ты контролишь и клиента и сервер (коммерческие vpn), тут уж никакой dpi не поможет, поэтому блокируют массовые инсталляции.

Anoxemian ★★★★★
()
Ответ на: комментарий от Anoxemian

когда ты контролишь и клиента и сервер (коммерческие vpn)

Как раз ip коммерческих как бэ известны и DPI там не нужен. А вот на личных с DPI будет уже хуже. Плюс как писал выше про порты, Васян поднимает все по инструкции с гули на стандартных портах, на забугорном хостинге, вот его и блочат.

anc ★★★★★
()
Ответ на: комментарий от anc

Например по стандартным портам.

И по нестандартным тоже. У моего «коммерческого» прова длиннющая портянка с вариантами на разных портах, и «стандартным» является 443\udp. Я все варианты пробовал. И даже по 443 и прочим портам со схожим трафиком. DPI работает же. Реально спасает только обфускация или «сворачивание мозгов» на стадии установки соединения алгоритму обнаружения по методу ValdikSS.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 2)
Ответ на: комментарий от Anoxemian

На непрерывный глубокий анализ вообще всего исходящего dataflow в таких объёмах никаких мощностей не хватит, так что это нормальная практика, принимать решение по первым N пакетам новой сессии. В Китае Великий Файрволл аналогичными методами обходится, иногда даже проще, запретом приёма RST пакетов например. Даже с поверхностным подходом нагрузка приличная, и железка выходит весьма дорогая для региональных мелких провов например. Так что ожидается очередная волна их разорения и поглощения под угрозой отзыва лицензии по мере предъявления им претензий о неисполнении новых требований к фильтрации трафика.

Вообще DPI железка глубоко «ныряет» в трафик конкретного абонента только по команде с пульта ТСПУ.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

и «стандартным» является 443\udp.

Я выше писал, попробуйте 443/tcp. Реально срабатывает даже на жутких ограничениях. Единственная «проблема», если у вас уже н-цать клиентов на xxxx/udp придется поднять второй инстанс, у меня именно так сделано, общая «база» ключей и парочка запущенных ovpn, один на xxxx/udp второй на 443/tcp.

anc ★★★★★
()
Ответ на: комментарий от anc

Я выше писал, попробуйте 443/tcp

Я же выше писал, я не деревянный, я все тривиальные уловки пробовал. И эту в том числе. Мой «коммерческий VPN провайдер» предлагает несколько десятков вариантов подключения, по tcp и по udp, с разными портами и шифрованием, естественно я их все пробовал, начиная с самых очевидных. Работает только то что с обфускацией, «наивный» вариант спрятать это в «шифрованном веб трафике» не прокатывает. Потому что DPI этим не обманешь, железка разбирает начало любого соединения, не важно по какому порту и протоколу.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от Jameson

Я же выше писал, я не деревянный, я все тривиальные уловки пробовал. И эту в том числе.

Тогда, только забаненные адреса самого прова VPN остаются.

Потому что DPI этим не обманешь, железка разбирает начало любого соединения, не важно по какому порту и протоколу.

Как она отличит валидный https от «не валидного» https? :)

anc ★★★★★
()
Ответ на: комментарий от anc

Тогда, только забаненные адреса самого прова VPN остаются.

Нет, адреса не забанены. Ты же понимаешь что к забаненым адресам не коннектилось бы вообще ничего?

Как она отличит валидный https от «не валидного» https? :)

Тем что начало установки OpenVPN соединения отличается от «валидного https». А вот если OpenVPN чем нибудь обернуть, например ssl\ssh, ДО собственно начала OpenVPN соединения, DPI не определит что это OpenVPN.

Jameson ★★★★★
()
Последнее исправление: Jameson (всего исправлений: 1)
Ответ на: комментарий от anc

Хм... Возможно вы и правы, не смотрел в эту сторону.

Блокировка vpn протоколов на ТСПУ. Там в дискуссии есть подробности что именно подвергается DPI и как, надо только свёрнутые и связанные ветки поразворачивать и тоже почитать.

Jameson ★★★★★
()
Ответ на: комментарий от anc

Ну там есть чуть чуть про IPsec, по другим протоколам аналогично я думаю, а чтобы точно правило расковырять нужно базу сигнатур для конкретной железки видеть.

Суть в том что однозначно идентифицируется используемый протокол VPN путём глубокого анализа начальных пакетов установки соединения, причём не важно по какому порту. И после однозначного подтверждения факта установки соединения устанавливается правило фильтрации ломающее обмен данными. Для каждого протокола своё. Обходится двумя способами — нарушением начального протокола путём отправки «мусорных» пакетов, что сбивает логику анализатора, либо тотальной маскировкой «запрещённого» протокола внутри другого, «не запрещённого», например в сессию ssl\https или сеанс ssh.

Jameson ★★★★★
()