Назад | Перейти на главную страницу

Принудительно направить локальный IP-трафик на внешний интерфейс

У меня есть машина с несколькими интерфейсами, которые я могу настроить как хочу, например:

Я хотел бы перенаправить весь трафик, отправленный на один из этих локальных адресов, через другой интерфейс. Например, все запросы к серверу iperf, ftp, http по адресу 192.168.1.1 должны не только маршрутизироваться внутри, но и перенаправляться через eth2 (а внешняя сеть позаботится о перенаправлении пакета на eth1).

Я попробовал и просмотрел несколько команд, например iptables, ip route и т. Д., Но ничего не помогло.

Самое близкое поведение, которое я мог получить, было сделано с:

ip route change to 192.168.1.1/24 dev eth2

которые отправляют все 192.168.1.x на eth2, за исключением 192.168.1.1, который по-прежнему маршрутизируется внутри. Могу ли я тогда выполнить NAT-переадресацию всего трафика, направленного на поддельный 192.168.1.2 на eth1, с внутренним перенаправлением на 192.168.1.1? Я действительно борюсь с iptables, но для меня это слишком сложно.

Цель этой настройки - провести тестирование драйвера интерфейса без использования двух компьютеров.

Я использую Linux, но если вы знаете, как это сделать с Windows, я куплю это!

Редактировать:

Внешняя сеть - это просто перекрестный кабель между eth1 и eth2. Допустим, у меня на машине есть http-сервер. Теперь я хочу получить доступ к этому серверу с той же машины, но я хочу, чтобы трафик TCP / IP проходил через этот кабель eth1 / eth2. Как мне настроить для этого свои интерфейсы?

Я успешно использовал следующее в Linux для проверки пропускной способности новой двухпортовой карты 10 Гбит / с в режиме «обратной связи», то есть, когда один порт подключен непосредственно к другому. Это всего лишь немного вуду, чтобы заставить пакеты выйти из сети, но если вы этого не сделаете, Linux просто закоротит трафик через ядро ​​(отсюда вопрос OP). В ответе Кейси выше я не уверен, действительно ли было необходимо иметь внешний маршрутизатор или не выше, но следующее полностью автономно. Два интерфейса - eth2 и eth3.

Дайте IP-адреса интерфейсам и поместите их в отдельные сети:

ifconfig eth2 10.50.0.1/24
ifconfig eth3 10.50.1.1/24

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

# nat source IP 10.50.0.1 -> 10.60.0.1 when going to 10.60.1.1
iptables -t nat -A POSTROUTING -s 10.50.0.1 -d 10.60.1.1 -j SNAT --to-source 10.60.0.1

# nat inbound 10.60.0.1 -> 10.50.0.1
iptables -t nat -A PREROUTING -d 10.60.0.1 -j DNAT --to-destination 10.50.0.1

# nat source IP 10.50.1.1 -> 10.60.1.1 when going to 10.60.0.1
iptables -t nat -A POSTROUTING -s 10.50.1.1 -d 10.60.0.1 -j SNAT --to-source 10.60.1.1

# nat inbound 10.60.1.1 -> 10.50.1.1
iptables -t nat -A PREROUTING -d 10.60.1.1 -j DNAT --to-destination 10.50.1.1

Теперь скажите системе, как попасть в каждую фальшивую сеть, и предварительно заполните записи arp (обязательно замените свои MAC-адреса, не используйте мои):

ip route add 10.60.1.1 dev eth2
arp -i eth2 -s 10.60.1.1 00:1B:21:C1:F6:0F # eth3's mac address

ip route add 10.60.0.1 dev eth3 
arp -i eth3 -s 10.60.0.1 00:1B:21:C1:F6:0E # eth2's mac address

Это достаточно обманывает Linux, чтобы фактически передавать пакеты по сети. Например:

ping 10.60.1.1

выходит из eth2, исходный IP-адрес 10.50.0.1 получает NAT-адрес в 10.60.0.1, а когда он входит в eth3, целевой 10.60.1.1 получает NAT-адрес в 10.50.1.1. И ответ проходит аналогичным образом.

