The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Агрегация (объединение мелких пакетов) при туннелировании"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Настройка Squid, Tor и прокси серверов (VPN)
Изначальное сообщение [ Отслеживать ]

"Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от Олег Бартунов (?), 28-Мрт-24, 19:13 
Имеется мобильный оператор, крайне не любящий высокий PPS, packet-per-second.
При этом порядка 90% траффика, который на данный момент роутится через openvpn/udp состоит из пакетов 64-128 байт.

Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или по таймауту?

По мотивам темы 10-летней давности https://www.linux.org.ru/forum/admin/10120422

Спустя 10 лет, что-то появилось, или отправят писать свой протокол?

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от Pahanivo пробегал (?), 29-Мрт-24, 00:12 
> Имеется мобильный оператор, крайне не любящий высокий PPS, packet-per-second.
> При этом порядка 90% траффика, который на данный момент роутится через openvpn/udp
> состоит из пакетов 64-128 байт.
> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
> по таймауту?

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

> Спустя 10 лет, что-то появилось, или отправят писать свой протокол?

Может я что-то не догоняю с пакетной сети - но, имхо, концептуально это бред.

Ответить | Правка | Наверх | Cообщить модератору

2. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от Олег Бартунов (?), 29-Мрт-24, 01:31 
>на забитом канале

В том-то и дело, по пропускной способности он не забит и на 10%

>а я так понимаю у тебя что-то реалтаймовское там ходит

Нет, задержки до 5000мс меня вполне устроят.
По сути мне нужен тот же алгоритм Нейгла, просто менее ориентированный на на реалтайм.

Ответить | Правка | Наверх | Cообщить модератору

3. "Агрегация (объединение мелких пакетов) при туннелировании"  +1 +/
Сообщение от Pahanivo пробегал (?), 30-Мрт-24, 00:10 
> Нет, задержки до 5000мс меня вполне устроят.

Ну дак в таком случае вас и " IP over Avian Carriers" утроит ))
Накой вам udp с вашем случае?


Ответить | Правка | Наверх | Cообщить модератору

4. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от Аноним (4), 01-Апр-24, 00:58 
Можно попробовать переключить openvpn на tcp, и не вклюючать NO_DELAY. Но как уже тут писали это приведет к возрасранию джиттера.

> Имеется мобильный оператор, крайне не любящий высокий PPS, packet-per-second.
> При этом порядка 90% траффика, который на данный момент роутится через openvpn/udp
> состоит из пакетов 64-128 байт.
> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
> по таймауту?
> По мотивам темы 10-летней давности https://www.linux.org.ru/forum/admin/10120422
> Спустя 10 лет, что-то появилось, или отправят писать свой протокол?

Ответить | Правка | Наверх | Cообщить модератору

5. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от ACCA (ok), 01-Апр-24, 22:22 
То есть ты хочешь собрать побольше P_CONTROL_V1, отправить их всей кучей, а потом получить кучу P_ACK_V1.

Ну, так себе идея.

Ответить | Правка | Наверх | Cообщить модератору

6. "Агрегация (объединение мелких пакетов) при туннелировании"  +1 +/
Сообщение от zyxman (?), 02-Апр-24, 07:57 
> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
> по таймауту?

Вообще буквально так работает FreeBSD ipfw pipe, там буквально есть корзина, которая заполняется пакетами и освобождается, либо когда пакет задержан на сколько заказано, либо когда корзина переполнилась.

На практике, надо померять распределение траффика, посчитать сколько пакетов в секунду проходит сейчас и поделить на сколько хочется иметь и получится 1/(задержка в секундах).

Дальше это уже вопрос настройки VPN, который будет просто отправлять сразу блоком - главное что этими пайпами оно будет получать сразу вот этот блок.
В Линуксе это вобщем тоже можно сделать, но сильно менее удобно.

Я экспериментировал с этой штукой, но траффик через диверт вытаскивал в скрипт и там в скрипте делал нужные мне манипуляции, это делается через юсерспейс, поэтому небыстрая штука получилась, но так точно работает, это факт.
В принципе можно переписать на С++, а также там есть ebpf кажется расширение чтобы оно прямо в ядре работало, тогда без проблем любые скорости.
По сложности, это задача на пару дней.

Также подобным образом сортировал пакеты по размеру (чтобы маленькие проходили раньше больших).

