☰

Странная потеря пакетов через NAT с двумя интерфейсами WAN

tag-icon • tag-icon linux networking routing nat
Странная потеря пакетов через NAT с двумя интерфейсами WAN

У меня есть серверная машина Linux, которую я также использую как сетевой шлюз / "маршрутизатор". У нее три активных сетевых интерфейса – два сетевых интерфейса подключены к Интернету через разных провайдеров, а третий обеспечивает доступ к Интернету для моих локальных машин через NAT. У меня есть балансировка нагрузки между WAN-линками.

С сервера сеть доступна просто отлично — все работает, балансировка нагрузки работает и в целом нет потерь пакетов. Соединения между сервером и локальными машинами тоже работают совершенно нормально. Но если я выхожу в интернет/WAN с локальной машины через сервер, я всегда вижу постоянную потерю пакетов ~40%. Это делает соединения очень нестабильными. Немного поразмыслив, я увидел, что я получаю (и теряю) пакеты, проходящие через оба интерфейса, более или менее одинаково, так что этонеткак будто один из интерфейсов будет тормозить работу всех остальных, теряя все свои пакеты.

Если я отключу любой из двух WAN-каналов, эта потеря пакетов мгновенно исчезнет. Она мгновенно появится снова, если я снова включу оба WAN-канала.

Что могло вызвать это? Есть ли какие-нибудь подсказки, как устранить эту проблему, не отказываясь от одного из каналов WAN?

моя iptablesтаблица фильтров:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

моя iptablesтаблица NAT:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.42.0.0/24        !10.42.0.0/24

моя iptablesтаблица Mangle:

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0            mark match ! 0x0
MARK       all  --  0.0.0.0/0            0.0.0.0/0            state NEW MARK set 0x2
MARK       all  --  0.0.0.0/0            0.0.0.0/0            state NEW statistic mode random probability 0.50000000000 MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

ip route showвыход:

default 
    nexthop via 10.7.0.254  dev eth0 weight 1
    nexthop via 78.62.255.254  dev eth2 weight 1
10.7.0.0/16 dev eth0  proto kernel  scope link  src 10.7.5.102 
10.42.0.0/24 dev eth1  proto kernel  scope link  src 10.42.0.254 
78.62.192.0/18 dev eth2  proto kernel  scope link  src 78.62.239.10 
169.254.0.0/16 dev eth1  scope link  metric 1000

все не отредактировано, как есть – не особо беспокойтесь о «конфиденциальности» в данном случае

решение1

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

Для правильной балансировки нагрузки NAT вам необходимо правило предварительной маршрутизации в таблице mangle, случайным образом помечающее новые потоки как 1 или 2, вам необходимы ip ruleправила маршрутизации пакетов, помеченных как 1, на интерфейс WAN 1, а пакетов, помеченных как 2, на интерфейс WAN 2, а также вам необходимы отдельные правила SNAT в iptablesтаблице NAT, по одному для каждого интерфейса WAN.

Более подробное описание см. Коротко о балансировке нагрузки Iptables Диего Лимы

Связанный контент