Dwa interfejsy, dwa adresy, dwie bramy?

15

Mam system, który ma dwa interfejsy sieciowe z różnymi adresami IP, oba z zakresu adresów publicznych (choć przez NAT w przypadku pierwszego) i oba mają różne bramy. (Długa historia, do celów testowych)

Problem polega na tym, że teraz, gdy próbuję pingować adres na drugim interfejsie, domyślna trasa wskazuje przez pierwszy interfejs - i nigdy nie dociera prawidłowo.

Czy można upewnić się, że odpowiedzi zawsze wychodzą przez ten sam interfejs sieciowy (i przy użyciu tego samego źródłowego adresu IP), w jakim się pojawiły? A jeśli tak, to w jaki sposób?

debian networking ipv4

— Shadur
źródło

1

Być może jakiś wariant tego: unix.stackexchange.com/questions/4420/…

— Shawn J. Goff,

17

Nie rozumiesz problemu. Nie każdy pakiet jest odpowiedzią i nie każdy pakiet można dopasować do jakiegoś innego pakietu, tak że „taki sam interfejs sieciowy, w jakim się pojawił” ma sens. To, co chcesz zrobić, to wybrać bramę dla pakietu na podstawie jego źródłowego adresu IP.

Nazywa się to routingiem źródłowym lub routingiem zasad. Możesz to zrobić za pomocą prostej iptablesreguły , ale najlepszym sposobem jest skonfigurowanie dwóch tabel routingu, po jednej dla każdego publicznego adresu źródłowego:

Najpierw utwórz dwie tabele (Zastąp <NAME1> i <NAME2> rozsądnymi nazwami dla dwóch dostawców, tak samo jak IP1, DEV1 itd.):

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

Dodaj bramę do każdej tabeli routingu (w razie potrzeby):

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

Następnie domyślna trasa:

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

Następnie reguły wyboru tabeli tras na podstawie adresu źródłowego:

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

Aby uzyskać więcej informacji, zobacz Routing dla wielu łączy w górę / dostawców .

— David Schwartz
źródło

Napisałeś: „Nie każdy pakiet jest odpowiedzią i nie każdy pakiet można dopasować do jakiegoś innego pakietu, tak że„ taki sam interfejs sieciowy, w jakim się pojawił ”ma sens. „Czy możesz to wyjaśnić? Rozumiem, że nie każdy pakiet jest odpowiedzią i nie każdy pakiet można dopasować do innego pakietu „źródłowego”. Jeśli wykluczymy te pakiety z rozpatrzenia, ponieważ nie powodują one żadnych problemów, a zatem nas nie dotyczą, dlaczego pozostałych pakietów nie można skierować do „tego samego interfejsu sieciowego, w którym się pojawiły”?

— Andrew Savinykh

@AndrewSavinykh To nie rozwiązałoby wszystkich problemów. W szczególności ulegałby on awarii za każdym razem, gdy wychodzący pakiet pochodzący lokalnie (na przykład wychodzące żądanie ping) wychodził w złym interfejsie dla swojego źródłowego adresu IP i był upuszczany przez bramę. Problemem jest, jak wyjaśniłem, faktyczne upewnienie się, że pakiety wychodzą z bramy odpowiadającej ich źródłowemu adresowi IP.

— David Schwartz

David, chcę osiągnąć to samo co OP, ale nie jestem w stanie.

— Wysłałem

6

Odpowiedź Davida Schwartza jest doskonała, ale możesz nieco uprościć reguły routingu, mając tylko jedną dodatkową tabelę i używając domyślnej trasy dla drugiej. Mam serwer za dwiema bramami NAT, a ostatnio przeszedłem proces odtwarzania tego scenariusza między kilkoma maszynami wirtualnymi. Mój /etc/network/interfaceswygląda tak:

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

(dotyczy konfiguracji, w której dwoma dostawcami usług internetowych są Optus i iiNet, stąd nazwa tabeli „optus”)

To plus linia przy /etc/iproute2/rt_tablestworzeniu tabeli powinna być wszystkim, czego potrzebujesz. Będziesz miał dwa adresy IP; ruch z 192.168.13.13 będzie wychodził przez 192.168.13.11, a ruch z 192.168.13.213 będzie wychodził przez 192.168.13.10. Skonfiguruj te dwie bramy, aby odpowiednio przekierowywały swoje porty (192.168.13.11 przekazuje rzeczy do 192.168.13.13, a 192.168.13.10 przekazuje rzeczy do 192.168.13.213), a reszta powinna sama się zająć.

Być może będziesz musiał nieco poprawić ustawienia w swojej sytuacji, ponieważ bezpośrednio używasz publicznych adresów IP, ale coś takiego powinno nadal działać. Ponadto znacznie łatwiej jest wykonywać te czynności, /etc/network/interfacesa następnie zarządzać tym plikiem git, niż próbować pamiętać, jak go skonfigurowałeś, dwa lata później, kiedy system musi zostać zrestartowany!

— rosuav
źródło

1

Przykład podwójnej sieci

Ten przykład pokazuje, w jaki sposób dodatkowe eth1z 10.130.0.2maską sieci 255.255.255.255i bramą 10.130.0.1można udostępnić usługom, które się z nią wiążąping -I eth1 8.8.8.8

Technicznie jesteśmy:

Dodanie innej bramy o większej wartości
Dodawanie / używanie tabeli 100 i konfigurowanie jej
Dodanie reguły kierującej ruch do / z eth1 przez nią

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

— intika
źródło