Дырявый NAT?!

Nat тупо не успевает обработать все пакеты?
А вообще как то подизвращенно все выглядит, канешн )))
Лоад авераж 0 или стремится к нему
на Dom0 лоад авераж временами достигает аж единицы. На ксеоне (8 потоков)
То есть чисто теоретически серв не есть нагружен.

ЗЫ: если НАТ не успевает обработать пакеты то они должны по идее становится в очередь, и при заполнении очереди терятся, т.е. дропаться.

ЗЗЫ: тихо фигею с ситуации... :(
 
Что я могу сказать, господа. Iptables напоминает мне английский язык, в котором нагородили 100500 времен, еще и разные залоги, типа так проще и яснее. Точно так же в недоразумении из недосистемы нагородили 100500 уникальных цепочек с собственными уникальными правилами (добавить drop в nat ни ни). Мне сложно предположить, что и сколько курил автор, нашедший такое удобным. Запрещающие правила добавлены везде, где только можно было, во всех быдлоцепочках всех быдлотаблиц. Стоит ли говорить, что эффекта никакого. Пакеты с немаршрутизируемым сорцом смотрят на это сетевое недоразумение вертикально ))
Было предположение, что это только в имбецильном пакет-бэйсд дэбилиане.. А н нет, кошерный центос натит точно также. У меня закралось подозрение, что айпитабловский нат или маскарадинг иначе не умеют, всегда будут пропущенные пакеты. Просто в большинстве случаев всем индифферентно на них, ни один нормальный человек не будет тисидампить на их предмет, если интернет на серых хостах есть. Однако в мире до сих пор есть гестапо и фашисты до сих пор мониторят трафик из танков "пантера" )))
В пока я констатирую факт отсутствия в линукс работоспособного ната и, соответственно, отсутствие сетевых возможностей.
Прошу форумчан проверить тисипидампом серые пакеты за линуксовым натом, если это возможно.
 
Возможно, почему б и нет? Проверено на 5 серваках по Харькову. Слакварь 12, 13, 13.37
Серых пакетов не обнаружено.
Возможно, виновник проблем - xen?
 
Возможно, почему б и нет? Проверено на 5 серваках по Харькову. Слакварь 12, 13, 13.37
Серых пакетов не обнаружено.
Возможно, виновник проблем - xen?

Леша, проверено на 3 шлюзах на линуксе - везде есть неотначенные пакеты, я еще 3 года назад был уверен, что это не победить.

Дополню, что нат начинает пропускать пакеты не транслируя, если начинается флуд или большая нагрузка.
Скорее всего пакеты просто не успевают маркироваться.
 
Леша, проверено на 3 шлюзах на линуксе - везде есть неотначенные пакеты, я еще 3 года назад был уверен, что это не победить.

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

Какая ОС, версия ее и версия ядра?
 
"Это не баг, это фича!" (с)

Лялик конечно говнецо еще то, то такого быть не может - тут явно виновата БДСМ связка Ксена и ЖРЕ.
Подумайте головой - если бы NAT(кстати, чо уж там ляликопоследователи не употреблялют "маскарадинг"?) пропускал серые пакеты, значит некоторая часть пакетов(читай запросов) просто не проходила и были бы "потери".
Красноглазики уже бы порвали разрабов.
 
"Это не баг, это фича!" (с)

Лялик конечно говнецо еще то, то такого быть не может - тут явно виновата БДСМ связка Ксена и ЖРЕ.
Подумайте головой - если бы NAT(кстати, чо уж там ляликопоследователи не употреблялют "маскарадинг"?) пропускал серые пакеты, значит некоторая часть пакетов(читай запросов) просто не проходила и были бы "потери".
Красноглазики уже бы порвали разрабов.

Пакет натится, но НЕ УДАЛЯЕТСЯ из маршрутизации, то есть по факту в интерфейс лезут два пакета, и отначеный и фейковый.
 
Пакет натится, но НЕ УДАЛЯЕТСЯ из маршрутизации, то есть по факту в интерфейс лезут два пакета, и отначеный и фейковый.

"Бред" (с)
Мы живем в 21 веке, iptables и Netfilter пилят уже надцать лет. Уже бы давно заметили и пофиксили.
Тут недавно в ядре фиксили баг в EXT4, который хрен поймаешь и то, подняли панику.

Кстати, думаем еще головой - в этом буржуйском ДЦ, кроме Принца еще дохрена Ляликов хостится и, тут, БАЦ! Баг с натом есть у всех, но только у Принца серые адреса лезут и его ругают за них?
 
"
Кстати, думаем еще головой - в этом буржуйском ДЦ, кроме Принца еще дохрена Ляликов хостится и, тут, БАЦ! Баг с натом есть у всех, но только у Принца серые адреса лезут и его ругают за них?

А что, многие натят в ДЦ?

"Это не баг, это фича!" (с)

Лялик конечно говнецо еще то, то такого быть не может - тут явно виновата БДСМ связка Ксена и ЖРЕ.
100%
Подумайте головой - если бы NAT(кстати, чо уж там ляликопоследователи не употреблялют "маскарадинг"?) пропускал серые пакеты, значит некоторая часть пакетов(читай запросов) просто не проходила и были бы "потери".
Красноглазики уже бы порвали разрабов.


