Вопросы Теги

Статические маршруты с несколькими подсетями

У меня проблема с построением статического маршрута, который охватывает 2 разные подсети и соединение VPN.Моя топология выглядит так:

  • Host-A: inet 10.0.28.45 netmask 255.255.224.0 broadcast 10.0.31.255

  • Host-B: inet 10.0.47.160 сетевая маска 255.255.240.0 широковещательная передача 10.0.47.255

  • Хост-C: inet 172.16.254.133 сетевая маска 255.255.255.0 широковещательная передача 172.16.254.255

У меня есть соединение OpenVPN, которое инициируется от узла C к узлу B. Соединение OpenVPN находится на tun0 с подсетью 192.168.100.0/24, поэтому Host-B имеет адрес tun0 192.168.100.2, а Host-C имеет адрес 192.168.100.5

Host-B имеет переадресацию IP и выполняю ip-masquerading на firewalld.

Я инициирую свое vpn-соединение и могу без проблем подключиться к Host-A с Host-C. Я хочу, чтобы Host-A также мог достигать Host-C. Насколько мне известно, чтобы добавить статический маршрут, вам нужен хост в той же подсети, что и ваш шлюз. Поскольку Host-A и Host-B находятся в разных подсетях, я добавил подсеть 10.0.32.0 в свою таблицу маршрутизации на Host-A.

Моя таблица маршрутизации на Host-A выглядит следующим образом: 

# ip route list
default via 10.0.0.1 dev eth0 
10.0.0.0/19 dev eth0 proto kernel scope link src 10.0.28.45
10.0.32.0/20 via 10.0.0.1 dev eth0 
169.254.0.0/16 dev eth0 scope link metric 1002

Затем я попытался добавьте маршрут к Host-B, который находится в подсети 10.0.32.0/20, как: 

ip route add 192.168.100.0/24 via 10.0.47.160

Но я получаю сообщение об ошибке: RTNETLINK отвечает: Сеть недоступна

Я понимаю, что шлюз, который я пытаюсь использовать здесь, находится вне область подсети, в которой находится Host-A. Я добавил подсеть 10.0.32.0/20 через 10.0.0.1 выше, чтобы указать маршрут, который должна принимать эта подсеть, внутри которой находится 10.0.47.160, но я не уверен, что это - правильный способ справиться с этим случаем.

Моя таблица маршрутизации на Host-B выглядит следующим образом: 

$ ip route list
default via 10.0.32.1 dev eth0 
10.0.32.0/20 dev eth0 proto kernel scope link src 10.0.47.160 
169.254.0.0/16 dev eth0 scope link metric 1002 
192.168.100.0/24 via 192.168.199.2 dev tun0 
192.168.100.2 dev tun0 proto kernel scope link src 192.168.199.1

Я хочу, чтобы весь трафик, кроме трафика, предназначенного для 192.168.100.0, продолжал выходить из eth0 через 10.0.0.1.

Мне кажется, что часть моей проблемы заключается в том, что мне что-то не хватает в моей таблице маршрутизации на хосте A, поэтому я получаю сообщение об ошибке «Сеть недоступна», когда пытаюсь добавить маршрут к 192.168.100.0/24.

Что мне здесь не хватает?

0
задан 26 June 2019 в 08:42
1 ответ

10.0.47.160 находится за пределами диапазона 10.0.0.0/19

Из калькулятора IP : 

Address:   10.0.0.0              00001010.00000000.000 00000.00000000
Netmask:   255.255.224.0 = 19    11111111.11111111.111 00000.00000000
Wildcard:  0.0.31.255            00000000.00000000.000 11111.11111111
=>
Network:   10.0.0.0/19           00001010.00000000.000 00000.00000000 (Class A)
Broadcast: 10.0.31.255           00001010.00000000.000 11111.11111111
HostMin:   10.0.0.1              00001010.00000000.000 00000.00000001
HostMax:   10.0.31.254           00001010.00000000.000 11111.11111110
Hosts/Net: 8190                  (Private Internet)

Итак 10.0.47.160> 10.0.31.254 и сеть недоступна.

Если вы сделаете свою сеть 10.0.0.0/19, которая будет конфликтовать с вашим маршрутом 10.0.32.0 (/ 32).

Я думаю, вы можете иметь в виду, что 10.0.32.0 через 10.0.0.1 на самом деле должно быть 10.0.32.0/19 через 10.0.0.1.

После обновления

Итак, ваш новый список маршрутов: 

# ip route list
default via 10.0.0.1 dev eth0 
10.0.0.0/19 dev eth0 proto kernel scope link src 10.0.28.45
10.0.32.0/20 via 10.0.0.1 dev eth0 
169.254.0.0/16 dev eth0 scope link metric 1002

И вы хотите добавить: 

ip route add 192.168.100.0/24 via 10.0.47.160

Ошибка, которую вы теперь получите будет другим: 

Error: Nexthop has invalid gateway.

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

Ваш единственный исходный IP-адрес (10.0.28.45) не находился бы в диапазоне шлюза 10.0.32.0/20, и если бы мы разрешили пакеты откуда угодно, мы могли бы потенциально получить всевозможные дыры и петли в нашем сеть.

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

По сути, вы просите маршрутизатор переназначить IP-адрес источника, но это не применимо, пока он не достигнет первого шлюза 10.0.0.1, и к тому времени он не знает пути возврата, поскольку пакеты не у меня нет «следа крошек».

Есть много способов решить эту проблему, но это зависит от сети, которую вы хотите. Я бы посмотрел на туннели (tap и tun), GRE или виртуальные коммутаторы, которые выполняют такие виды переназначения IP-адресов и отслеживают внешние соединения, как если бы они были локальными. Они создают виртуальные интерфейсы в том же диапазоне, что и пункт назначения, и именно так на самом деле работают VPN.

К счастью, эти решения стали намного проще, чем раньше!

1
ответ дан 4 December 2019 в 15:40

Теги

Похожие вопросы