[AlKov]

Разбираясь с in discards на порту аплинка (порт 28 DGS-3420), обнаружил во входящем трафике IP из privat network.

Которые, похоже, и попадают в in discard (route в NULL на интерфейсе DGS).

Провайдера уведомил, жду комментариев.

Заодно решил посмотреть ситуацию на этом же порту со своей стороны.

Обнаружил там небольшой исходящий траф из "абонентской" сети (172.16.0.0/12).

Причём только исходящий. Типа такого: 

tcpdump -nn -i vlan62 src net 172.16.0.0/12
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan62, link-type EN10MB (Ethernet), capture size 65535 bytes
16:10:47.356822 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.357555 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.358528 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.359511 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.360488 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.361301 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.362974 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.363433 IP 172.16.16.251.39704 > 92.38.147.147.443: Flags [R], seq 877107705, win 0, length 0
16:10:47.642626 IP 172.16.1.115.55898 > 156.234.201.18.80: Flags [R.], seq 2140482065, ack 1575333553, win 0, length 0
16:10:47.674930 IP 172.16.10.74.44032 > 179.43.146.42.853: Flags [R], seq 238405226, win 0, length 0
16:10:47.674944 IP 172.16.10.74.44032 > 179.43.146.42.853: Flags [R], seq 238405226, win 0, length 0

Не пойму, что это за траф и как он пролезает через NAT?

NAT такой - 

-A POSTROUTING -s 172.16.0.0/12  -o vlan62 -m set --match-set uplink src -j SNAT --to-source 111.222.200.137-111.222.200.190 --persistent

В ipset uplink список тех самых 172.16...

Манипуляции с цепочкой FORWARD (удаление из неё правила)

-A FORWARD -s 172.16.0.0/12 -o vlan62 -j ACCEPT

приводят только к полному пропаданию трафика..

 

Пока временно повесил на входящий порт DGS-а (от бордера) ACL с запретом 172.16.0.0/12.

На аплинке исходящий от 172.16... пропал, но на "выходе" бордера всё по-прежнему..

[Ivan_83]

8 hours ago, AlKov said:

Не пойму, что это за траф и как он пролезает через NAT?

Не удивлюсь если это ваш сервер такое генерит, через какойнить -j reject.

Советую добавить -e и дальше по макам искать источник.

[AlKov]

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

Советую добавить -e и дальше по макам искать источник.

Добавил, но ничего не прояснилось.. 

Source MAC = MAC бордера (интерфейс с VLAN 62)

Dest MAC = MAC интерфейса на коммутаторе (также на VLAN 62)

Легальный трафик идёт в точности так же. Только с NAT SRC IP, а не со 172.16.ххх

 

А это не могут быть какие-нибудь абонентские VPN-ы?

[disappointed]

1. Исключить "правило исключения" для этой сетки выше правила ната.

2. Взять какой-то активный внутренний ip и снять со стороны локалки дамп в несколько секунд,

проанализировать в wireshark что там происходит и почему так много ресетов подряд идёт. Можно даже два дампа, один с локалки второй с wan одновременно.

[AlKov]

17 часов назад, disappointed сказал:

1. Исключить "правило исключения" для этой сетки выше правила ната.

Не понял.. Какое правило "выше правила NAT"?? В POSTROUTING "выше" нет ничего для этой подсети.

17 часов назад, disappointed сказал:

2. Взять какой-то активный внутренний ip и снять со стороны локалки дамп в несколько секунд,

проанализировать в wireshark

А на что обращать внимание?

 

P.S. Что примечательно, наряду с "левым" мелким трафиком, от этого же IP идёт вполне легальный (уже "отначеный"), более "жирный".

Т.е. получается как бы основная часть трафика идёт как положено, через NAT, а вторая, мелкая, NAT пытается обойти..

Бред какой-то... 😞

 

[disappointed]

В примере только R - это tcp с флагом ресет, ещё и пачками подряд. Выглядит странно.

Может там помимо R какой-то флаг ещё стоит противоречивый и поэтому трансляция из conntrack не подтягивается и оно в FORWARD уходит как есть.

Или вообще это не фильтр ли по реестру РКН за бордером спуфит эти 172 адреса разрывая коннекты.

 

Я тут посмотрел у себя и увидел на аплинках, РТ, Мега, идёт множество входящих пакетов с bogons сетей, у меня есть публичный NTP, вот на него идёт большое кол-во обращений со всяких 192 172 10.х.х.х. Скорее всего частично неотНАТтченный трафик в каком-то соотношении, это норма для интернета.

