В результате мониторинга и изучения проблем с рабочими VPN за последний 1.5 месяца стала примерно ясна суть еще одной проблемы.
Судя по всему вносятся потери во входящий трафик, весьма приблизительно по такой схеме: if (hash(src_ip, src_port, dst_ip, dst_port) % koef == 0) → drop packets with 3% probability.
При этом без разницы, что за трафик там идет - хоть даже Iperf3. То видно, что пока не меняются src_ip, dst_ip, dst_port, набор проблемных портов src_port не меняется в выборке из 100 портов (сейчас в такой выборке - около 5-6 проблемных портов).
Вероятность того что порт плохой (koef) - иногда больше, иногда меньше становится.
Отсюда следует, что при установке соединения - когда src_port выбирается рандомный, то с некоторой вероятностью мы получаем потерю пакетов и тормоза.
Наблюдается такое на TCP и на UDP, в связках (hetzner, leaseweb, other) ↔ (ростелеком, транстелеком).
Схема выглядит достаточно странно.
Находятся эти проблемные порты через Iperf, 3 секунды гоняем на порту, смотрим потери UDP или ретрансмиты TCP.
Вот к примеру график потерь пакетов из Гонконга на наборе из 1000 src портов от 1300 до 65000 с шагом 65:
А по вертикальной оси что отложено? Процент потерь?
Да, по вертикали процент потерь.
Интересно, значит пора начать повсеместно использовать UDPspeeder и udp2raw.
Если кто-то объединит функции этих программ с, например, TunSafe с автоматическим слежением качества связи дайте мне знать — мобильные процессоры не особо справляются с такой нагрузкой.
У меня есть такая проблема, но только в связке с одним провайдером на моей стороне (РФ) и одним зарубежным провайдером: не доходит значимая часть TCP SYN’ов, в обе стороны (ни я не могу установить соединение, ни они ко мне), на определённых портах.
Это обычный HTTP-вебсайт, не VPN.
Я пока не уверен, что это блокировки. Больше похоже либо на роутер с битой памятью где-то ближе к РФ (думал, что у моего провайдера, вы говорите, что разные каналы подвержены проблеме), либо как-то забавно настроенные фильтры BCP38.
Если я отправляю себе TCP SYN’ы от любого IP-адреса с определённой площадки (которая позволяет подменять IP-адрес источника), вижу 100% потерей при определённых портах.
Например, ни один TCP SYN-пакет из 10 от 8.8.8.8:65248 до меня:2233 не дошел, а от 8.8.8.8:55945 — никаких проблем, все дошли.
Вот еще аналогичный график потерь снятый с hetzner в сторону ростелеком. Не очень похоже на нормальный random / hash, либо используется плохая функция хэша.
Сегодня, после 3 ночи MSK, раскладка проблемных портов сменилась, хотя более суток была неизменной, с начала наблюдения.
Ранее также была зафиксирована зависимость потерь от размеров пакетов iperf (внутри vpn):
20 bytes - 0.37%
50 bytes - 0.5%
200 bytes - 0.76%
1350 bytes - 2.8%
А вообще эта байда длится уже не менее 1.5 месяцев.
А с помощью долбёжки с TTL можно ли выяснить проблемный маршрутизатор?
Наверное можно, но mtr под линукс не поддерживает --localport, а --port работает только в tcp режиме, судя по мануалу.
Рабочий исходящий порт:
% sudo tcptraceroute 94.100.24.67 80 -P 10016 -q 6
Selected device enp2s0, address 192.168.69.10, port 10016 for outgoing packets
Tracing the path to 94.100.24.67 on TCP port 80 (http), 30 hops max
1 192.168.69.1 1.975 ms 0.749 ms 1.166 ms 2.423 ms 2.253 ms *
2 95-161-156-121.obit.ru (95.161.156.121) 1.421 ms 2.675 ms 1.134 ms 4.958 ms 1.556 ms 1.889 ms
3 172.29.194.72 1.304 ms 2.454 ms 18.128 ms 9.192 ms 16.138 ms 14.347 ms
4 172.29.192.121 16.369 ms 12.064 ms 12.735 ms 9.513 ms 6.279 ms 3.141 ms
5 172.29.194.77 1.159 ms 0.963 ms 5.978 ms 1.091 ms 0.903 ms 0.936 ms
6 172.29.194.94 1.131 ms 2.890 ms 1.372 ms 1.941 ms 1.015 ms 1.064 ms
7 172.29.255.197 2.567 ms 1.537 ms 1.179 ms 1.031 ms 1.103 ms 1.136 ms
8 172.29.194.113 2.176 ms 1.925 ms 1.586 ms 1.224 ms 1.151 ms 1.352 ms
9 172.29.194.37 5.130 ms 1.498 ms 0.911 ms 1.154 ms 1.973 ms 1.570 ms
10 vi-xx-0150.brc2.obit.ru (85.114.1.13) 1.974 ms 2.378 ms 3.236 ms 1.887 ms 1.976 ms 7.417 ms
11 * 109.239.136.155 15.394 ms * * * *
12 100ge0-42.core2.ams1.he.net (184.105.65.125) 33.066 ms * * 112.909 ms * *
13 100ge0-29.core1.ams7.he.net (184.105.213.197) 60.557 ms 58.424 ms 64.578 ms 67.975 ms 83.675 ms 35.377 ms
14 hivelocity-ventures-corp.e0-1.switch1.ams7.he.net (184.105.27.106) 34.104 ms 48.390 ms 57.888 ms 64.501 ms 84.650 ms 105.816 ms
15 * * * * * *
16 * * * * * *
17 * * * * * *
18 94-100-24-67.static.hvvc.us (94.100.24.67) [open] 34.051 ms 35.087 ms 34.208 ms 34.867 ms 35.691 ms 34.678 ms
Нерабочий исходящий порт:
% sudo tcptraceroute 94.100.24.67 80 -P 10009 -q 6
Selected device enp2s0, address 192.168.69.10, port 10009 for outgoing packets
Tracing the path to 94.100.24.67 on TCP port 80 (http), 30 hops max
1 192.168.69.1 15.789 ms 2.220 ms 0.463 ms 0.513 ms 0.291 ms 0.852 ms
2 95-161-156-121.obit.ru (95.161.156.121) 1.104 ms 1.795 ms 0.810 ms 2.062 ms 0.843 ms 0.860 ms
3 172.29.194.72 1.588 ms 0.786 ms 0.857 ms 0.939 ms 0.791 ms 1.152 ms
4 172.29.192.121 1.264 ms 4.696 ms 4.347 ms 8.515 ms 9.309 ms 5.530 ms
5 172.29.194.77 1.583 ms 6.602 ms 0.909 ms 1.458 ms 2.957 ms 7.076 ms
6 172.29.194.94 0.853 ms 1.583 ms 1.364 ms 2.193 ms 0.903 ms 0.938 ms
7 172.29.255.197 2.833 ms 0.885 ms 1.057 ms 2.617 ms 1.297 ms 0.862 ms
8 172.29.194.113 1.736 ms 0.908 ms 4.144 ms 5.369 ms 4.128 ms 1.041 ms
9 172.29.194.37 1.459 ms 1.075 ms 2.203 ms 1.252 ms 1.298 ms 2.697 ms
10 vi-xx-0150.brc2.obit.ru (85.114.1.13) 1.359 ms 4.076 ms 3.059 ms 3.332 ms 1.875 ms 1.474 ms
11 * * * * * 109.239.136.155 70.226 ms
12 100ge0-42.core2.ams1.he.net (184.105.65.125) 39.163 ms * * 33.007 ms * 35.631 ms
13 100ge0-29.core1.ams7.he.net (184.105.213.197) 31.363 ms 33.058 ms 31.488 ms 32.445 ms 31.278 ms 31.369 ms
14 hivelocity-ventures-corp.e0-1.switch1.ams7.he.net (184.105.27.106) 35.329 ms 33.458 ms 33.483 ms 34.554 ms 39.352 ms 42.495 ms
15 * * * * * *
16 * * * * * *
17 * * * * * *
18 * * * * * *
19 * * * * * *
20 * * * * * *
21 * * * * * *
22 * * * * * *
23 * * * * * *
24 * * * * * *
25 * * * * * *
26 * * * * * *
27 * * * * * *
В трёх случах из трёх проблема появляется при транзите трафика через Мегафон Поволжье/Волга.
Последние хопы с трёх каналов: 83.169.204.90 и 85.26.205.119.
Не удается с помощью tcptraceroute что то толковое определить. Тут также то доходит, то не доходит, в зависимости от порта, но прямой связи с теми портами где потери по iperf - нет.
Но в ходе дальнейшего изучения также было выявлено что один хост, который сначала не давал потерь - вдруг стал давать небольшие потери на портах (0.2%), после нескольких тестов. Возможно спровоцировали это сканом.
А также в процессе скана iperf-ом, другой хост перешел из состояния малых потерь (0.2%) на некоторых портах в состояние больших потерь (3%), прямо посередине процесса скана.
Учитывая то, что iperf гонит случайный трафик, возможно мы идем по китайскому сценарию, когда в нераспознаваемый трафик вносятся потери с некоторой вероятностью.
График начался с малых потерь, а потом потери стали большими. Причем есть фаза когда есть и малые и большие одновременно. Конфиги на железо может распространяются так.
Серверы подконтрольны вам? Сделайте с них traceroute, вдруг там тоже Мегафон.
Да, подконтрольные. Но мегафона там никогда не было в трейсах, там либо ростелеком (в основном), либо трансттелеком (реже). По поводу наличия потерь на транстелекоме возможно я ошибся, проверил, там в трейсах почти везде ростелеком сейчас.
Возможно всё банально, и так проявляется криво работающий trunk.
Только вот проблема эта наблюдается с трафиком из разных частей света - гонконг, сша, европа, япония. Врядли везде транк криво работает.
У меня такое вышло 
, также проверял с 1300 до 65000 порта с шагом 65 по 3 секунды на UDP.
Использовал такой скрипт на питоне из под винды
import paramiko
import subprocess
import json
# Задайте здесь значения переменных
hostname = 'address' # Имя или IP-адрес сервера
port = 22 # Порт для SSH
username = 'username' # Имя пользователя
private_key_path = 'path-to-file' # Путь к файлу с приватным ключом SSH
iperf3_duration = 3 # Длительность теста iperf3 в секундах
output_file = "data.txt" # Файл для записи результатов
results_file = "results.txt" # Файл для записи отфильтрованных результатов
# Создание SSH-соединения
private_key = paramiko.RSAKey(filename=private_key_path)
client = paramiko.SSHClient()
client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
client.connect(hostname, port=port, username=username, pkey=private_key)
for iperf3_port in range(1300, 65001, 65): # Цикл по портам
# Установка правил ufw и запуск iperf3 на сервере
commands = [
f'sudo ufw allow {iperf3_port}',
f'iperf3 -s -p {iperf3_port} -D'
]
for command in commands:
stdin, stdout, stderr = client.exec_command(command)
print(stdout.read().decode())
print(stderr.read().decode())
# Запуск iperf3 локально. iperf3 должен быть в PATH
subprocess.run(f'iperf3 -c {hostname} -p {iperf3_port} -u -t {iperf3_duration} -J > {output_file}', shell=True)
# Чтение результатов из файла и запись нужных значений в другой файл
with open(output_file, "r") as file:
data = json.load(file)
results = {
"port": iperf3_port,
"lost_percent": data["end"]["sum"]["lost_percent"]
}
with open(results_file, "a") as results_file_obj:
results_file_obj.write(json.dumps(results) + "\n") # Запись результатов в новую строку файла
# Остановка iperf3 на сервере и удаление правил ufw
commands = [
'pkill iperf3',
f'sudo ufw delete allow {iperf3_port}',
]
for command in commands:
stdin, stdout, stderr = client.exec_command(command)
print(stdout.read().decode())
print(stderr.read().decode())
# Закрытие SSH-соединения
client.close()
Может я что-то не так проверяю 
А так живу за двумя натами, на дальнем востоке, проверял на серваке с нидерландов
За натом наверное будет проблематично задать source port, потому что NAT назначит свой.
Если же менять порт сервера, как в вашем случае, то source port все равно будет рандомным, и воспроизводимотси результатов не будет.
А так скрипт которым я проверял под линуксом, выглядит так: \
#!/usr/bin/bash
echo . > outfile.txt
for i in {20..1000}
do
SPORT=$((i*65))
echo $SPORT
iperf3 -c X.X.X.X -u -b 10m -t 2 --bind src.white.ip.addr --cport $SPORT >> outfile.txt
done
А на стороне сервера - iperf3 -s
Далее вывод в outfile.txt анализировал grep-ом на предмет потерь.
Под винду там iperf3 потребует больше опций, иначе он работает просто неадекватно.
Для UDP корректно сработает такой вариант опций клиента iperf3: -u -b 10m -l 1350 -w 2m -t 15 (это при условии что сервер - на линуксе или freebsd).
Обязательно чтобы было -l 1350 -w 2m , иначе он просто меряет какую-то ерунду.
Для tcp iperf3 под винду обязательно чтобы было -w 2m, иначе результаты тоже будут неакдекватные.
P.S. я тоже мерял на Дальнем Востоке
виндовый iperf где брали? на iperf.fr старая версия, вот тут https://files.budman.pw/ самый последний файл ver3.13, вроде адекватно работает
Да, брал кажется там https://files.budman.pw/ , версия iperf-3.1.3-win64
3.1.3 как раз на iperf.fr и очень старая, 2016г. Тоже с ней были проблемы
Оо, будем знать. Поменяю iperf и добавлю еще -b 10m -l 1350. А вместе с -w 2m не хочет работать.
Но, как и vladserg подметил из-за провайдерского NAT воспроизводимости результатов не будет, и мои изыскания скорее всего не имеют особого смысла 
. Белый айпишник у меня в городе стоит 500р/мес может с ним у меня что-то дельное выйдет . Если руки дотянутся до этого
у меня иногда iperf выдает broken pipe, но в файле этого не видно, добавьте &> out.txt
вообще у меня потери иногда то есть, то нет, не знаю в чем проблема, точно так измерить мне не выйдет
Теперь все по нулям. Только на одном порту 60905 был 0.0723066%.
В сам скрипт пришлось еще добавить попытки если выводит ошибку, типа “error”: “unable to read from stream socket: Resource temporarily unavailable”. Скорее всего на удаленном сервере iperf просто не успевает запуститься. Больше одной попытки не было.
Но в силу NAT, все это не имеет большого смысла.
Если 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, то маршрут никогда не меняется, но потери на них то пропадают то появляются
Проблема пропадала на длительное время, но 29 октября 2024 г. - снова появилась, и до настоящего момента присутсвует.