У меня есть маршрутизатор, выполняющий простую трансляцию NAT с использованием iptables iptables -t nat -o -j MASQUERADE
Это работает нормально почти всегда, за исключением одного конкретного случая, когда некоторые пакеты TCP RST и FIN покидают маршрутизатор без NAT.
В этом сценарии я настраиваю 1 или 2 клиентских компьютера для потоковой передачи Flash-видео (например, www.nasa.gov/ntv). Затем на маршрутизаторе я отключаю и повторно устанавливаю общедоступный интерфейс (который является модемом). Как и ожидалось, потоки Flash останавливаются. . После восстановления соединения и попытки обновить страницы Flash я вижу, что некоторые пакеты TCP RST и [FIN, ACK] покидают общедоступный интерфейс (я предполагаю, что Flash пытается восстановить свой поток).
Я не знаю, как эти пакеты могут покинуть маршрутизатор без NAT
Отбрасывая [RST, ACK] и [FIN, ACK] не будет работать. Есть много приложений, таких как загрузка по ftp, которые просто не подтверждают завершение передачи по FTP. Комментарии gscott - правильный метод, но необходимо еще одно дополнительное требование. Вы должны сделать их строгими, применяя политику
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -P INPUT DROP
При этом вам нужно указать все свои правила, иначе пакеты будут отброшены.
Спасибо за чаевые. Я был именно тем, что мне нужно, чтобы направить меня на верный путь.
Основной причиной была нефильтрованная пересылка между локальной сетью и публичным интерфейсом. Когда общедоступный интерфейс был отключен, он очистил записи conntrack. Затем клиенты попытались восстановить свои соединения и в итоге отправили пакеты RST и FIN. Поскольку NAT настраивается только для НОВЫХ подключений, эти пакеты оставляли маршрутизатор неизменным.
Мне пришлось изменить свое правило пересылки, чтобы разрешить пересылку только НОВЫХ, УСТАНОВЛЕННЫХ, СВЯЗАННЫХ пакетов из частной сети.
К вашему сведению
Другой способ предотвратить попадание пакетов FIN, ACK и RST, ACK в общедоступную сеть - заблокировать их в исходящей цепочке.
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST,ACK -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN,ACK -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL FIN -j DROP
iptables -I OUTPUT -s <internal net> -p tcp --tcp-flags ALL RST -j DROP
Это помогло мне предотвратить подделку пакетов.
Это может быть ошибка в цели MASQUERADE iptables. В вашем сценарии кажется, что у вас есть следующие совпадающие события:
Таким образом, попытка замаскировать пакет может потерпеть неудачу из-за недопустимого адреса, на который нужно замаскироваться, поэтому пакет маршрутизируется без изменений.
Ожидаемое поведение от цели MASQUERADE будет заключаться в очистке соответствующих записей состояния, когда интерфейс выходит из строя или меняет адрес, поэтому такой ситуации не должно было возникнуть. Но было обнаружена древняя ошибка iptables что звучит так, как будто это может вызвать подобное поведение.
Чтобы выполнить дальнейшее устранение неполадок, запишите общедоступный IP-адрес вашего маршрутизатора, воспроизведите проблему и взгляните на таблицу состояний, используя egrep 12.34.56.78 /proc/net/ip_conntrack (где 12.34.56.78 - это IP-адрес, который вы указали ранее). Если вы получаете строки conntrack со старым IP-адресом, несмотря на изменение адреса общедоступного интерфейса, вы, вероятно, столкнулись с ошибкой iptables - подумайте об обновлении ядра / iptables и сообщите о проблеме команде netfilter.