Jump to content

ANAT (Advanced asymmetric CG NAT) xt_ANAT module ядра для Linux

sdy_moscow
 Share

Recommended Posts

  • Replies 85
  • Created
  • Last Reply

Top Posters In This Topic

Popular Days

Top Posters In This Topic

Popular Days

Posted Images

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
22 минуты назад, John_obn сказал:

@jffulcrum, у нового сервера конфа: Intel Xeon Platinum 8168, сеть Mellanox ConnectX-5 100G

На старом сервере под NAT юзаем: Intel E5-2690v4 тоже с Mellanox ConnectX-5 100G

Если не секрет, какой результат по скоростям и нагрузкам и какой модуль используете (ANAT?)

John_obn

John_obn

Posted
Posted

@sdy_moscow,

Потестил еще на группе юзеров модуль xt_ANAT и обнаружил на одном клиенте следующую проблему: у клиента не устанавливался IPSEC туннель. По непонятной причине (клиент все настройки возможные покрутил) клиент начинает фрагментировать пакет в какой-то момент в фазе 2. Такой пакет не пропускается (либо не NATится - не догадался точно проверить), в результате чего туннель не поднимается. Подозреваю, что ANAT либо не смог создать запись в NAT таблице, либо сопоставить с имеющимися

Скрытый текст 
15:25:32.691229 IP 172.20.67.232.500 > x.x.x.x.500: isakmp: phase 1 I agg
15:25:32.739783 IP x.x.x.x.500 > 172.20.67.232.500: isakmp: phase 1 R agg
15:25:32.743094 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 1 I agg[E]
15:25:32.760209 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I inf[E]
15:25:32.787500 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:32.790604 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I #6[E]
15:25:32.850438 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:32.853250 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I #6[E]
15:25:32.853916 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I #6[E]
15:25:32.898093 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:32.957194 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:32.957194 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:36.270131 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:36.270131 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:37.272743 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:37.272743 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:37.975350 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:37.975350 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:40.890147 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:41.296938 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:41.296938 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:42.283808 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:42.283808 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:42.994471 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:42.994471 IP 172.20.67.232 > x.x.x.x: ip-proto-17

 

 

 

@sdy_moscow Если речь о старом сервере, то я скидывал данные со скриншотами когда то в тему про Linux NAT. Если не найдете, могу сюда выложить текущие цифры.

Если вопрос про ANAT, то я его набегами в роли тестов запускаю. Но если очень интересно, могу сделать нагрузку по максимуму, погонять и скинуть суточный график.

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
15 минут назад, John_obn сказал:

@sdy_moscow,

Потестил еще на группе юзеров модуль xt_ANAT и обнаружил на одном клиенте следующую проблему: у клиента не устанавливался IPSEC туннель. По непонятной причине (клиент все настройки возможные покрутил) клиент начинает фрагментировать пакет в какой-то момент в фазе 2. Такой пакет не пропускается (либо не NATится - не догадался точно проверить), в результате чего туннель не поднимается. Подозреваю, что ANAT либо не смог создать запись в NAT таблице, либо сопоставить с имеющимися

  Показать содержимое 
15:25:32.691229 IP 172.20.67.232.500 > x.x.x.x.500: isakmp: phase 1 I agg
15:25:32.739783 IP x.x.x.x.500 > 172.20.67.232.500: isakmp: phase 1 R agg
15:25:32.743094 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 1 I agg[E]
15:25:32.760209 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I inf[E]
15:25:32.787500 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:32.790604 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I #6[E]
15:25:32.850438 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:32.853250 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I #6[E]
15:25:32.853916 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I #6[E]
15:25:32.898093 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:32.957194 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:32.957194 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:36.270131 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:36.270131 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:37.272743 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:37.272743 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:37.975350 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:37.975350 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:40.890147 IP x.x.x.x.4500 > 172.20.67.232.4500: NONESP-encap: isakmp: phase 2/others R #6[E]
15:25:41.296938 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:41.296938 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:42.283808 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:42.283808 IP 172.20.67.232 > x.x.x.x: ip-proto-17
15:25:42.994471 IP 172.20.67.232.4500 > x.x.x.x.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
15:25:42.994471 IP 172.20.67.232 > x.x.x.x: ip-proto-17

 

 

 

