Невозможно сделать это с 192.168.1.1 и 192.168.1.2 на одном и том же сетевом интерфейсе шлюза, таким образом разрешая один и тот же MAC-адрес. Это не функция, не реализованная в iptables которая может быть реализована, это функция, которая не может быть реализована из-за того, как работает IP-сеть.
Клиент, использующий 192.168.1.1 или 192.168.1.2 в качестве шлюза, никогда не отправит ни одного пакета IPv4 с адресом 192.168.1.1 или 192.168.1.2 при отправке пакетов в Интернет. Будет:
- обратитесь к его таблице маршрутизации для данного пункта назначения
- найти, что есть шлюз для этого пункта назначения
- Использовать ARP или кэшированная запись для разрешения адреса L2 (MAC-адреса Ethernet), необходимого для доступа к шлюзу.
Последний шаг будет иметь только одно назначение Ethernet: уникальный MAC-адрес сетевой карты шлюза: то же самое для клиента со шлюзом 192.168.1.1 или другого клиента со шлюзом 192.168.1.2.
Таким образом, каждый клиент теперь отправит шлюзу пакет со своим адресом источника IPv4, предполагаемый пункт назначения IPv4 в кадре Ethernet имеет один и тот же MAC-адрес назначения Ethernet в обоих случаях. 192.168.1.1/192.168.1.2 не работает.
Теперь шлюз видит два пакета для маршрутизации. Ни в коем случае эти пакеты больше не намекают, если они использовали 192.168.1.1 или же 192.168.1.2 в качестве шлюза: информация не появляется в проводной сети, поэтому шлюз не может быть известен где-либо. Если в системе нет информации для различения случаев, то iptables также не может иметь этой несуществующей информации.
Предложение обходного пути:
Можно использовать МАКВЛАН интерфейса, чтобы иметь вторую сетевую карту с собственным отдельным MAC-адресом и вместо этого назначить ему 192.168.1.2/24, в результате чего пакеты от клиентов, использующих 192.168.1.2 в качестве шлюза, будут поступать на эту сетевую карту. Этот случай легко отличить от iptables: отличающийся -i сетевая карта фильтр.
Но это создает проблему маршрутизации из-за наличия нескольких сетевых карт в одной локальной сети и требует:
расширенные правила маршрутизации политики для правильного решения этого случая
поэтому ответы не отправляются через неправильную сетевую карту, что может повлиять на поведение маршрутизации или правила брандмауэра.
- и, кроме того, любая служба UDP, запрашиваемая на 192.168.1.2 (если 192.168.1.1 используется по умолчанию), должна знать, как ответить с правильным исходным адресом 192.168.1.2 (вместо 192.168.1.1 по умолчанию): она должна быть многосетевой. осведомленный. TCP не требует особого ухода.
или же дополнительное сетевое пространство имен для отделения добавленного интерфейса. Но с правилом REDIRECT это означает, что служба на порту 9992 вместо этого должна работать в дополнительном сетевом пространстве имен.И это сетевое пространство имен по-прежнему, вероятно, должно взаимодействовать с Интернетом, используя исходное сетевое пространство имен: также необходимо планировать дополнительные настройки в различных местах.