Теперь используйте iperf для проверки пропускной способности. Привяжите к правильным IP-адресам и убедитесь, с каким IP вы связываетесь (поддельный адрес другого конца):

# server
./iperf -B 10.50.1.1 -s

# client: your destination is the other end's fake address
./iperf -B 10.50.0.1 -c 10.60.1.1 -t 60 -i 10

Убедитесь, что трафик действительно идет на провод:

tcpdump -nn -i eth2 -c 500

Вы также можете посмотреть / proc / interrupts, чтобы быть абсолютно уверенным, что карта используется:

while true ; do egrep 'eth2|eth3' /proc/interrupts ; sleep 1 ; done

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

Как всегда - я немного опоздал - но в настоящее время можно использовать сетевые пространства имен, чтобы изолировать интерфейсы и предотвратить любую локальную пересылку (и возиться с iptables :)).

Создайте пространства имен (все сделано с необходимыми разрешениями, например, как root):

ip netns add ns_server
ip netns add ns_client

Обратите внимание, что статус / конфигурация интерфейсов теперь должны быть доступны в контексте назначенного пространства имен, поэтому они не будут отображаться, если вы запустите голый IP ссылка поскольку это выполняется в контексте пространства имен по умолчанию. Выполнение команды в пространстве имен можно выполнить с помощью

ip netns exec <namespace-name> <command>

как префикс.

Теперь назначьте пространства имен интерфейсам, примените конфигурацию и настройте интерфейсы:

ip link set eth1 netns ns_server
ip netns exec ns_server ip addr add dev eth1 192.168.1.1/24
ip netns exec ns_server ip link set dev eth1 up
ip link set eth2 netns ns_client
ip netns exec ns_client ip addr add dev eth2 192.168.1.2/24
ip netns exec ns_client ip link set dev eth2 up

Теперь вы можете запускать приложения в пространстве имен - для запуска сервера iperf

ip netns exec ns_server iperf -s -B 192.168.1.1

и клиент:

ip netns exec ns_client iperf -c 192.168.1.1 -B 192.168.1.2

Теперь трафик будет отправляться через физические интерфейсы, поскольку весь сетевой стек, интерфейс, маршрутизация ... изолированы пространствами имен, поэтому ядро ​​не может сопоставить адреса, используемые в трафике, с локальными (доступными) интерфейсами.

Если вы закончили свои эксперименты, просто удалите пространства имен:

ip netns del <namespace-name>

Интерфейсы будут переназначены в пространство имен по умолчанию, и вся конфигурация, выполненная в пространстве имен, исчезнет (например, нет необходимости удалять назначенные IP-адреса).

Я расширил ответ каладоны, так как я не видел ответных пакетов. В этом примере:

  1. На моем локальном ПК у меня есть сетевые карты в разных подсетях, 192.168.1 / 24, 192.168.2 / 24
  2. Есть внешний маршрутизатор / ПК, у которого есть доступ к обеим подсетям.
  3. Я хочу отправлять двунаправленный трафик через сетевые адаптеры на локальном ПК.
  4. Конфигурация требует двух неиспользуемых IP-адресов для каждой подсети.

Маршруты iptable локального ПК настроены на SNAT и исходящий трафик DNAT на «поддельный» IP.

iptables -t nat -A POSTROUTING -d 192.168.1.100 -s 192.168.2.0/24 -j SNAT --to-source      192.168.2.100
iptables -t nat -A PREROUTING  -d 192.168.1.100 -i eth0           -j DNAT --to-destination 192.168.1.1
iptables -t nat -A POSTROUTING -d 192.168.2.100 -s 192.168.1.0/24 -j SNAT --to-source      192.168.1.100
iptables -t nat -A PREROUTING  -d 192.168.2.100 -i eth1           -j DNAT --to-destination 192.168.2.1

Правила делают следующее:

  1. Перепишите источник 192.168.2.1 на 192.168.2.100 в исходящих пакетах
  2. Перепишите адрес назначения 192.168.1.100 на 192.168.1.1 для входящих пакетов
  3. Перепишите источник 192.168.1.1 на 192.168.1.100 в исходящих пакетах
  4. Перепишите адрес назначения 192.168.2.100 на 192.168.2.1 для входящих пакетов

