При передаче больших объемов данных с помощью клиента OpenVPN через определенное интернет-соединение, интернет-соединение из сети серверов OpenVPN полностью прерывается. Другие клиенты OpenVPN не влияют на производительность при передаче тех же данных.
Сеть серверов имеет асинхронное интернет-соединение со скоростью исходящего потока 9600 Кбит / с (измерено с iperf) и около 50 Мбит / с в нисходящем направлении.
Передача с сервера OpenVPN конкретному клиенту использует только около 2-3 МБит / с из доступных ~ 10 МБит / с восходящего потока. У клиента гораздо больше нисходящих потоков, так что это не может быть проблемой.
Сначала я обнаружил, что пакеты OpenVPN, идущие к этому конкретному клиенту, фрагментируются, поэтому я вручную настроил tun-mtu настройка в OpenVPN с использованием следующей конфигурации на стороне сервера:
tun-mtu 1492
push "tun-mtu 1492"
Это не было корнем проблемы, поэтому я попытался настроить формирование трафика с помощью tc на маршрутизаторе Linux между модемом и серверной сетью.
Это сценарий, который я использую для настройки формирования трафика (eth2 это интерфейс, подключенный к Интернету):
tc qdisc add dev eth2 root handle 1: htb default 12
tc class add dev eth2 parent 1: classid 1:1 htb rate 9500kbit
tc class add dev eth2 parent 1:1 classid 1:10 htb rate 2Mbit ceil 9500kbit prio 0
tc class add dev eth2 parent 1:1 classid 1:11 htb rate 2Mbit ceil 9500kbit prio 1
tc class add dev eth2 parent 1:1 classid 1:12 htb rate 2Mbit ceil 9500kbit prio 2
tc class add dev eth2 parent 1:1 classid 1:13 htb rate 1Mbit ceil 9500kbit prio 3
tc class add dev eth2 parent 1:1 classid 1:14 htb rate 1Mbit ceil 3Mbit prio 4
# match tcp ack packets
tc filter add dev eth2 parent 1:0 protocol ip prio 0 u32 \
match ip protocol 6 0xff \
match u8 0x05 0x0f at 0 \
match u16 0x0000 0xffc0 at 2 \
match u8 0x10 0xff at 33 \
flowid 1:10
# match OpenVPN traffic in both directions
tc filter add dev eth2 parent 1:0 prio 1 u32 match ip sport 1194 0xffff match ip protocol 0x11 0xff flowid 1:14
tc filter add dev eth2 parent 1:0 prio 2 u32 match ip dport 1194 0xffff match ip protocol 0x11 0xff flowid 1:14
# match traffic using TOS flags to three bands mainly according to man 8 tc-prio
tc filter add dev eth2 parent 1:0 prio 3 u32 match ip tos 0x10 0x18 flowid 1:11
tc filter add dev eth2 parent 1:0 prio 4 u32 match ip tos 0x02 0x1E flowid 1:13
tc filter add dev eth2 parent 1:0 prio 5 u32 match ip tos 0x08 0x18 flowid 1:13
Цель заключалась в том, чтобы установить приоритет всего трафика выше, чем трафик OpenVPN, и дополнительно предоставить лишь небольшую часть доступной полосы пропускания.
Это все равно не помогло. Я не мог понять никаких повторных передач при анализе трафика с помощью tcpdump.
Говоря «сетевое соединение полностью разрывается», я имею в виду, что у других интернет-соединений почти всегда истекает время ожидания, а скорость передачи очень низкая (ниже 1 кбит / с). Попытка использовать Интернет другими способами, кроме соединения OpenVPN, не влияет на работающую передачу данных OpenVPN, которая все замедляет.
«Медленная» скорость передачи OpenVPN не является реальной проблемой, в отличие от «разорванного» подключения к Интернету в сети серверов.
Какие причины могут быть причиной поломки сети?
Где я мог продолжить расследование?