Поначалу экспериментов ничего не вышло, тк просто не увидел вообще никакой сортировки, потому что по учебнику сделал очень маленькую корзину и очень маленькую задержку и оно вообще не задерживало и не сортировало.
Потом проанализировал мой траффик, сколько там был период между пакетами и сделал задержку и размер буфера (корзины) так чтобы за ее время в среднем десяток пакетов накапливалось, и тогда сразу всё поехало как заказал.

Ответить | Правка | Наверх | Cообщить модератору

7. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от Олег Бартунов (?), 03-Апр-24, 09:58 
>> Есть ли какие-либо варианты аггрегации мелких пакетов по достижению заданного размера или
>> по таймауту?
> Вообще буквально так работает FreeBSD ipfw pipe, там буквально есть корзина, которая
> заполняется пакетами и освобождается, либо когда пакет задержан на сколько заказано,
> либо когда корзина переполнилась.

Это уже интересно, спасибо!
Читаю handbook и мануал по ipwf и не нахожу ничего похожего на корзину, только delay применяемый для каждого отдельного пакета.

Можешь ткнуть конкретно или привести некоторые правила от которых можно оттолкнуться?
А то чувствую себя хлебушком в freebsd, после 15 лет на debian.

Я правильно понимаю, что чтоб с обратной стороны не получать отдельные пакеты ответов, то надо с обоих сторон [freebsd>openvp] <канал> [openvpn<freebsd]

Ответить | Правка | Наверх | Cообщить модератору

8. "Агрегация (объединение мелких пакетов) при туннелировании"  +1 +/
Сообщение от zyxmanemail (?), 04-Апр-24, 02:00 
> Читаю handbook и мануал по ipwf и не нахожу ничего похожего на
> корзину, только delay применяемый для каждого отдельного пакета.

ipfw pipe
Там в настройках конкретной трубы можно указать:
bw bandwidth
delay ms-delay
queue {slots | sizeKbytes}

я просто назвал корзиной буфер (тут он очередь).

> Можешь ткнуть конкретно или привести некоторые правила от которых можно оттолкнуться?
> А то чувствую себя хлебушком в freebsd, после 15 лет на debian.

Тут есть небольшая проблема, у меня сгорели все компы где еще был АТА а оно на старом диске. Но по памяти я нашел в интернетах пример (и чуток подправил для лучшей наглядности):

sudo ipfw pipe 1 config bw 15KByte/s
# creates a pipe that only allows up to 15KB/s to go through.
# Then:
sudo ipfw add 10 pipe 1 src-port 80
# will attach that pipe to the outgoing traffic on port 80, effectively limiting the outgoing traffic of the web server.
sudo ipfw delete 10
# will remove the pipe from the port.

https://gist.github.com/olegokunevych/8146412

> Я правильно понимаю, что чтоб с обратной стороны не получать отдельные пакеты
> ответов, то надо с обоих сторон [freebsd>openvp] <канал> [openvpn<freebsd]

Да и нет.

Диверт просто очень удобная фича bsd (freebsd, openbsd), оно просто создает сокет по правилу вида, диверт всего что идет в какой-то интерфейс (кроме tcp сокет такой-то, см далее), к нему есть стандартная либа, просто говоришь "подключиться к диверт номер такой-то" и функция будет получать на вход пакеты, которые та самая либа прям на блюдечке с голубой каемочкой, делаешь с ними что хочешь, потом по умолчанию в тот же диверт обратно отправляешь (если не отправишь просто получится drop и всё; если никто не будет слушать диверт, он просто будет всё дропать; и если надо, ты можешь создать свои пакеты и туда инжектировать).

Дальше, запускается две пары прог.
На удаленной bsd которая из диверта пакеты например в tcp канал копирует с простейшей инкапсуляцией (ну просто чтобы в потоке отдельные пакеты видеть, там какой-то эскейп символ сделать и его конечно маскировать если будет в пакетах встречаться и обратно демаскировать при инжектировании обратно в стек), на местной bsd прога из канала достает пакеты, обратно  декапсулирует и в локальный диверт бросает.
Ну и вторая пара всё то же в обратном направлении делает.

Тонкость есть в чем, что если просто этими манипуляциями завернуть пакеты в tcp, он конечно постарается их буферизовать по максимуму, может и мегабайт в одном окне отправлять.
То есть нужно еще таймаут в прогу добавить на нашу задержку (на которую отконфигурили трубу) и по наступлению таймаута делать flush tcp.

