Два інтерфейси, дві адреси, два шлюзи?

15

У мене є система, яка має два мережевих інтерфейси з різними адресами IP, обидва вони знаходяться в діапазоні загальнодоступних адрес (хоча і через NAT у випадку першого), і обидві мають різні шлюзи. (Довга історія, це для тестування)

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

Чи можна переконатися, що відповіді завжди надходять через той самий мережевий інтерфейс (і з тим самим IP-джерелом), як і у випадку, коли вони надходили? А якщо так, то як?

debian networking ipv4

— Шадур
джерело

1

Можливо, якийсь варіант щодо цього: unix.stackexchange.com/questions/4420/…

— Шон Дж. Гофф

17

Ви нерозумієте проблему. Не кожен пакет є відповіддю, і не кожен пакет може бути узгоджений з яким-небудь іншим пакетом, так що "той же мережевий інтерфейс, як вони увійшли" має сенс. Що ви хочете зробити, це вибрати шлюз для пакета на основі його вихідної IP-адреси.

Це називається маршрутизацією на основі джерела або маршрутизацією політики. Це можна зробити за допомогою простого iptablesправила , але найкращим способом є встановлення двох таблиць маршрутизації, по одній для кожної публічної адреси джерела:

Спочатку створіть дві таблиці (Замініть <NAME1> і <NAME2> на розумні імена для своїх двох провайдерів, однаково з IP1, DEV1 тощо):

echo 200 <NAME1> >> /etc/iproute2/rt_tables
echo 201 <NAME2> >> /etc/iproute2/rt_tables

Додайте шлюз до кожної таблиці маршрутів (якщо потрібно):

ip route add <NET1> dev <DEV1> src <SRC1> table <NAME1>
ip route add <NET2> dev <DEV2> src <SRC2> table <NAME2>

Тоді маршрут за замовчуванням:

ip route add default via <IP1> table <NAME1>
ip route add default via <IP2> table <NAME2>

Потім правила вибору таблиці маршруту на основі адреси джерела:

ip rule add from <IP1> table <NAME1>
ip rule add from <IP2> table <NAME2>

Детальнішу інформацію див. У розділі Проведення маршрутів для декількох посилань / постачальників .

— Девід Шварц
джерело

Ви писали: "Не кожен пакет є відповіддю, і не кожен пакет може бути узгоджений з яким-небудь іншим пакетом, таким чином, що" той же мережевий інтерфейс, який вони увійшли "має сенс. - Чи можете ви пояснити це далі? Я розумію, що не кожен пакет є відповіддю, і не кожен пакет може бути узгоджений з іншим "вихідним" пакетом. Якщо ми виключаємо ці пакети з розгляду, оскільки вони не викликають жодних проблем і, отже, не стосуються нас, чому залишилися пакети не можуть бути маршрутизовані до "того самого мережевого інтерфейсу, як вони увійшли"?

— Андрій Савіних

@AndrewSavinykh Це не вирішило б усі проблеми. Зокрема, він буде ламатися, коли вихідний пакет, що виникає локально (наприклад, вихідний запит ping), вийшов невірним інтерфейсом для його вихідної IP-адреси та був скинутий шлюзом. Як я пояснив, проблема полягає в тому, щоб переконатися, що пакети виходять з шлюзу, відповідного IP-адресі їх джерела.

— Девід Шварц

Девіде, я хочу досягти того ж, що і ОП, але цього не можу. Я опублікував тут питання: serverfault.com/questions/992624/… , було б чудово, якщо ви могли поглянути

— Housemd

6

Відповідь Девіда Шварца є відмінною, але ви можете трохи спростити правила маршрутизації, маючи лише одну додаткову таблицю та використовуючи маршрут за замовчуванням для іншого. У мене є сервер, який знаходиться за двома NAT-шлюзами, і я нещодавно пройшов процес відтворення цього сценарію між купою VM. Моє /etc/network/interfacesвиглядає так:

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.13.13
    netmask 255.255.255.0
    up ip route add table optus default via 192.168.13.10
    up ip rule add from 192.168.13.213 table optus
    up ip route add default via 192.168.13.11

auto eth0:0
iface eth0:0 inet static
    address 192.168.13.213
    netmask 255.255.255.0

(це для налаштувань, де два провайдери є Optus і iiNet, звідси назва таблиці "optus")

Це, плюс рядок у /etc/iproute2/rt_tablesстворенні таблиці, має бути всім необхідним. У вас буде дві IP-адреси; трафік з 192.168.13.13 вийде через 192.168.13.11, а трафік з 192.168.13.213 вийде через 192.168.13.10. Налаштуйте ці два шлюзи для належного виконання переадресації портів (192.168.13.11 пересилає інформацію до 192.168.13.13, а 192.168.13.10 пересилає дані до 192.168.13.213), а решта повинна подбати про себе.

Можливо, вам доведеться трохи налаштувати речі для вашої ситуації, оскільки ви використовуєте загальнодоступні IP-адреси безпосередньо, але щось подібне все одно має працювати. Крім того, набагато простіше робити ці речі в, /etc/network/interfacesа потім керувати цим файлом, а не намагатися пригадати, як ви його встановили, через два роки, коли система має бути перезавантажена!

— rosuav
джерело

1

Приклад подвійної мережі

Цей приклад показує, як додаткові функції eth1з 10.130.0.2мережевою маскою 255.255.255.255та шлюзом 10.130.0.1можуть бути доступні для служб, що пов'язують їїping -I eth1 8.8.8.8

Технічно ми:

Додавання іншого шлюзу з більшою метрикою
Додавання / використання таблиці 100 та налаштування її
Додавання правила для маршрутизації трафіку до / з eth1 через нього

ip addr add 10.130.0.2/32 broadcast 10.130.0.2 dev eth1
ip link set eth1 up
ip route add 10.130.0.1 src 10.130.0.2 dev eth1
ip route add 10.130.0.1 src 10.130.0.2 dev eth1 table 100
ip route add default via 10.130.0.1 dev eth1 metric 10
ip route add default via 10.130.0.1 dev eth1 table 100
ip rule add from 10.130.0.2/32 table 100
ip rule add to 10.130.0.2/32 table 100
curl --interface eth1 ifconfig.co
curl --interface eth0 ifconfig.co
ping -I eth1 8.8.8.8

— інтик
джерело