@sdy_moscow Если речь о старом сервере, то я скидывал данные со скриншотами когда то в тему про Linux NAT. Если не найдете, могу сюда выложить текущие цифры.

Если вопрос про ANAT, то я его набегами в роли тестов запускаю. Но если очень интересно, могу сделать нагрузку по максимуму, погонять и скинуть суточный график.

Было бы очень интересно посмотреть на скоростях больше 10 Гбит...

 

По фрагментации пакетов - да. Что-то помнится мне, что в исходном xt_NAT что-то в коде про фрагментированные пакеты было не совсем гладко. А раз было, то так и осталось. Но тут бы понять поточнее... или исходники смотреть. А сессия создается по порту/ип соурса - она должна была по любому подняться.

А у вас ipsec l2tp? Вы же его во что-то заворачиваете? Сами понимаете чистый ipsec через NAT ходить и не должен по идее.

John_obn

John_obn

Posted
Posted

@sdy_moscowХорошо, выберу время и закину несколько BRAS на ANAT , сниму графики.

Ясно, значит ковыряться в исходниках. Это туннель клиента, через какую то программу запускает типа Anyconnect или подобную. При прохождении через NAT на nftables этот туннель устанавливается и работает без всяких helper'ов

Умник

Умник

Posted
Posted
17 минут назад, sdy_moscow сказал:

про фрагментированные пакеты было не совсем гладко.

xt_ANAT их просто рубит. 

    if (unlikely(l_ip->frag_off & htons(IP_OFFSET))) {
        //printk(KERN_DEBUG "xt_ANAT DEBUG: Drop fragmented IP packet\n");
		axt_cnt_inc(&cnt_pkt_wfrags);
        return NF_DROP;
    }

 

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
53 минуты назад, Умник сказал:

xt_ANAT их просто рубит. 

    if (unlikely(l_ip->frag_off & htons(IP_OFFSET))) {
        //printk(KERN_DEBUG "xt_ANAT DEBUG: Drop fragmented IP packet\n");
		axt_cnt_inc(&cnt_pkt_wfrags);
        return NF_DROP;
    }

 

Да,  я помню, тоже когда этот код переписывал слегка удивился нелюбви xt_nat к фрагментированным пакетам. Я всё-таки не такой большой спец по NAT, больше оптимизацией производительности и стабильности занимался в ANAT, ковырять эти вопросы уже времени не было.  Интересно, почему такое решение прописано в xt_NAT и что будет, если просто эти 5 строчек закомментить (сам-то ANAT работать будет 100%, но будет ли корректная трансляция..)? Может кто знает или попробует? А потестить - это же еще фрагментированный трафик надо найти...

  • 3 weeks later...
[anp/hsw]

[anp/hsw]

Posted
Posted

Для того, чтобы натить фрагментированый пакет, нужно знать о всех его кусках

- зарезервировать память для всех кусков пакета и подождать их (это можно и до nat сделать, например стеком самой ОС)

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

Подозреваю, либо сложно, либо лениво.

 

В 19.12.2024 в 20:12, sdy_moscow сказал:

что будет, если просто эти 5 строчек закомментить

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

Найти фрагментированый трафик легко - поставьте mtu пониже. Можно даже на конкретный маршрут (ip route add xxx via yyy mtu 1400 например).

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
3 часа назад, [anp/hsw] сказал:

Для того, чтобы натить фрагментированый пакет, нужно знать о всех его кусках

...

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

Найти фрагментированый трафик легко - поставьте mtu пониже. Можно даже на конкретный маршрут (ip route add xxx via yyy mtu 1400 например).

 