Вот, tcp делается довольно просто, дальше можно по вкусу добавить например шифрование, я обычно тупо в ssh делаю проброс tcp сокета, оно довольно быстрое, у меня например самба несколько лет через такой канал жила.

ebpf идеологически то же, но программить сложнее, но там нет оверхеда на копирование в юсерспейс, поэтому заворачивалку отдельных пакетов в tcp лучше на ebpf сделать (на этапе tcp уже все оверхеды по барабану, оно и так медленное).

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

Ответить | Правка | Наверх | Cообщить модератору

10. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от Олег Бартунов (?), 06-Апр-24, 22:03 
Спасибо ещё раз.
Читаю мануал ipfw и dummynet и складывается понимание, что queue используется именно как некий буффер чтения, при заполненной полосе bw,
при переполнении которого пакеты просто отбрасываются, если не успевают проходить в bw, НО не как буффер для накопления перед отправкой,
который опустошается (в канал с учётом bw) при заполнении или по delay.
Или delay здесь не нужен так как он будет просто тормозить все пакеты и не связан с queue?

> The queue option sets the maximum amount of excess data (in packets or KBytes) that will be accepted before additional packets are refused.

Собственно, как именно это будет интерпретироваться, по сути мне только это и надо,
10.1.1.111 - tun0 в клиенте локальной freebsd, 10.1.1.1 - tun0 - внешнего сервера, тоже на freebsd.

ipfw add pipe 1 ip from 10.1.1.111/32 to 10.1.1.1/32 out
ipfw pipe 1 config bw 10Mbit/s queue 4KBytes delay 24ms

Если я правильно понял, то "queue 4KBytes delay 24ms" это (4096×8)×(1000÷24) = канал 1.3Мбит/с, что существенно ниже bw 10Mbit/s

Ещё вопрос, если это всё таки накопление перед отправкой, то имеет ли смысл сделать queue кратно mtu (mtu*2|4|8), и поиграть с разными mtu в openvpn?

PS, канал 1.3Мбит/с - это 21k pps для пакетов по 64 байта или 10k для пакетов 128 байт, либо примерно 910 pps для 1500

Или я где-то ошибаюсь?

Ответить | Правка | Наверх | Cообщить модератору

11. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от zyxmanemail (?), 07-Апр-24, 01:32 
> Спасибо ещё раз.
> Читаю мануал ipfw и dummynet и складывается понимание, что queue используется именно
> как некий буффер чтения, при заполненной полосе bw,
> при переполнении которого пакеты просто отбрасываются, если не успевают проходить в bw,
> НО не как буффер для накопления перед отправкой,
> который опустошается (в канал с учётом bw) при заполнении или по delay.

Это КОРЗИНА, которая заполняется пришедшими пакетами со скоростью ограниченной bw, то есть если будет приходить больше, будут отбрасываться сразу.
Далее, если суммарный размер пакетов находящихся в корзине с новым больше отконфигуренного размера, или если в корзине максимальное количество пакетов, новый пакет НЕ добавляется а отбрасывается.
Далее, если пакет таки попал в корзину, включается таймер и он там сидит до тех пор пока не закончится delay, как закончится delay отправляется дальше по ipfw и удаляется из корзины (освобождает место в корзине).
Проверка производится не в абстрактные моменты времени, а строго по тикам таймера, который по умолчанию в фре 6 был 50Гц, сейчас не знаю сколько, но на современных машинках можно спокойно ставить 1000Гц, это не очень высокая точность но техника переваривает не напрягаясь.

Да, за давностию лет я могу перепутать некоторые нюансы, типа в каком конце находится ограничитель скорости и тп, но логика по-моему точно такая.

То есть, если вы сделаете очень маленькие буфера, при очень большой скорости будет маленькая задержка В БУФЕРАХ, но часть пакетов будет отбрасываться; если сделать очень большие буфера, будет задержка большая.
Обычно есть некоторый оптимум задержки и потерь пакетов в таких шейперах, его нужно подбирать экспериментальным путем.

>> The queue option sets the maximum amount of excess data (in packets or KBytes) that will be accepted before additional packets are refused.
> Собственно, как именно это будет интерпретироваться, по сути мне только это и
> надо,
> 10.1.1.111 - tun0 в клиенте локальной freebsd, 10.1.1.1 - tun0 - внешнего
> сервера, тоже на freebsd.
> ipfw add pipe 1 ip from 10.1.1.111/32 to 10.1.1.1/32 out