[AlKov]

16 часов назад, disappointed сказал:

В примере только R - это tcp с флагом ресет, ещё и пачками подряд. Выглядит странно.

Может там помимо R какой-то флаг ещё стоит противоречивый и поэтому трансляция из conntrack не подтягивается и оно в FORWARD уходит как есть.

Есть ещё какие-то, не понятные флаги: "R.", "F.", "FP." С "точкой" в конце.

 

09:26:17.047681 IP 172.16.11.234.49478 > 178.248.237.177.443: Flags [R.], seq 4272666895, ack 1918564764, win 0, length 0
09:26:17.047866 IP 172.16.11.234.49467 > 178.248.237.177.443: Flags [R.], seq 2418366493, ack 1006666028, win 0, length 0
09:26:17.048139 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 2411951325, ack 2392870919, win 259, length 0
09:26:17.347547 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0
09:26:17.566650 IP 172.16.14.144.34852 > 213.180.204.145.443: Flags [R], seq 3070305443, win 0, length 0
09:26:17.807372 IP 172.16.4.151.52172 > 51.195.92.136.853: Flags [R], seq 2005766074, win 0, length 0
09:26:17.807919 IP 172.16.4.151.52172 > 51.195.92.136.853: Flags [R], seq 2005766074, win 0, length 0
09:26:17.821778 IP 172.16.4.151.56056 > 79.127.215.167.853: Flags [R], seq 3939105740, win 0, length 0
09:26:17.823751 IP 172.16.4.151.56056 > 79.127.215.167.853: Flags [R], seq 3939105740, win 0, length 0
09:26:17.907050 IP 172.16.4.151.60832 > 54.38.198.100.853: Flags [R], seq 2185298091, win 0, length 0
09:26:17.907634 IP 172.16.4.151.60832 > 54.38.198.100.853: Flags [R], seq 2185298091, win 0, length 0
09:26:17.908256 IP 172.16.4.151.52588 > 179.43.146.42.853: Flags [R], seq 1130723839, win 0, length 0
09:26:17.908748 IP 172.16.4.151.52588 > 179.43.146.42.853: Flags [R], seq 1130723839, win 0, length 0
09:26:17.944726 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0
09:26:19.150483 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0
09:26:19.182651 IP 172.16.12.223.44204 > 167.235.118.99.443: Flags [R], seq 3342213979, win 0, length 0
09:26:19.182670 IP 172.16.12.223.44204 > 167.235.118.99.443: Flags [R], seq 3342213979, win 0, length 0
09:26:19.267903 IP 172.16.12.223.48284 > 167.235.118.104.443: Flags [R], seq 2762067003, win 0, length 0
09:26:19.268051 IP 172.16.12.223.48284 > 167.235.118.104.443: Flags [R], seq 2762067003, win 0, length 0
09:26:20.007961 IP 172.16.3.41.64407 > 142.250.74.67.443: Flags [FP.], seq 4294967272:0, ack 1, win 388, options [nop,nop,TS val 3191474899 ecr 2887551799], length 24
09:26:21.545559 IP 172.16.11.234.49477 > 142.251.1.104.443: Flags [F.], seq 0, ack 1, win 259, length 0

16 часов назад, disappointed сказал:

Или вообще это не фильтр ли по реестру РКН за бордером спуфит эти 172 адреса разрывая коннекты.

Возможно. Фильтрация РКН у нас от аплинка.

Но почему они с моей стороны мимо НАТа лезут?? Это же мои клиенты шлют ресеты..

16 часов назад, disappointed сказал:

Скорее всего частично неотНАТтченный трафик в каком-то соотношении, это норма для интернета

Гм.. Мир перевернулся.. Всегда считал, что PRIVAT IP в Интернет - это нонсенс..

Ну или дурной тон, в лучшем случае.

 

P.S. В принципе, можно было бы и забить на это всё, но у меня есть сильные подозрения, что от этого "мусора" со стороны провайдера страдает мой бордер.

Уж очень совпадают всплески CPU LOAD по времени..

 

[ixi]

В 15.03.2024 в 17:14, AlKov сказал:

Не пойму, что это за траф и как он пролезает через NAT?

отсутствует в conntrack? попробуйте зафильтровать ct state invalid

[AlKov]

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

попробуйте зафильтровать ct state invalid