Да, почитал, а то забыл всё уже. К сожалению, TCP заголовок не входит в фрагменты, а значит трансляцию "фрагментов" просто так не сделать. Для фрагментированных пакетов нужно писать отдельный механизм. Теоретически, всё можно сделать через идентификаторы, но это не 5 строчек точно 🙂 !

Может когда-нибудь и сделаю.....

Впрочем, может проще клиенту МТУ уменьшить ?!

[anp/hsw]

[anp/hsw]

Posted
Posted
11 часов назад, sdy_moscow сказал:

Впрочем, может проще клиенту МТУ уменьшить ?!

Очевидно, что каждому серверу в интернете mtu уже не уменьшить. А если бездумно уменьшать mtu клиенту, то это придется делать на всех устройствах. Допустим на роутере вы можете абоненту mtu задать через dhcp (и то не все поймут), но что делать с телефонами например, подключеными к этому роутеру?

Т.е. уменьшая mtu на клиенте вы генерируете еще больше фрагментированых пакетов, чем раньше.

dansoftware

dansoftware

Posted
Posted (edited)

Начало разговора тут: https://forum.nag.ru/index.php?/topic/129992-xyz-upal/&do=findComment&comment=1757361

 

15 часов назад, sdy_moscow сказал:

Вот поэтому и надо через АНАТ выносить таких в отдельный пул. Он умеет.

А он умеет как-то самостоятельно идентифицировать и автоматически выносить в отдельный пул таких мусорных абонентов или для идентификации необходим внешний инструмент?

Edited by dansoftware
sdy_moscow

sdy_moscow

Posted
  • Author
Posted
4 часа назад, [anp/hsw] сказал:

Очевидно, что каждому серверу в интернете mtu уже не уменьшить. А если бездумно уменьшать mtu клиенту, то это придется делать на всех устройствах. Допустим на роутере вы можете абоненту mtu задать через dhcp (и то не все поймут), но что делать с телефонами например, подключеными к этому роутеру?

Т.е. уменьшая mtu на клиенте вы генерируете еще больше фрагментированых пакетов, чем раньше.

Напомню, началось всё с того, что пакеты не влезали в туннель и возникла фрагментация (что само по себе не очень хорошо) ... так что уменьшать MTU надо у тех, кто за этими туннелями живет. У нас эта проблем как-то не проявляется остро, может абонентов поменее и еще не столкнулись с ней. Кстати отсечка в условии такая, что первый пакет пройдет, а вот последующие теряются (условие работает по полю OFFSET в IP header). Не знаю, но может это не очень правильно по RFC. По-хорошему, тут бы ICMP ответ не помешал для автоподстройки MTU. Может правилами файрвола это как-то  намудрить?

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
7 часов назад, dansoftware сказал:

А он умеет как-то самостоятельно идентифицировать и автоматически выносить в отдельный пул таких мусорных абонентов или для идентификации необходим внешний инструмент?

Автоматических скриптов которые это делают (идентифицируют + автоматически выносят) - нет, хотя при желании сделать можно. Это не DPI, это CGNAT.

 

Идентифицировать DDOS можно через превышение числа сессий в ANAT через счетчик OV_MSLIM  (настройка через  [CMD_USGR_SET_WRN]  ), с последующей маркировкой трафика с помощью --mark .

Скрытый текст