ipfw add ДЭСЯТЬ pipe 1 ip from 10.1.1.111/32 to 10.1.1.1/32 out
номер правила забыли, он не назначается автоматом.

> ipfw pipe 1 config bw 10Mbit/s queue 4KBytes delay 24ms
> Если я правильно понял, то "queue 4KBytes delay 24ms" это (4096×8)×(1000÷24)
> = канал 1.3Мбит/с, что существенно ниже bw 10Mbit/s

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

Алгоритмы я выше привел. Разбирайтесь.

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

> Ещё вопрос, если это всё таки накопление перед отправкой, то имеет ли
> смысл сделать queue кратно mtu (mtu*2|4|8), и поиграть с разными mtu
> в openvpn?

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

> PS, канал 1.3Мбит/с - это 21k pps для пакетов по 64 байта
> или 10k для пакетов 128 байт, либо примерно 910 pps для
> 1500
> Или я где-то ошибаюсь?

perl -e 'print "".(1300000/8/64)."\n"'
2539.0625
perl -e 'print "".(1300000/8/1500)."\n"'
108.333333333333

Как говорится в классике - удачной охоты!

Ответить | Правка | Наверх | Cообщить модератору

12. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от Олег Бартунов (?), 07-Апр-24, 14:52 
Локальная kvm freebsd, openvpn
ipfw add 10 pipe 1 udp from 10.11.9.21 to 10.11.9.1 out
ipfw pipe 1 config bw 2Mbit/s queue 4KBytes     # лимит выше 1Мбит (-b 1M), условно, без лимита
iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64