Подводя итог, теперь локальная система может взаимодействовать с «виртуальной» машиной с адресами 192.168.1.100 и 192.168.2.100.

Затем вам нужно заставить свой локальный компьютер использовать внешний маршрутизатор для доступа к вашему поддельному IP-адресу. Вы делаете это, создавая прямой маршрут к IP через маршрутизатор. Вы хотите убедиться, что вы принудительно отправляете пакеты в подсеть, противоположную целевой.

ip route 192.168.1.100 via $ROUTER_2_SUBNET_IP 
ip route 192.168.2.100 via $ROUTER_1_SUBNET_IP

Наконец, чтобы все это работало, внешний маршрутизатор должен знать, как получить поддельные IP-адреса на вашем локальном ПК. Вы можете сделать это, включив для вашей системы прокси-ARP.

echo 1 | sudo tee /proc/sys/net/ipv4/conf/all/proxy_arp
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward

С такой настройкой теперь вы можете рассматривать поддельные IP-адреса как настоящую систему на вашем локальном ПК. При отправке данных в подсеть .1 пакеты будут передаваться через интерфейс .2. При отправке данных в подсеть .2 пакеты будут передаваться через интерфейс .1.

ping 192.168.1.100
ping 192.168.2.100

Хорошо, наконец-то мне удалось настроить конфигурацию.

Идея состоит в том, чтобы использовать другой поддельный адрес, чтобы принудительно направить этот поддельный адрес к интерфейсу 2, а затем преобразовать поддельный адрес в реальный адрес 2 с помощью NAT / iptables.

Моя установка на самом деле состоит из одного маршрутизатора, который я могу установить между IF1 (интерфейс 1) и IF2.

В моей настройке FAKE_ADDR и IF1_ADDR находятся в одной подсети.

ifconfig $IF1 $IF1_ADDR netmask 255.255.255.0
ifconfig $IF2 $IF2_ADDR netmask 255.255.255.0

iptables -t nat -A PREROUTING -d $FAKE_ADDR -i $IF2 -j DNAT --to-destination $IF2_ADDR
iptables -t nat -A POSTROUTING -s $IF2_ADDR -d $IF1_ADDR/24 -j SNAT --to-source $FAKE_ADDR

route add $FAKE_ADDR gw $ROUTER_ADDR

А на роутере:

route add $FAKE_ADDR gw $IF2_ADDR

Если я отправляю что-то на FAKE_ADDR, pkt перенаправляется через IF1 на маршрутизатор, снова перенаправляется на IF2, тогда FAKE_IP заменяется IF2_ADDR. Пакет обрабатывается сервером, результат отправляется обратно в IF1_ADDR, из IF2_ADDR, который заменяется на FAKE_ADDR.

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

Ответ Томаса Тангейзера был точным!

У меня была аналогичная ситуация: одна машина с двумя интерфейсами enet. Я планировал использовать один интерфейс как сервер (получатель), а другой как клиент (отправитель). Каждый интерфейс будет подключен к маршрутизатору, и iperf будет пропускать трафик через маршрутизатор для измерения пропускной способности, PPS, задержки и т. Д.

К сожалению, подход iptables был не интуитивно понятным и чреват проблемами. После нескольких разочаровывающих часов я отказался от этого плана атаки. Вдохновленный предложением Томаса, я провел небольшую домашнюю работу по пространствам имен IP в Linux и начал ценить простоту и элегантность этого решения.

Ниже приведен список точных команд, которые я использовал для настройки Fedora FC26 для работы в этом качестве. Два интерфейса - enp1s0 и enp3s0. Маршрутизатор имеет два интерфейса с адресами 192.168.2.112 и 172.16.16.2. Каждый разъем FC26 ENET напрямую подключен к соответствующему интерфейсу маршрутизатора.