Помогло! За 10 мин. всего 8 icmp пакетов. Всё остальное исчезло.

Благодарю!

 

P.S. Вот как бы ещё дискарды убрать с аплинка.. 

Может убрать с DGS-а NULL route PRIVAT net? Завернуть их на бордер. Нехай он их дропает.

Или вообще, обратно прову вернуть по дефаулт роут?

ACL что-то не помогают, хотя счётчик на аплинке тикает..

[bike]

В 18.03.2024 в 10:00, AlKov сказал:

Гм.. Мир перевернулся.. Всегда считал, что PRIVAT IP в Интернет - это нонсенс..

Ну или дурной тон, в лучшем случае.

Хороший тон - на аплинках бордера все bogons net зарезать на корню и не забыть про свои сети на вход тоже.

[AlKov]

1 минуту назад, bike сказал:

Хороший тон - на бордере все bogons net зарезать на корню и не забыть про свои сети на вход тоже.

Это я уже сделал. Остался пров, который продолжает лить ко мне "левак".

И задавать при этом весьма интересные вопросы - 

Цитата

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

Мол чё тебе, парниша, весёлые картинки не нравятся?! :)

[ixi]

2 часа назад, AlKov сказал:

И задавать при этом весьма интересные вопросы - 

Скажите, что вопросы о левых адресах возникают у сорма, который вы фильтровать не можете :)

 

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

[disappointed]

5 часов назад, AlKov сказал:

Гм.. Мир перевернулся.. Всегда считал, что PRIVAT IP в Интернет - это нонсенс..

Ну или дурной тон, в лучшем случае.

Вон 50 в сек фигачит круглосуточно, и это из 8к легитимных запросов на текущий момент. т.е. 0,5% всегда летит кривых. 

 

[Ivan_83]

On 3/17/2024 at 2:04 PM, disappointed said:

публичный NTP, вот на него идёт большое кол-во обращений со всяких 192 172 10.х.х.х. Скорее всего частично неотНАТтченный трафик

А в каком документе указанная сеть обозначена как приватная?

[sirmax]

21 минуту назад, Ivan_83 сказал:

А в каком документе указанная сеть обозначена как приватная?

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

https://noname.com.ua/mediawiki/index.php/Bogon

 

(Автор не я, это копипаста)

оригинал я не найду но номера rfc там есть

[alibek]

Я на офисном роутере фильтрую на WAN следующие префиксы:

0.0.0.0/8 #source this
10.0.0.0/8 #private network
100.64.0.0/10 #CG-NAT
127.0.0.0/8 #loopback addresses
169.254.0.0/16 #link-local subnet
172.16.0.0/12 #private network
192.0.0.0/24 #reserved
192.0.2.0/24 #test network
192.42.172.0/24 #non-work
192.88.99.0/24 #anycast relay
192.168.0.0/16 #private network
198.18.0.0/15 #test inter-network
198.51.100.0/24 #test network
203.0.113.0/24 #test network
224.0.0.0/4 #multicast
240.0.0.0/4 #reserved

 

Номера RFC не помню, но лишних записей там нет.

[AlKov]

10 часов назад, Ivan_83 сказал:

А в каком документе указанная сеть обозначена как приватная?

RFC1918

[AlKov]

Вот ещё нарыл на аплинке 

Цитата