[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   122 KBytes   999 Kbits/sec  1952  
[  5]   1.00-2.00   sec   122 KBytes  1000 Kbits/sec  1953  
[  5]   2.00-3.00   sec   122 KBytes  1000 Kbits/sec  1953  
[  5]   3.00-4.00   sec   122 KBytes  1000 Kbits/sec  1953  
[  5]   4.00-5.00   sec   122 KBytes  1000 Kbits/sec  1953  
[  5]   5.00-6.00   sec   122 KBytes  1000 Kbits/sec  1953

Хост debian, проверял pps как для vnet30, так и для wlan0
Количество пакетов в секунду одинаковое

tx 1 rx 1966 / pps on vnet30
tx 1 rx 1962 / pps on vnet30
tx 1 rx 1955 / pps on vnet30
tx 1 rx 1962 / pps on vnet30
tx 1 rx 1961 / pps on vnet30

tx 1958 rx 2 / pps on wlan0
tx 1961 rx 2 / pps on wlan0
tx 1955 rx 3 / pps on wlan0
tx 1964 rx 2 / pps on wlan0
tx 1954 rx 2 / pps on wlan0

Дополнительно, на хосте смотрел iptraf-ng на этих интерфейсах, и там всё те же пакеты, 58-112-192 байт, с тем же pps

С другой стороны, freebsd, openvpn
iperf3 -s

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   107 KBytes   874 Kbits/sec  1.316 ms  0/1708 (0%)  
[  5]   1.00-2.00   sec   122 KBytes  1.00 Mbits/sec  1.040 ms  0/1960 (0%)  
[  5]   2.00-3.00   sec   120 KBytes   981 Kbits/sec  0.660 ms  0/1918 (0%)  
[  5]   3.00-4.00   sec   124 KBytes  1.02 Mbits/sec  0.624 ms  0/1985 (0%)  
[  5]   4.00-5.00   sec   122 KBytes   998 Kbits/sec  0.648 ms  0/1950 (0%)  
[  5]   5.00-6.00   sec   122 KBytes   997 Kbits/sec  0.614 ms  0/1948 (0%)  
[  5]   6.00-7.00   sec   122 KBytes  1.00 Mbits/sec  0.690 ms  0/1954 (0%)  
[  5]   7.00-8.00   sec   124 KBytes  1.02 Mbits/sec  0.642 ms  0/1983 (0%)  
[  5]   8.00-9.00   sec   121 KBytes   991 Kbits/sec  0.835 ms  0/1937 (0%)  
[  5]   9.00-10.00  sec   121 KBytes   994 Kbits/sec  1.394 ms  0/1942 (0%)  
[  5]  10.00-11.00  sec   124 KBytes  1.02 Mbits/sec  0.666 ms  0/1984 (0%)  
[  5]  11.00-12.00  sec   122 KBytes   998 Kbits/sec  0.614 ms  0/1949 (0%)  
[  5]  11.00-12.00  sec   122 KBytes   998 Kbits/sec  0.614 ms  0/1949 (0%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[SUM]  0.0-12.0 sec  31 datagrams received out-of-order
[  5]   0.00-12.00  sec  1.53 MBytes  1.07 Mbits/sec  0.705 ms  0/25053 (0%)  receiver

Таким образом, с лимитом (bw 2Mbit/s) выше указанного в iperf (-b 1M) 1952 пакета в секунду проходят без потерь, и без объединения.


Локальная freebsd:

ipfw pipe 1 delete
ipfw pipe 1 config bw 512Kbit/s queue 24KBytes delay 24ms
iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64

[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   122 KBytes   999 Kbits/sec  1952  
[  5]   1.00-2.00   sec   122 KBytes  1000 Kbits/sec  1953  
[  5]   2.00-3.00   sec   122 KBytes  1000 Kbits/sec  1953


С другой стороны, ожидаемо:
[  5]  17.02-18.00  sec  54.4 KBytes   457 Kbits/sec  2.635 ms  1571/2442 (64%)  
[  5]  18.00-19.00  sec  43.8 KBytes   358 Kbits/sec  1.519 ms  1271/1971 (64%)  
[  5]  19.00-20.00  sec  43.5 KBytes   356 Kbits/sec  2.505 ms  1257/1953 (64%)  
[  5]  19.00-20.00  sec  43.5 KBytes   356 Kbits/sec  2.505 ms  1257/1953 (64%)  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-20.00  sec   882 KBytes   361 Kbits/sec  2.566 ms  24773/38887 (64%)  receiver

Локальный хост:
tx 1 rx 697 / pps on vnet30
tx 1 rx 703 / pps on vnet30
tx 1 rx 703 / pps on vnet30

То есть, я просто получю шейпер.
При разных вариантах очереди, таймаута, полосы, получается шейпер.
Всё работает логично и правильно, и тут не должно быть никаких объединений нескольких мелких пакетов в один mtu.

Так у меня изначальный вопрос был, есть ли возможность объединить в канале, например, openvpn мелкие пакеты, снизив внешний pps?

Ответить | Правка | Наверх | Cообщить модератору

13. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от zyxmanemail (?), 07-Апр-24, 20:09 
>[оверквотинг удален]
> ipfw add 10 pipe 1 udp from 10.11.9.21 to 10.11.9.1 out
> ipfw pipe 1 config bw 2Mbit/s queue 4KBytes    
> # лимит выше 1Мбит (-b 1M), условно, без лимита
> iperf3 -u -c 10.11.9.1 -b 1M -t -2 -l 64
> То есть, я просто получю шейпер.
> При разных вариантах очереди, таймаута, полосы, получается шейпер.
> Всё работает логично и правильно, и тут не должно быть никаких объединений
> нескольких мелких пакетов в один mtu.
> Так у меня изначальный вопрос был, есть ли возможность объединить в канале,
> например, openvpn мелкие пакеты, снизив внешний pps?

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

Ответить | Правка | Наверх | Cообщить модератору

14. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от zyxmanemail (?), 07-Апр-24, 20:11 

> Так у меня изначальный вопрос был, есть ли возможность объединить в канале,
> например, openvpn мелкие пакеты, снизив внешний pps?

PS кстати, простой скрипт на перле, думаю до тысяч 50 пакетов на современной машинке потянет, ну точно заметно больше 1500.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

15. "Агрегация (объединение мелких пакетов) при туннелировании"  +/
Сообщение от zyxmanemail (?), 07-Апр-24, 20:32 

> Так у меня изначальный вопрос был, есть ли возможность объединить в канале,
> например, openvpn мелкие пакеты, снизив внешний pps?

вот набор ссылок по теме. спрашивайте.

тут только не надо читать умняк насчет полностью эмулировать tcp, ничего мы эмулировать не будем, у нас два сокета будет занято (один туда, второй сюда), мы их НЕ будем дивертить а всё остальное будем:
https://www.opennet.dev/base/net/fire.txt.html

https://forum.lissyara.su/freebsd-f8/ipfw-divert-t5511.html
https://man.freebsd.org/cgi/man.cgi?query=divert&sektion=4&a...
https://man.freebsd.org/cgi/man.cgi?query=Net::Divert&sektio...

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру