LINUX.ORG.RU
ФорумAdmin

Редирект траффика хоста через удаленный шлюз

 , ,


0

1

День добрый!

Сутки не получается понять что я делаю не так, перечитано все что можно в т.ч. на лоре.

Конфигурация сети следующая:
GW Mikrotik на самой свежей прошивке
WAN: 8.8.8.8, статика, Gpon от МГТС
LAN: 10.10.30.0/24, SNAT локалки
L2TP Server: 10.10.255.1, без шифрования, MTU/MRU 1450

Dedicated на Debian 11 в другой стране
WAN: 9.9.9.9, само собой статика
L2TP Client: 10.10.255.10, без шифрования, MTU/MRU 1450

Задача сделать так чтобы весь траффик (кроме сервисного) хоста 10.10.30.15 полностью шел через удаленный сервер, для этого реализована схема как с двумя WAN провайдерами:

1. На GW метится траффик с хоста:
chain=prerouting action=mark-routing new-routing-mark=redir_route passthrough=no src-address=10.10.30.15 dst-address=!10.10.0.0/16

2. Хост снатится:
chain=srcnat action=src-nat to-addresses=10.10.255.1 src-address=10.10.30.15 out-interface=L2TP

3. Создается маршрут с меткой (привожу всю таблицу маршрутизации):
0 A S 0.0.0.0/0 10.10.255.1 10.10.255.10 1 routing-mark=redir_route
1 ADS 0.0.0.0/0 192.168.1.1 1
4 ADC 10.10.30.0/24 10.10.30.1 Bridge LAN 0
7 ADC 10.10.255.10/32 10.10.255.1 L2TP 0
8 ADC 192.168.1.0/29 192.168.1.2 Eth1 WAN 0

4. На удаленном сервере все это снова снатится:
-A POSTROUTING -s 10.10.255.1 -j SNAT --to-source 9.9.9.9

5. С вот такими маршрутами:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 9.9.9.1 0.0.0.0 UG 0 0 0 eth0
10.10.0.0 10.10.255.1 255.255.0.0 UG 0 0 0 ppp0
10.10.255.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
9.9.9.9 0.0.0.0 255.255.255.192 U 0 0 0 eth0

Результат: крайне долгий коннект с этого особого хоста во внешний мир, скорость закачки с репозитория Debian в районе 20 кбит/с.

Что я проверял и пробовал и вообще: -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu присутствует а так же --set-mss 600/1200 и т.д. тоже пробовал. Все пингуется и трассируется во всех возможных вариантах. Скачивание/закачка по FTP через L2TP туннель отличные. Файрволлы отключались, правила и маршруты проверялись и перепроверялись.

Большие пакеты ходят, без фрагментации вот такие максимум: PING 194.71.11.137 (194.71.11.137) 1422(1450) bytes of data. 1430 bytes from 194.71.11.137: icmp_seq=1 ttl=46 time=84.5 ms С фрагментацией ходят любые.

MTU/MRU туннеля снижал и увеличивал на обеих концах.

Ну и конечно сотня разных перенастроек всего подряд которые даже не вспомню уже, прошу помощи ну или ткнуть носом в очевидный косяк или незнание!

Зачем

2. Хост снатится:

chain=srcnat action=src-nat to-addresses=10.10.255.1 src-address=10.10.30.15 out-interface=L2TP

непонятно.

Но, главный вопрос, трафик от хоста 10.10.30.15 идёт во внешний мир через тунель и удаленный сервер или нет?

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

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

Траффик от хоста идет и через туннель и роутится на удаленном сервере и вообще ходит как задумано, только медленно очень.

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

Сам испек, сам и ешь.

anonymous
()
Ответ на: комментарий от FourtyTwo

В слепую крутить параметры особого смысла нет. Убедится, что именно закачка файла 20 кбайт/с (а не тормоза из-за резолвинга DNS) и при закачке большого файла дампить пакеты (с записью в файл) на удалённом сервере и, возможно, на 10.10.30.15. Потом долго курить tcp и изучать дамп. Смотреть какие параметры соедиения устанавливаются (mss, wscale), смотреть есть повторные передачи пакетов...

