Comments 6
В принципе, это нормальное поведение для UDP в Linux.
Удивлен, что TCP у клиентов (которые через FORWARD ходят) нормально работает...
У меня при включенной round-robin default gateway маршрутизации TCP-соединение отказывалось устанавливаться, потому что round-robin происходил на уровне пакетов, а не на уровне соединений: т.е. первый пакет TCP-сессии идет через один гейтвей, второй через другой. TCP-сервер соответственно не ожидает, что второй пакет придет с другого IP, и соединение не устанавливается.
Что интересно, TCP-соедиения, устанавливаемые с самого Debian-маршрутизатора, работают в такой схеме нормально.
У меня при включенной round-robin default gateway маршрутизации TCP-соединение отказывалось устанавливаться, потому что round-robin происходил на уровне пакетов, а не на уровне соединений: т.е. первый пакет TCP-сессии идет через один гейтвей, второй через другой. TCP-сервер соответственно не ожидает, что второй пакет придет с другого IP, и соединение не устанавливается.
Что интересно, TCP-соедиения, устанавливаемые с самого Debian-маршрутизатора, работают в такой схеме нормально.
Позвольте поинтересоваться — а зачем вам вообще rr default gw? Не могу представить себе ситуацию в которой он будет реально нужен...
Речь конечно не идет об острой необходимости. Ситуация такова, что есть два своих провайдера с узкими каналами и третий с широким, но пустить туда весь трафик нельзя по определенным причинам. Поэтому было решено распределять нагрузку на всех троих более или менее равномерно. RRDG и является таким решением. Что характерно, после включения пользователи отметили, что "интернет стал быстрее".
Sign up to leave a comment.
Round-robin default gateway ломает маршрутизацию от источника для OpenVPN сервера