Linux шлюз. Случайная блокировка траффика.

MTU?

И да, вконтакт не нужен

Проверяю с одного и того же компа одного и того же свича. На vlan 2 ip прибито.

net.ipv4.conf.default.rp_filter = 1

попробуй закомментировать

Закомментил sysctl -p таже фигня

пинги проходят идеально, telnet vk.com 80 - неале.

пинги ходят — значит с маршрутами всё ОК.

запросы приходящие на локальный инетрфейс сервера ни чем друг от друга не отличаются. Размеры пакета, структура, адреса, все одинаково. Только на 10.10.1.1 не приходят ответы от vk.com.

с vlan тоже порядок

Есть у кого хотябы предположения, куда копать? Чем такая «избирательность» может быть вызвана?

я бы проверил правила iptables, особенно обращая внимание на маски сетей

чему равно net.ipv4.netfilter.ip_conntrack_max? И отключи syn_cookies - на роутере они не нужны(хотя и не вредны, вроде)

dmesg

net.netfilter.nf_conntrack_generic_timeout = 600
net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 120
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 60
net.netfilter.nf_conntrack_tcp_timeout_established = 432000
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close_wait = 60
net.netfilter.nf_conntrack_tcp_timeout_last_ack = 30
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_close = 10
net.netfilter.nf_conntrack_tcp_timeout_max_retrans = 300
net.netfilter.nf_conntrack_tcp_timeout_unacknowledged = 300
net.netfilter.nf_conntrack_tcp_loose = 1
net.netfilter.nf_conntrack_tcp_be_liberal = 0
net.netfilter.nf_conntrack_tcp_max_retrans = 3
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.netfilter.nf_conntrack_icmp_timeout = 30
net.netfilter.nf_conntrack_acct = 1
net.netfilter.nf_conntrack_events = 1
net.netfilter.nf_conntrack_events_retry_timeout = 15
net.netfilter.nf_conntrack_max = 65536
net.netfilter.nf_conntrack_count = 65535
net.netfilter.nf_conntrack_buckets = 16384
net.netfilter.nf_conntrack_checksum = 1
net.netfilter.nf_conntrack_log_invalid = 0
net.netfilter.nf_conntrack_expect_max = 256
net.nf_conntrack_max = 65536

Изменил
net.netfilter.nf_conntrack_max = 1048576
net.nf_conntrack_max = 1048576
Также фигня. Легче не стало.
dmesg ничего про отбрасываемые пакеты не говорит.

ethtool -S <iface>

Внутренний ethtool -S eth1
NIC statistics:
rx_packets: 415851724
tx_packets: 423273452
rx_bytes: 288972037283
tx_bytes: 421636332205
rx_broadcast: 69795
tx_broadcast: 863
rx_multicast: 103282
tx_multicast: 3792
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 103282
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 337
rx_missed_errors: 354
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 26
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 407
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 288972037283
rx_csum_offload_good: 405977381
rx_csum_offload_errors: 187
rx_header_split: 0
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0
rx_dma_failed: 0
tx_dma_failed: 0


Внешний ethtool -S eth0
NIC statistics:
rx_packets: 468353106
tx_packets: 434500200
rx_bytes: 427953662049
tx_bytes: 291994413376
rx_broadcast: 620
tx_broadcast: 521
rx_multicast: 0
tx_multicast: 10
rx_errors: 0
tx_errors: 0
tx_dropped: 0
multicast: 0
collisions: 0
rx_length_errors: 0
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_no_buffer_count: 2425
rx_missed_errors: 3228
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
tx_abort_late_coll: 0
tx_deferred_ok: 0
tx_single_coll_ok: 0
tx_multi_coll_ok: 0
tx_timeout_count: 0
tx_restart_queue: 1
rx_long_length_errors: 0
rx_short_length_errors: 0
rx_align_errors: 0
tx_tcp_seg_good: 0
tx_tcp_seg_failed: 0
rx_flow_control_xon: 0
rx_flow_control_xoff: 0
tx_flow_control_xon: 0
tx_flow_control_xoff: 0
rx_long_byte_count: 427953662049
rx_csum_offload_good: 406682531
rx_csum_offload_errors: 5964
alloc_rx_buff_failed: 0
tx_smbus: 0
rx_smbus: 0
dropped_smbus: 0