11:02:04.643745 c0:a0:bb:dd:ee:11 > cf:00:00:00:00:00, ethertype 802.1Q (0x8100), length 64: vlan 0, p 6, ethertype Loopback (0x9000), Loopback, skipCount 0,  invalid (256)
11:02:04.694822 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 79.124.59.82.48817 > 194.XXX.XXX.XXX.5553: Flags [S], seq 692414600, win 1024, length 0
11:02:05.950758 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 80.66.83.161.56473 > 194.XXX.XXX.XXX.8800: Flags [S], seq 3990995619, win 1024, length 0
11:02:11.337231 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 80.82.64.107.59592 > 194.XXX.XXX.XXX.23144: Flags [S], seq 3773374537, win 1024, length 0
11:02:12.808946 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 176.113.115.130.43550 > 194.XXX.XXX.XXX.13175: Flags [S], seq 3704742688, win 1024, length 0
11:02:14.643184 c0:a0:bb:dd:ee:11 > cf:00:00:00:00:00, ethertype 802.1Q (0x8100), length 64: vlan 0, p 6, ethertype Loopback (0x9000), Loopback, skipCount 0,  invalid (256)
11:02:16.732217 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 5.188.206.14.50996 > 194.XXX.XXX.XXX.61642: Flags [S], seq 2919258356, win 1024, length 0
11:02:17.250392 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 79.124.58.166.49529 > 194.XXX.XXX.XXX.51102: Flags [S], seq 2786812139, win 1024, length 0
11:02:17.899934 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 80.66.83.161.56473 > 194.XXX.XXX.XXX.9562: Flags [S], seq 3674618507, win 1024, length 0
11:02:19.272747 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 79.124.59.82.48817 > 194.XXX.XXX.XXX.26696: Flags [S], seq 2771527444, win 1024, length 0
11:02:21.230664 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 80.82.64.107.59592 > 194.XXX.XXX.XXX.64734: Flags [S], seq 2428959945, win 1024, length 0
11:02:23.633452 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 162.216.150.78.56078 > 194.XXX.XXX.XXX.13408: Flags [S], seq 2818192980, win 1024, options [mss 1460], le
ngth 0
11:02:24.644920 c0:a0:bb:dd:ee:11 > cf:00:00:00:00:00, ethertype 802.1Q (0x8100), length 64: vlan 0, p 6, ethertype Loopback (0x9000), Loopback, skipCount 0,  invalid (256)
11:02:25.008637 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 80.66.83.163.56570 > 194.XXX.XXX.XXX.15466: Flags [S], seq 631913427, win 1025, options [mss 1460], lengt
h 0
11:02:28.712130 ac:3a:67:fff:ff:ff > c0:a0:bb:dd:ee:01, ethertype 802.1Q (0x8100), length 64: vlan 63, p 0, ethertype IPv4 (0x0800), 79.124.58.166.49529 > 194.XXX.XXX.XXX.39562: Flags [S], seq 1336142042, win 1024, length 0

 

Вот эти " Loopback (0x9000), Loopback, skipCount 0" - не есть ли причина discard packet и загруза CPU?

И вообще, что это за петли?  routing loops, или что-то другое? И чья сторона является причиной?

[disappointed]

7 часов назад, AlKov сказал:

Вот ещё нарыл на аплинке 

 

Вот эти " Loopback (0x9000)

 

Это стандартные тесты на петлю от свитчей.

[AlKov]

16 часов назад, disappointed сказал:

Это стандартные тесты на петлю от свитчей.

Про это я в курсе. Но.. С чего бы им появляться, да ещё со статусом "invalid"? Это разве тоже нормально?

 

Вот смотрите, что за ситуация происходит:

194.XXX.XXX.XXX/30 - это мой "линковочный" IP.

На него с какого-то перепугу пров шлёт мне "чужие" IP, про которые бордер ничего не знает и честно оправляет их взад (в дефаулт) прову.

Шлюз со стороны прова имеет IP из 194.XXX.XXX.XXX/30.

Предполагаю, что отсюда и вылезают те самые Loopback.

Или я ошибаюсь?

[witch]

может у аплинка proxy arp включён?

[AlKov]

31 минуту назад, witch сказал:

может у аплинка proxy arp включён?

Да хз.. Общаюсь по е-мейл через "говорящие головы" ТП, которые только пересылают инфу к технарям и обратно.

Но надо отдать должное - помойку из bogon network всё же сегодня они мне ликвидировали. :-)

Квест с loopback пока не пройден..

[witch]

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

Квест с loopback пока не пройден..

Лупбеки же бегают на Л2. Очень на прокси арп похоже.

[disappointed]

4 часа назад, AlKov сказал:

Предполагаю, что отсюда и вылезают те самые Loopback.

Или я ошибаюсь?

 

Всё показаное выше так и должно выглядеть. Это просто включённый LBD, точно также как у вас на доступе он включён.

 cf:00:00:00:00:00 - стандартно, инвалид для этого типа - всегда так и было в tcpdump, это не статус.

[AlKov]

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

Это просто включённый LBD, точно также как у вас на доступе он включён.

Выключил LBD на порту аплинка - ничего не изменилось..

 

P.S. Глянул на "нормальном" аплинке на предмет Loopback - "левый траф" прилетает (причём, с тех же самых IP!!), но петель нет..

Походу, это всё-таки какие-то "неправильные пчёлыLoopback".

 

P.P.S. Интересный каламбурчик вышел про неправильных пчёл. "Кривой" аплинк как раз "пчелиный" (Beeline) 🙂