# How to configure the IP Namespaces
ip netns add iperf-server
ip netns add iperf-client
ip link set enp1s0 netns iperf-server
ip link set enp3s0 netns iperf-client
ip netns exec iperf-server ip addr add dev enp1s0 192.168.2.139/20
ip netns exec iperf-client ip addr add dev enp3s0 172.16.16.2/24
ip netns exec iperf-client ip link set dev enp3s0 up
ip netns exec iperf-server ip link set dev enp1s0 up
ip netns exec iperf-server route add default gw 192.168.2.112
ip netns exec iperf-client route add default gw 172.16.16.1

# Test the interfaces and network using ping
ip netns exec iperf-client ping -c1 172.16.16.1
ip netns exec iperf-server ping -c1 192.168.2.112
ip netns exec iperf-server ping -c1 172.16.16.2
ip netns exec iperf-client ping -c1 192.168.2.139

# Start Iperf Server for UDP test
ip netns exec iperf-server iperf -u -s
# Run Client against Iperf server for UDP test
ip netns exec iperf-client iperf -u -c 192.168.2.139

Похоже, вы хотите превратить свой Linux-бокс в блок типа маршрутизатор / мост / шлюз / брандмауэр. Следующие ресурсы могут быть тем, что вы ищете:

Проект Linux Router

Список дистрибутивов маршрутизатора или брандмауэра

Маршрутизатор Linux LiveCD

Linux Journal - Linux Router

Обновление основано на дополнительной информации:

Я не думаю, что вы сможете делать то, что хотите. ОС всегда будет смотреть на свою внутреннюю таблицу маршрутизации и «видеть» оба IP-адреса локально. Затем он будет маршрутизировать трафик в ОС и никогда не передавать его по сети. Вам понадобится вторая машина или две виртуальные машины (см. Xen).

Здесь нужно пройти много вещей, поэтому я не могу полностью гарантировать свою точность, но исходный вопрос, похоже, ищет то, что известно как техника "отправить себе". Связанный поиск показывает, что я считаю исправление ядра как верхняя ссылка + обсуждения и исправления с другими подходами в различных списках рассылки, особенно. LKML.

Я думаю, нужно еще посмотреть сетевые пространства имен, сделано с помощью iproute2 "ip netns". Это также требует некоторого дополнительного интерфейса и магии маршрутизации, поэтому может быть даже не менее сложным, чем массивная шумиха iptables в других ответах.

Комментарии определенно приветствуются, если кто-то нашел в них что-то полезное - как, что, где в вашей реализации.

Проверьте эту статью. Здесь подробно описаны шаги для включения доступа в Интернет к виртуальной машине виртуального бокса с использованием переадресации NAT.

http://jackal777.wordpress.com/2012/02/13/virtualbox-host-only-networking-nat-for-internet-access/

вот как я заработал для IPV6

назначенные статические IP-адреса

/sbin/ifconfig eth1 inet6 add 2001:db8::1/127 
/sbin/ifconfig eth3 inet6 add 2001:db8::2/127 

настроить маршруты хоста только на "ФАЛЬШИВЫЕ" адреса

ip -6 route add 2001:db8::2/128 dev eth1 metric 1
ip -6 route add 2001:db8::1/128 dev eth3 metric 1

заполнил таблицу соседей ... как arp

ip -6 neighbor add 2001:db8::1 lladdr 90:e2:ba:0d:75:e8 dev eth3 # eth1's mac address
ip -6 neighbor add 2001:db8::2 lladdr 90:e2:ba:0d:75:e9 dev eth1 # eth3's mac address

добавлены записи ip6tables

ip6tables -t nat -A POSTROUTING -s 2001:db8::1 -d 2013::2 -j SNAT --to-source 2001:db8::1
ip6tables -t nat -A PREROUTING -d 2001:db8::1 -j DNAT --to-destination 2001:db8::1
ip6tables -t nat -A POSTROUTING -s 2001:db8::2 -d 2013::1 -j SNAT --to-source 2001:db8::2
ip6tables -t nat -A PREROUTING -d 2001:db8::2 -j DNAT --to-destination 2001:db8::2