5

Я успешно настроил сервер OpenVPN в Debian (Raspberry Pi модель B +). С протоколом, установленным на TCP, он работает точно так, как нужно (интернет, маршрутизируемый через VPN, доступ к машинам локальной сети), однако, когда я устанавливаю протокол на UDP (который, я думаю, был бы желателен для лучшей скорости), я обнаружил, что могу Пинговать любой хост (IP-адрес или доменное имя), я могу telnet и ssh (снова IP-адрес или домен), но когда я пытаюсь открыть страницу в браузере, кажется, что устанавливает первоначальное соединение, но затем никогда не загружается.

Есть ли у вас какие-либо идеи, почему просмотр веб-страниц будет проблемой для режима UDP?

Я настроил UFW для управления iptables, основная строка конфигурации для этого была добавлена в before.rules

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Allow traffic from OpenVPN client to eth0
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT

Так как для TCP все работает правильно и почти для UDP, то я думаю, что проблема не в брандмауэре /iptables, но я могу ошибаться.

Моя конфигурация сервера openvpn

local 192.168.0.31
dev tun
proto tcp
port 1194
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig 10.8.0.1 10.8.0.2
push "route 10.8.0.31 255.255.255.255"
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.0.31 255.255.255.0"
push "dhcp-option DNS 192.168.0.1"
push "redirect-gateway def1"
push "explicit-exit-notify 3"
client-to-client
duplicate-cn
keepalive 10 120
tls-auth ta.key 0
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 1

У кого-нибудь есть идеи, почему может быть проблема?

1 ответ1

11

Эти конкретные симптомы (при использовании VPN) являются довольно распространенными симптомами, указывающими на проблему с MTU вашего пути.

Основы MTU

MTU пути (максимальная единица передачи) - это самый большой пакет, который может проходить между двумя устройствами в Интернете (или любой другой сети). Каждая ссылка на пути имеет свой собственный MTU, который может совпадать или не совпадать с другими. Общий MTU пути - это самый низкий MTU на всем пути.

Если ваш компьютер пытается отправить пакет больше, чем MTU пути, пакет данных отбрасывается при превышении прыжка, и данные никогда не поступят. В сетях с хорошим поведением ваш компьютер должен получить ответ об ошибке и знать, чтобы автоматически настраивать MTU и / или фрагментировать последующие пакеты. В сетях с плохим поведением он может быть просто отброшен.

Обнаружение пути MTU (авто) - это механизм, используемый для автоматического обнаружения MTU между вами и сервером VPN, однако он более надежен с TCP, чем с UDP в сетях с плохим поведением, поскольку TCP требует явной обратной связи, которая может сказать вам, какие пакеты не не приехать.


Причина, по которой он действует так же, как и в случае VPN-соединений, заключается в том, что заголовки инкапсуляции VPN сокращают MTU вашего туннельного соединения, а также потому, что UDP не обеспечивает обратную связь для отброшенных пакетов.

Если ваш реальный PMTU составляет, например, 1400 байтов, отправка 1400-байтового пакета через VPN может занять 1432 байта. По TCP-соединению, если вы попытаетесь отправить 1432-байтовый пакет, TCP может сказать, что он не приходит, фрагментировать его и отправить снова в виде 1400-байтового пакета и второго 32-байтового пакета (тем не менее, это грубое упрощение). С UDP это просто отбрасывается молча. Однако в обоих случаях отправка любого пакета размером менее 1400 байт будет успешной.

Вот почему SSH и telnet работают, а веб-браузер - нет. Ваша VPN снизила MTU ниже вашего значения по умолчанию, но ваша ОС не реализовала это либо потому, что сообщения об ошибках не возвращаются должным образом, либо автоматическое обнаружение PMTU не работает. Но поскольку SSH, telnet и ping используют очень маленькие пакеты (обычно <100 байт), если ваш MTU был уменьшен с 1400 до 1368 (1400 - 32), это не имеет значения, так как они все еще намного меньше, чем предел. , SSH и telnet обычно отправляют от одного байта до одной строки за раз плюс заголовки пакетов. Пакеты Ping обычно имеют размер до 64 байтов плюс заголовки пакетов, что опять же намного меньше, чем у любого нормального MTU (1400+)

Изначально веб-браузер подключается, поскольку пакеты DNS, TCP SYN/ACK и HTTP-запросы обычно намного меньше, чем 1400 байт, но как только веб-сайт пытается отправить реальную веб-страницу, он будет использовать полноразмерные пакеты, которые затем получат молча выбрасывают по пути.


Решение проблемы

Есть простой (обманчивый) способ, и другой путь, который включает в себя выяснение, в чем проблема на самом деле.

Обманчивый способ установить MTU намного ниже вручную - например, на 1000, так что все будет соответствовать даже уменьшенному MTU VPN. Само по себе это хороший тест, чтобы увидеть, является ли MTU проблемой.

Лучшим способом было бы выяснить, в чем заключается проблема, и устранить ее. Проблемы с автоматическим обнаружением MTU могут возникать из-за дрянного сервера или интернет-провайдера, с которым вы ничего не можете сделать, или локальных проблем с брандмауэром / конфигурацией, которые вы можете исправить. Возможно, ваши правила маршрутизации OpenVPN и брандмауэра не позволяют ICMP-сообщениям об ошибках возвращаться на ваш компьютер.

Промежуточным методом будет выяснить истинный максимальный MTU и установить его вручную - вы можете начать с чего-то небольшого, например 1000 байтов, и работать вверх, чтобы найти максимальное значение, которое работает. По сути, подключите вашу VPN с использованием UDP, а затем пропустите что-нибудь через VPN с помощью команды ping -f <server address> -l <packet size> и увеличивайте размер пакета до тех пор, пока он не перестанет работать - либо по таймауту, либо по ошибке.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .