Примусовий локальний IP-трафік до зовнішнього інтерфейсу

У мене є машина з декількома інтерфейсами, які я можу налаштувати так, як хочу:

• eth1: 192.168.1.1
• eth2: 192.168.2.2

Я хотів би переслати увесь трафік, надісланий на одну з цих локальних адрес через інший інтерфейс. Наприклад, усі запити на 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. Як мені налаштувати для цього свої інтерфейси?

Я розширив відповідь від каладони, оскільки не міг побачити пакети відповідей. Для цього прикладу:

1. На моєму локальному ПК я маю NIC в різних підмережах, 192.168.1 / 24 , 192.168.2 / 24
   
2. Є зовнішній маршрутизатор / ПК, який має доступ до обох підмереж.
3. Я хочу надсилати двосторонній трафік через NIC на локальний ПК.
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-адрес на вашому локальному ПК. Ви можете зробити тонше, увімкнувши проксі-сервери проксі для вашої системи.

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

Я успішно використовував наступне в Linux для тестування пропускної здатності на новій картці 10Gbps з двома портами в режимі "петля", тобто один порт підключений безпосередньо до іншого. Це все лише трохи вуду для того, щоб вимусити пакети з дроту, але якщо цього не зробити, Linux просто замикає трафік через ядро ​​(звідси питання ОП). У відповіді Кейсі вище, я не впевнений, чи дійсно потрібно було мати зовнішній маршрутизатор чи не вище, але наступне повністю автономне. Два інтерфейси - 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 отримує NATUT до 10.60.0.1, а коли він надходить у eth3, призначення 10.60.1.1 отримує NATUT до 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 / переривати, щоб бути абсолютно впевненим, що карта використовується:

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-адреси).

Гаразд, мені нарешті вдалося налаштувати конфігурацію.

Ідея полягає у використанні іншої підробленої адреси, змусити маршрут цієї підробленої адреси до інтерфейсу 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 був неінтуїтивним і загрожує проблемами. Через кілька розчаруючих годин я відмовився від цього плану нападу. Надихнувшись пропозицією Томаса, я зробив невелике домашнє завдання з Linux IP Namespaces і почав цінувати простоту та елегантність цього рішення.

Нижче наведено перелік точних команд, які я використовував для налаштування свого 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

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

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

Журнал Linux - Маршрутизатор Linux

Оновлення на основі додаткової інформації:

Я не думаю, що ти зможеш робити те, що ти хочеш. ОС завжди буде дивитися на свою внутрішню таблицю маршрутизації та "бачити" обидва IP-адреси локально. Тоді він буде направляти трафік в ОС і ніколи не ставити його на провід. Вам знадобиться друга машина або дві віртуальні машини (перевірити Xen ).

Тут можна пройти багато речей, тому я не можу повністю гарантувати свою точність, але, мабуть, оригінальне питання шукає те, що відомо як техніка "відправити до себе" . Пов'язаний пошук показує, що, на мою думку, найкраще підтримується виправлення ядра як верхня посилання + дискусії та виправлення з іншими підходами в різних списках розсилки, особливо LKML.

Я думаю, що слід також переглянути простори мережних імен , зроблені з "ip netns" iproute2 . Це також потребує додаткового інтерфейсу та магії маршрутизації, тому може бути не менш складним, ніж масивний iptables hoopla в інших відповідях.

Коментарі безумовно вітаються, якщо хтось знайшов щось корисне з цим - як, що, де щодо вашої реалізації.

Перевірте цю статтю. Тут згадуються детальні кроки для надання доступу до Інтернету до virtualbox vm за допомогою NAT переадресації.

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

ось, як у мене це працює для IPV6

призначені статичні ips

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

налаштувати маршрути лише для хостів до адрес "FAKE"

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

заселили сусідський стіл ... як арп

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