Если NAT сохраняет порт (port-preserving NAT), то рандомным он не будет. Реализация NAT на Linux со стандартными настройками сохраняет порт.
Мой провайдер не может связаться с Мегафоном, а при личном обращении меня попросили обращаться к провайдеру — NOC с частными лицами не работает.
По поводу свежего Iperf3 3.13 - на Win11 он действительно адекватно работает без доп опций, но вот на Win7 все равно глючит без добавочных опций -w 2m -l 1350, а с ними - нормально.
Скомпилировал 2.1.9. Последняя версия во второй линейке.
Сравнение.
iperf-2.1.9-win32.exe (439,5 КБ)
Пока что эта байда продолжает наблюдаться, хоть количество проблемных направлений снизилась, и вероятность того, что порт проблемный снизились где-то до 2-4%.
В целом похоже, что это потери вносятся на магистралях, а не у конечного провайдера.
Также вчера (24.06.2023) наблюдались блокировки openvpn по протоколу, по одиночным направлениям, в течении суток. потом их убрали.
В общем, судя по всему РКН продолжает тренироваться ломать интернет.
Провайдеры отвечают что мы ничего сделать с этим не можем.
После двухнедельных переговоров с двумя провайдерами и Мегафоном, мою проблему устранили сегодня ночью, спустя 6 недель с её появления.
@vladserg, у вас без изменений?
Проверил - пока проблема сохраняется. Пока не было времени репортить ее провайдеру, потому как да - обычно это занимает кучу времени и переписки. Тем более что проблема наблюдается на двух разных провайдерах, использующих магистрали ростелекома. Пока только наблюдаю, может попозже попробую пообщаться с ними на эту тему, если будет время.
На вопрос - почему блокировки openvpn затрагивают бизнес пользователей, которые платят за интернет в десятки раз больше физ лиц, и как вообще предлагается работать бизнес пользователям в условиях, когда связь могут отключить в любой момент - ответа от них нет.
Точнее время пока тратим на технические решения для обхода возможных блокировок. Потому что это дает больше гарантии результата, чем разговоры с провайдерами. Спасибо Xunlei за наводку на UDPspeeder , хороший тул, который может убить двух зайцев - и потери убирать и обфускацию заодно добавить (я предполагаю, что он данные в пакетах перемешивает, плюс добавлят добавочные пакеты). Единственное, что пинг немного увеличивает.
А вот опыт с помещением openvpn в cloak или wstunnel - плохой. Пока на канале потерь нет, то нормально. Но если будут потери на интернет канале, даже минимальные (0.1%), то при работе нескольких TCP потоков внутри одного тоннеля будет все очень плохо, поскольку внешний канал это TCP, он уменьшает окно передачи, и начинаются огромные пинги внутри тоннеля из-за buffer bloat (больше 4 секунд), т.е. недостатки схемы работы TCP поверх TCP. Когда внутренние потоки начинают влиять друг на друга, мешать друг другу, в отличие от ситуации в TCP поверх UDP, когда внутренние потоки друг на друга не влияют.
То есть когда TCP поверх TCP - у них один общий лимит скорости, связанный с потерями на канале, который вводит внешний TCP, уменьшая окно передачи, еще и очень плохо работающий в итоге. А когда TCP поверх UDP - то у каждого TCP свой независимый congestion control, как и должно быть.
Попробуйте ещё udp2raw --raw-mode faketcp, машрутизаторы в основном приоритизируют TCP. Под виндовс нужен драйвер NPCAP, в линуксе работает из коробки с правами AmbientCapabilities=CAP_NET_RAW CAP_NET_ADMIN. Джиттер уменьшается, по сравнению с UDP. Чтобы логи не заполнялись предудупреждениями необходио добавить параметр --mtu-warn 1500. Для уменьшения размера ежесекундного пакета heartbeat можно использовать параметр --hb-len. Правила брандмауэра при этом не работают, если включены ICMP ответы будут в начале паралельно Destination port unreachable идти от драйвера ОС.
5 августа и 26 июня наблюдалась на несколько часов в середине дня недоступность всех(или почти всех) нестандартных TCP(syn drop)/UDP портов, включая <1024 и icmp echo request, кроме 22, 80, 443 vps с vpn на 5 пользователей. SSH на нестандартном порту отвалился. Идентичная ситуация как с домру, так и из дц(через Cloud-IX).
У знакомого со своим однопользовательским vpn на vps под себя в это время всё работало.
Вчера наблюдал блокировку UDP-пакетов на порт 443 на площадке в России, если первый байт данных пакета чётный.
Банально при отправке ASCII-цифр от 1 до 9 доходили только нечётные.
Фильтр был на стороне DDOS-GUARD (подтверждено хостером), применялся примерно сутки.
wg сервер 194.180.174.4:53481
wg клиент в рф 5.142.228.х:64238(ListenPort) - iperf выдает 5% потерь на вход, на выход без потерь
root@pc:~# iperf3 -c 10.66.66.1 -R -u -b 70000000
Connecting to host 10.66.66.1, port 5201
Reverse mode, remote host 10.66.66.1 is sending
[ 5] local 10.66.66.15 port 35161 connected to 10.66.66.1 port 5201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 7.87 MBytes 66.1 Mbits/sec 0.172 ms 319/6355 (5%)
[ 5] 1.00-2.00 sec 7.87 MBytes 66.0 Mbits/sec 0.160 ms 360/6394 (5.6%)
[ 5] 2.00-3.00 sec 7.91 MBytes 66.4 Mbits/sec 0.149 ms 330/6396 (5.2%)
[ 5] 3.00-4.00 sec 7.96 MBytes 66.7 Mbits/sec 0.149 ms 298/6397 (4.7%)
[ 5] 4.00-5.00 sec 7.93 MBytes 66.5 Mbits/sec 0.197 ms 319/6397 (5%)
[ 5] 5.00-6.00 sec 7.94 MBytes 66.6 Mbits/sec 0.174 ms 312/6396 (4.9%)
[ 5] 6.00-7.00 sec 7.93 MBytes 66.5 Mbits/sec 0.146 ms 321/6396 (5%)
[ 5] 7.00-8.00 sec 7.95 MBytes 66.7 Mbits/sec 0.156 ms 302/6396 (4.7%)
[ 5] 8.00-9.00 sec 7.89 MBytes 66.1 Mbits/sec 0.155 ms 352/6396 (5.5%)
[ 5] 9.00-10.00 sec 7.96 MBytes 66.8 Mbits/sec 0.139 ms 298/6398 (4.7%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.12 sec 84.4 MBytes 70.0 Mbits/sec 0.000 ms 0/64700 (0%) sender
[ 5] 0.00-10.00 sec 79.2 MBytes 66.4 Mbits/sec 0.139 ms 3211/63921 (5%) receiver
iperf Done.
wg клиент в рф 5.142.228.х:64237 - iperf без потерь в обе стороны
root@pc:~# iperf3 -c 10.66.66.1 -R -u -b 70000000
Connecting to host 10.66.66.1, port 5201
Reverse mode, remote host 10.66.66.1 is sending
[ 5] local 10.66.66.15 port 36944 connected to 10.66.66.1 port 5201
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 8.34 MBytes 70.0 Mbits/sec 0.198 ms 0/6394 (0%)
[ 5] 1.00-2.00 sec 8.35 MBytes 70.0 Mbits/sec 0.161 ms 0/6397 (0%)
[ 5] 2.00-3.00 sec 8.34 MBytes 70.0 Mbits/sec 0.175 ms 0/6396 (0%)
[ 5] 3.00-4.00 sec 8.34 MBytes 70.0 Mbits/sec 0.164 ms 0/6395 (0%)
[ 5] 4.00-5.00 sec 8.35 MBytes 70.0 Mbits/sec 0.162 ms 0/6398 (0%)
[ 5] 5.00-6.00 sec 8.34 MBytes 70.0 Mbits/sec 0.176 ms 0/6394 (0%)
[ 5] 6.00-7.00 sec 8.35 MBytes 70.0 Mbits/sec 0.195 ms 0/6398 (0%)
[ 5] 7.00-8.00 sec 8.34 MBytes 70.0 Mbits/sec 0.176 ms 0/6395 (0%)
[ 5] 8.00-9.00 sec 8.34 MBytes 70.0 Mbits/sec 0.155 ms 0/6394 (0%)
[ 5] 9.00-10.00 sec 8.35 MBytes 70.0 Mbits/sec 0.173 ms 0/6399 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.11 sec 84.3 MBytes 70.0 Mbits/sec 0.000 ms 0/64648 (0%) sender
[ 5] 0.00-10.00 sec 83.4 MBytes 70.0 Mbits/sec 0.173 ms 0/63960 (0%) receiver
iperf Done.
проверил 3 раза
на клиентах не из РФ потерь нет на обеих портах
трасса от РФ клиента с потерями
My traceroute [v0.95]
pc (192.168.1.5) -> 194.180.174.4 (194.180.12023-11-06T16:26:34+0300
Keys: Help Display mode Restart statistics Order of fields q
uit Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 21 0.4 0.4 0.4 0.6 0.0
2. 212.48.195.203 0.0% 21 3.0 3.4 2.2 11.7 1.9
3. 212.48.194.218 0.0% 21 2.7 3.2 1.6 10.4 1.7
4. 185.140.148.29 0.0% 20 49.7 49.5 48.6 49.9 0.3
5. 194.68.123.187 20.0% 20 51.4 77.6 39.8 272.2 64.3
6. 80.81.192.172 89.5% 20 72.7 87.4 72.7 102.1 20.8
7. 184.105.65.54 63.2% 20 99.9 99.2 98.8 99.9 0.4
8. 216.66.82.42 0.0% 20 104.8 105.4 103.7 117.3 2.9
9. 185.163.44.5 0.0% 20 100.2 101.1 100.0 104.9 1.5
10. 194.180.174.4 0.0% 20 99.3 99.7 98.3 101.3 0.7
от vps на oracle sweden (без потерь)
arm1 (10.5.1.10) -> 194.180.174.4 (194.182023-11-06T13:27:48+0000
Keys: Help Display mode Restart statistics Order of fields
quit Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 140.91.246.4 0.0% 6 0.1 0.2 0.1 0.4 0.1
2. 128.241.219.242 0.0% 6 0.8 0.8 0.7 0.9 0.1
3. 128.241.219.241 0.0% 6 1.3 1.2 1.1 1.3 0.1
4. 129.250.3.68 0.0% 6 39.3 28.4 24.8 39.3 5.9
5. 129.250.7.87 0.0% 6 24.9 25.6 24.8 28.5 1.5
6. 130.117.15.129 0.0% 6 24.3 24.1 23.9 24.3 0.2
7. 130.117.50.5 0.0% 6 22.1 22.1 22.0 22.2 0.1
8. 130.117.0.142 0.0% 6 27.8 27.9 27.5 28.3 0.2
9. 154.54.36.254 0.0% 6 56.5 42.6 33.4 65.4 14.5
10. 154.54.59.181 0.0% 6 39.0 38.8 38.7 39.0 0.1
11. 154.54.59.186 0.0% 6 39.8 40.0 39.8 40.4 0.2
12. 154.54.59.178 0.0% 6 42.1 44.3 42.1 54.6 5.0
13. 154.54.38.246 0.0% 5 54.4 54.3 54.1 54.4 0.1
14. 154.54.56.61 0.0% 5 61.2 61.2 61.1 61.3 0.1
15. 149.14.58.90 0.0% 5 59.5 62.6 59.5 74.9 6.9
16. 194.180.174.4 0.0% 5 61.1 61.1 61.0 61.1 0.0
на другом клиенте из рф 95.182.113.x с трассой
DietPi (192.168.1.200) -> 194.180.174.4 2023-11-06T16:39:58+0300
Keys: Help Display mode Restart statistics Order of fields qui
t Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 14 0.5 0.5 0.4 0.5 0.0
2. 95.182.113.254 0.0% 14 0.9 1.0 0.8 1.8 0.2
3. 95.182.112.1 0.0% 14 0.8 0.8 0.7 0.9 0.0
4. 81.211.99.61 0.0% 14 2.7 2.8 2.6 3.2 0.2
5. 79.104.229.55 16.7% 13 30.6 31.4 30.5 33.7 1.1
6. 194.68.123.187 91.7% 13 51.6 51.6 51.6 51.6 0.0
7. 80.81.192.172 91.7% 13 103.0 103.0 103.0 103.0 0.0
8. 184.105.65.54 58.3% 13 99.9 100.8 98.9 101.8 1.3
9. 216.66.82.42 0.0% 13 98.3 97.3 91.7 98.3 1.8
10. 185.163.44.5 0.0% 13 96.9 103.3 96.7 126.7 11.0
11. 194.180.174.4 0.0% 13 97.5 97.3 97.1 97.9 0.2
потерь нет на любых портах
на хосте с потерями вижу что большинство портов без потерь, некоторые с потерями 0.2%, некоторые 3%, 6%… tcp протокол тоже с потерями
upd: нашел другого хоста не из РФ (могу раскрыть в лс), но там маршрут к серверу (он в молдове btw) идёт через рт 188.128.126.213, 178.35.228.79, и потери на некоторых портах тоже есть
Если подвигать порт у сервера, что-то меняется? Если не меняется, попробуйте с сервера: mtr -u -n -P 64238 -s <pmtu> 5.142.228.х
сервер в молдове, клиент в рф
на сервере iperf3 -s -p5000
на клиенте:
iperf3 -c server -R -u -b 10000000 -p5000 --cport 5555 - OK
iperf3 -c server -R -u -b 10000000 -p5000 --cport 5556 - 2% LOSS
на сервере iperf3 -s -p5001
на клиенте:
iperf3 -c server -R -u -b 10000000 -p5001 --cport 5555 - 2% LOSS
iperf3 -c server -R -u -b 10000000 -p5001 --cport 5556 - 2% LOSS
на сервере iperf3 -s -p5002
на клиенте:
iperf3 -c server -R -u -b 10000000 -p5002 --cport 5555 - OK
iperf3 -c server -R -u -b 10000000 -p5002 --cport 5556 - OK
повторяемость 100% (не в % а в есть/нет потерь)
ps порт клиента отображается на сервере, nat его не меняет, проверял каждый раз
а что мне для этого запускать на рф хосте? какой сервис будет отвечать на udp пинги?
Ответы хоста не нужны. Идея в том чтобы найти хоп, который дропает входящие. Но mtr нужны переменные порты (исходящий или входящий).
потерь уже нет, но я тестил вечером от рф хоста к серверу, и потери были уже на 2, 3 хопах. щас их нет, но там очень непонятно т.к. показывает потери на последнем хопе, а iperf3 показывает 0% loss на тех же портах
Если блокируют входящие от сервера, тесты исходящими к серверу покажут что-то другое. Маршрутизаторы не всегда уведомляют о произошедшем (через ICMP), из-за нагрузки или просто rate-limit. Потери с точки зрения тестов (mtr) не всегда означают потерю актуального трафика. Но если хоп систематически дропает часть трафика, тогда и все последующие по трассе будут тоже показывать потери. Быть может не через логику mtr (инкремент ttl на каждый отправленный пакет), но можно попытаться выявить хоп с потерями даже с учетом хрупкости ICMP уведомлений.
это все еще продолжается. когда делаю traceroute с определенными sport-dport, то маршрут никогда не меняется, но потери на них то пропадают то появляются