Может у вас хостер смотрит на TTL пакетов и ограничивает полосу для «левого» трафика.

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

Спасибо за наводку по поводу левого траффика, буду дампить

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

Я, возможно, неправильно понял задачу, но зачем тут вообще нужна маркировка пакетов? Что мешает создать отдельную таблицу маршрутизации со шлюзом по умолчанию в виде удаленного сервера и направлять весь трафик с нужного Вам хоста в нее? А SNAT, соответственно, осуществлять на удаленном сервере?

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

Микротик не умеет без маркировки перенаправлять траффик в новую таблицу насколько я знаю, или я что-то не знаю?

FourtyTwo
() автор топика
Ответ на: комментарий от FourtyTwo

Микротик не умеет без маркировки перенаправлять траффик в новую таблицу насколько я знаю

Тут я ничего подсказать не могу, никогда не имел с ними дела. Но вообще это как-то странно...

Serge10 ★★★★★
()

Зачем 2 раза исподьзовать нат, в l2tp канале я бы не стал натить а прописал маршруты.

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

Убрал лишний снат посередине, на всякий случай включил на обеих сторонах proxy-arp, оставил остальное как раньше, результат тот же что и раньше.

Взял tcpdump, начал снова качать большой файл через всю эту систему со скоростью 10-30 кбит/с и получил дамп с сервера как вы советовали. Теперь я совсем ничего не понимаю, обмен пакетами идет кусками по 20-40 пакетов через каждые 5-10 секунд.

Куда копать?

Кусок дампа тут: https://pastebin.com/gJP7yy2S

FourtyTwo
() автор топика
Ответ на: комментарий от mky

Включил на туннеле MPPE128, скорость возросла до 300-600 кбит/с.

Получается это хостер выделенного сервера или мой провайдер что-то режут и когда пошел шифрованный трафик он стал легче проходить ограничения?

FourtyTwo
() автор топика
Ответ на: комментарий от FourtyTwo

Возможно, непонятно где режут, но судя по дампу, есть потери пакетов после выделенного сервера:

2019-07-16 21:32:34.558837 IP (tos 0x0, ttl 47, id 34687, offset 0, flags [DF], proto TCP (6), length 1450)
    194.71.11.137.443 > 10.10.30.11.44364: Flags [.], cksum 0x0cd3 (correct), seq 3057509424:3057510822, ack 3257939770, win 31, options [nop,nop,TS val 3197813343 ecr 2538590910], length 1398

а потом повторная передача через те самые 5 секунд:

2019-07-16 21:32:39.194811 IP (tos 0x0, ttl 47, id 34718, offset 0, flags [DF], proto TCP (6), length 1450)
    194.71.11.137.443 > 10.10.30.11.44364: Flags [.], cksum 0xfab6 (correct), seq 3057509424:3057510822, ack 3257939770, win 31, options [nop,nop,TS val 3197817979 ecr 2538590910], length 1398

А смотреть, все ли пакеты одного окна попадают в дамп подряд или есть ещё потери до выделенного сервера уже ваше дело, мне лень курит чужой дамп.

Я не знаю тонкостей современного оборудования, может у хостера действительно стоит какая IPS, которая лезет внутрь не шифрованных пакетов, но не справляется с нагрузкой, а может какие завихрения микротика, без шифрации ведь L2TP тунели особо не востребованы и, следовательно, не протестированы. Странно что ftp через тунель качал быстро.

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

Самое интересное что на удаленном сервере крутится прозрачный HTTPS Squid через который я время от времени серфлю всякое.

Когда появилась задача выпустить через удаленку хост я сразу настроил L2TP по быстрому и начал вот эту историю с натами и редиректами.

Вчера, после того как включил MPPE128 я завернул через туннель HTTP(S) трафик с хоста и все работает, как минимум скачивается через всю эту связку под 100 Мбит/с.

Так или иначе всем спасибо за подсказки и помощь!

FourtyTwo
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.