Заметил следствие из проблемы. Если сделать так:
-A POSTROUTING -s 10.0.0.0/16 -j SNAT --to-source xx.xxx.xxx.xx
-A POSTROUTING -s 10.1.0.0/16 -j SNAT --to-source xx.xxx.xxx.xy
-A POSTROUTING -s 10.2.0.0/16 -j SNAT --to-source xx.xxx.xxx.xz
-A POSTROUTING -s 10.10.0.0/16 -j SNAT --to-source xx.xxx.xxx.zz

То все у всех работает. Какая-то связь между количеством натящихся адресов. Есть предположения, с чем это может быть связано?

gich ventilator

Воздержитесь от ответов на провокации и оскорбления, я их тру.

Ну если учесть, что броузер открывает сразу кучу коннектов для параллельного скачивания сайта, то на 2000 пользователей это получается: 65535 / 2000 =~ 30 коннектов на юзера. Совсем не много. Так что нать сразу на несколько айпишников.

PS: Модератор, не надо стирать корректные сообщения.

Некоторые ресурсы вполне могут лимитировать количество запросов с одного адреса.

кроме того 65535 / 2000 =~ 30 коннектов на юзера _на один_ дестинейшн адрес+порт. Вряд ли все юзеры ломятся на один сервер.

Потому лимита на количество сессий к разным серверам особо нет, у нас вот до 150к сессий на один ип ната.

«ответы не приходят» на внутреннем интерфейсе смотриш или который в мир?

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

Как ты раньше в это не упёрся? Мы пока не разбросали людей так, что б получалось по 200-300 на ip у людей icq не работала. Там ограничение, по крайней мере раньше было, у них на кол-во коннектов с одного ip.

Скорее всего вконтакт просто блокировал твой айпи в качестве защиты от ддоса.

Сейчас я сделал в SNAT пул на 10 внешних IP. Есть ли какой-то способ расчета потребного количества адресов в пуле? Может, ему 20 лучше.
А вот почему раньше не уперся-не смогу сказать. Все открывалось вроде.Бывали иногда какие-то странные глюки, но радикально такого, чтобы выловить явно и поднять в условиях лабы - как-то не случалось.

К слову по поводу icq. Миранда на пример, очень плохо коннектилась последние месяца 2.

Знает ли кто как iptables распоеделяет адреса в пуле?

Если указан пул вида --to-source 1.1.1.1-100, то коннекты по пулу распределяются рандомно.

У меня сейчас сделано так:
-A POSTROUTING -s 10.0.0.0/8 ! -d 10.0.0.0/8 -j SNAT --to-source xx.xx.xx.1-xx.xx.xx.9 --persistent
К слову, если не указать в iptables snat pool опцию --persistent, то icq не будет работать, будет отвалилваться или плохо работать потоковая передача данных - видео, музыка. Я так понимаю, что оптимально на 200-300 человека добавлять по 1 адресу на пул?

net.core.wmem_default net.core.rmem_default net.core.wmem_max net.core.rmem_max net.core.somaxconn net.ipv4.ip_conntrack_max и default (важно для NAT)

Чукча не читатель, чукча писатель. Накопировал из гугла да.

net.core.wmem_default
net.core.rmem_default
net.core.wmem_max
net.core.rmem_max
net.core.somaxconn

Нука расскажи нам как это вообще к нату и маршрутизации относится?

PS: для ната есть практически две крутилки

net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_buckets

Причем net.netfilter.nf_conntrack_buckets нужно устанавливать в значение равное максимуму net.netfilter.nf_conntrack_count

вообще-то не из гугла.;)

из sysctl.conf

net.netfilter.nf_conntrack_max крутил ровно 1 раз

net.netfilter.nf_conntrack_max обсудили в самом начале.

ну я как бы лезть и не стал с ними поэтому. но вот похожие проблемки видел из-за net.core.wmem_max. услвоия были специфичечкие но всё же.

net.core.wmem_max не имеет никакого отношения к транзитному трафику.

ню-ню.;-)