А вот не видно этих потерь.
Ну допустим нат "течет", а почему айпитаблес не дропит эти пакеты в быдлоцепочках форвард и построутинг на мастере?

Леша, проверено на 3 шлюзах на линуксе - везде есть неотначенные пакеты, я еще 3 года назад был уверен, что это не победить.

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

Когда трафик идет только в одну виртуалку, неотначенных пакетов действительно почти нет. Когда запущено 10, начинается "течь" по всем.

Один баг - просто баг, много багов - линукс! (с)

Мы живем в 21 веке, iptables и Netfilter пилят уже надцать лет. Уже бы давно заметили и пофиксили.
Тут недавно в ядре фиксили баг в EXT4, который хрен поймаешь и то, подняли панику.
оно останется оном. Сколько его не пили. Виндовс тоже уже не один день существует. Как они его пилят, если одно и тоже ядро 2.6 подходит к разным дистрибутивам? Значит там ничего по сути не меняют, кроме устранения существующего бага и добавленяи трех новых. Linux-way.
 
Останнє редагування:
если по простому, то 26:D.
часть в просторечии никогда не используется.

Ну так и простые админы не используют 100500 цепочек айпитаблес. Только от коверкания выдуманного языка ничего страшного не происходит, а от коверкания айпитаблес ДЦ банят.
 
Развели тут холивар...

Я не знаю, что использовал Валера, но если б оно все текло везде, то разрабы уже давно ходили бы с оторванными руками.
Я подозреваю связку ксен+ксенбридж+нат
Уж очень ксен на дебилиане хроменький, как Росинант у Дон Кихота.

Насчет "многие ли натят в дц" - на внешнем наблюдается довольно много разностороннего IPSec. Отсюда вывод: туннелят, шифруют и натят. Может, и немногие, но мы там явно не одни.

ЗЫ: Еще вопрос почему не мой трафик наблюдается на моем ифейсе тоже непонятно...
 
Хетзнер, да?
И на что его поменять? На неВолю или триАнал?



Возвращаясь к теории о последовательности прохождения цепочек iptables:
NAT POSTROUTING - это предпоследняя цепочка для транзитных пакетов. И именно в ней осуществляется SNAT (MASQUERADE).
То есть, в нашей задаче хоть какое-то действие над уже почти вылетевшим из eth0 пакетом мы можем предпринять исключительно в MANGLE POSTROUTING (последняя цепочка джля транзитных пакетов)

Но почему-то iptables -t mangle -A POSTROUTING -o eth0 -s 172.16.0.0/16 -j DROP лупасит все, что пришло из подсети 172.16.0.0/16, даже уже с замененным сорцом, все улетает в дроп...
 
Останнє редагування:
Я ошибся. nat POSTROUTING идет уже после mangle POSTROUTING.

Но проблема, тем не менее решена, спасибо хлопцам с nag.ru
дело в том, что, как оказалось, все, что текло мимо НАТ - было безотносящимся к любому установленному соединению. т.е. в терминологии iptables - -m state --state INVALID.
поскольку INVALID - суть состояние пакета, который не относится ни к какому из установленных соединений, соответственно, conntrack проводит его мимо -j SNAT.

а убить это просто:
iptables -I FORWARD -m state --state INVALID -j DROP

Остается невыясненным последний вопрос: почему на Dom0 такое правило действует не на все пакеты, а продублированное на ВПС - решает проблему на 100%?
 
Я и i___ сказали бы тебе почему, но ты обидишься )))
 
Я и i___ сказали бы тебе почему, но ты обидишься )))

Нет, i___ не согласен. Он несколько вник в iptables и даже получил адресную помощь на nag.ru. Он скромно констатирует, что несколько погорячился в адрес linux. Скажу больше после pf серые пакеты также проходят. Интересно, как обстоит дело в нат в виндовс.
Можно сделать выводы:
- после nat все-таки остаются пакеты с исходным сорцом, которые надо фильтровать, о чем не сказано в большинстве "эммануэль" про nat
- вконтакте есть неправильные схемы прохождения пакетов в iptables, надо смотреть официальный сайт проект
- nag.ru - сила
- tcpdump все-таки смотрит на интерфейс
- различия пакетов на выходе виртуалки и на выходе родителя можно объяснить особенностями xen bridge
- победа разума над инстинктами в отдельно взятом дц произошла. УРяяяяяяяяяяяяяяяяяяяяяяяя, товарищи!
 
Останнє редагування:
Ты нам так и не показал как ты делал NAT.
Может проще пропускать ответы только на запросы?
iptables -t nat -A POSTROUTING -s <ИП источника> -j SNAT --to <ИП сервера>
пробовался вариант
iptables -t nat -A POSTROUTING -s <ИП источника> -j MASQUERADE
разницы (в рамках данного проекта) никакой.

А что, есть новые интересные способы "делать NAT"? Я таковых не знаю, увы. С интересом выслушаю.

Пропускать ответы только на запросы не проще.
 
Назад
Зверху Знизу