Это раньше был счетчик MANY SESSION LIMIT (это устаревшее название, правильно сейчас было-бы USER WARNING SESSION LIMIT.

 

Этот счетчик увеличивается на 1 когда число сессий у клиента в протоколе (UDP/TCP/ICMP/OTHER.) превысило параметр USR_WRN_SS_xxx по умолчанию 2024/2024/128/32. Он сам не сбрасывается, считается нарастающим итогом. Сбросить можно всю группу счетчиков OV.

Если он увеличивается, то скорее всего у кого-то вирусня или торент "анлим". Посмотреть у кого и что за трафик можно через буфер сообщений - событие  'W-ULIM'.

 

НО! Помимо DDOS есть еще АБУЗы, и IP в блэк листы чаще попадают из-за отсутствия реакции на них.  Счетчики превышений числа сессий ANAT стоят у нас на мониторинге, поймать у кого идет превышение можно через просмотр журнала событий ANAT $>cat /proc/net/ANAT/msga. По ним + АБУЗам идет постоянная работа со "спамерами". При минимальных усилиях админов это не плохо работает и в ручном режиме.

 

Если нет возможности спамерам выдать локальные адреса из отдельного пула, то сделайте --mark в правилах файрвола для IP спамеров и ддосеров в iptables,ДО передачи пакетов в ANAT от клиентов, например, с помощью ipset . Настройте в конфигурации ANAT выдачу внешних IP из выделенного диапазона для этого маркированного трафика !<mark>. После этого добавьте ip спамеров в список ipset и ваш основной пул не будет попадать постоянно в блэк листы, пока вы будете разбираться с клиентом.

 

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

 

Скрытый текст

Просто в настройках пулов поместите строчку с диапазоном локальных адресов спамеров <usr_ip_start> - <usr_ip_end> и (или) фильтром !0xXXXX по маркировке выше остальных настроек пулов.

 

Пример секции настройки пулов:

[CFG_NATPOLL_V2_0]

^S *H !0xFFFF : 70.100.100.66-70.100.100.68
172.0.0.0   - 172.0.0.255  : 70.100.100.69 - 70.100.100.82
80.100.100.65 - 80.100.100.165
[CFG_NATPOLL_END]

 

Первая строчка - маркированный 0xFFFF трафик натить в адреса 70.100.100.66-70.100.100.68 при этом для трасировки маркировать "S"

Вторая строчка - пользователей в адресами 172.0.0.0   - 172.0.0.255 натить  в адреса  70.100.100.69 - 70.100.100.82

Третья строчка - всех остальных натить в адреса  80.100.100.65 - 80.100.100.165

 

 

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
1 час назад, TheUser сказал:

Вы про классических спаммеров, по SMTP? Оно еще живо?

В основном абузы идут по сканированию сейчас. Спамеры - это скорее "собирательное" название. Большая часть проблем - вирусня.

AKim

AKim

Posted
Posted

Правильно понимаю, что ANAT не работает с тоннелями и программами, которые фрагментируют пакеты? 

[anp/hsw]

[anp/hsw]

Posted
Posted
20 часов назад, sdy_moscow сказал:

По-хорошему, тут бы ICMP ответ не помешал для автоподстройки MTU. Может правилами файрвола это как-то  намудрить?

Это pmtu discovery.

Можно вручную послать icmp fragmentation needed на нужный размер пакета, но это все равно сгенерирует фрагментированый пакет а не подстройку mtu. MTU может только клиент по своей воле подстроить и обычно это делается при создании интерфейса либо получении адреса по dhcp

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
4 часа назад, AKim сказал:

Правильно понимаю, что ANAT не работает с тоннелями и программами, которые фрагментируют пакеты? 

Да, но не совсем так. Если ваш туннель сам реализует фрагментацию, то проблем не будет (например PPTP или L2TP).  ANAT является наследником xt_NAT и проблемы возникают именно с классическим фрагментированным IP трафиком - он через него не пройдёт на данный момент, и не важно туннель это или нет. Это не что-то сверхъестественное и обычно решается настройками MTU. Полноценная NAT трансляция фрагментированного трафика требует реализации отдельного механизма трансляций.

 

Проблемы у @[anp/hsw]  возникли с IPSEC туннелями между интерфейсами с большими MTU.

 

https://devrockets.ru/2022/07/23/vsyo-pro-mtu-i-fragmentaciyu/

https://www.intact.ru/images/library/telecom/search/reshenie_problem,_svyazannih_s_fragmentaciey_ip.pdf  

sdy_moscow

sdy_moscow

Posted
  • Author
Posted
2 часа назад, [anp/hsw] сказал:

Это pmtu discovery.

Можно вручную послать icmp fragmentation needed на нужный размер пакета, но это все равно сгенерирует фрагментированый пакет а не подстройку mtu. MTU может только клиент по своей воле подстроить и обычно это делается при создании интерфейса либо получении адреса по dhcp

Да, но сейчас большинство приложений умеет подстраиваться под MTU.

Я бы еще попробовал запретить фрагментированный трафик и снять фильтры на ICMP 3,4.

https://rtfm.wiki/network/path-mtu-discovery-and-filtering-icmp

https://blog.cloudflare.com/path-mtu-discovery-in-practice/

 

Вот тут про IPSEC есть интересное:

https://www.intact.ru/images/library/telecom/search/reshenie_problem,_svyazannih_s_fragmentaciey_ip.pdf    - с 17-ой страницы

IPsec может сбрасывать, устанавливать или копировать бит DF из IP-заголовка пакета данных в IP-заголовок IPsec. Это называется функцией замещения бита DF (DF Bit Override Functionality).

 

Может просто надо настроить замещать DF  на 1 ? (см. стр.19)

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_dplane/configuration/zZ-Archive/DF_Bit_Override_Functionality_with_IPsec_Tunnels.html

[anp/hsw]

[anp/hsw]

Posted
Posted
1 час назад, sdy_moscow сказал:

сейчас большинство приложений умеет подстраиваться под MTU

Только tcp стек. С udp все очень сложно в этком плане.

Кроме того, не забывайте, что интернет это не только mtu 1500, следующий по популярности 1492, далее 1400...

Даже если вы заставите клиента сменить mtu, сервер вы заставить скорее всего не сможете. А mtu может быть разным с обоих сторон и это нормально.

1 час назад, sdy_moscow сказал:

Может просто надо настроить замещать DF  на 1

Это будет работать, если вы уравляете обоими концами тунеля. В корпоративной сети с централизованым управлением - да. В провайдерском CGNAT, где вы часто и клиента и сервер не контролируете - нет.

sdy_moscow

sdy_moscow

Posted
  • Author
Posted

@[anp/hsw] в общем-то я согласен, но сделать сейчас полноценную реализацию у меня нет времени. Хотя как сделать - понятно. Надо вводить дополнительные хэш таблицы для фрагментированного трафика. НО, если для исходящего еще можно сделать так, что порядок фрагментов будет не важен, то для входящего трафика так не получится. Первым пакетом должен прийти обязательно первый фрагмент. Если это не устроит, то только собирать пакеты  в целые ДО отправки их в ANAT средствами linux.

dryukov

dryukov

Posted
Posted

Фарагменты могут приходить дублированными, с потерями, задом наперед, перед заголовком и т.п. NAT это не сборщик пакетов и не DPI.
Можно добавить к хешу как опцию, но возможно сделает поиск проблем очень трудно определяемым тому кто это будет обслуживать.
Да и устройство может не поддерживать ID для всех соединений на один и тот же порт, один UDP сокет может принимать пакеты с разных IP, а если он сам за DNAT у него будет меняться только порт просящего.

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

Кроме того грузить роутер фрагментами это баг, а не фича.
Почему роутер решил сам всё фрагментировать и собирать вопрос, видимо ресурсов у него много очень.

Если нормально ICMP работает то черной дыры не должно быть, даже придя из интерната с 1500 на Ваш сегмент с 1400 пограничный ответит о необходимости фрагментации и по идеи этот ICMP должен дойти отправителю через сеть MTU 1500.
Но если где то, кто то воткнул ICMP DROP то не дойдет конечно. Либо супер NAT не отзеркалировал ICMP клиенту за NAT.

Да и чтобы в сети PPS на 2 не умножался тоже логично дропать.

Кроме того если человеки используют ipsec и будет еще где то один ipsec то эти огрызки производительность уложат, смотрим картинку того же микрота на 64 байт пакетах.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.