У меня получился следующий сценарий:
сервер Ubuntu 20.04 lts, для простоты названный сервером A со следующими сетевыми интерфейсами:
- петля
- enp1s0 (wan) PUBLIC-IP/23
- enp8s0 (локальная сеть) 10.9.96.3/20
- ppp0 (l2tp) 192.168.42.1
с этой таблицей маршрутизации (публичные маршруты намеренно опущены):
- 10.9.96.0/20 dev enp8s0 proto ядро область ссылка src 10.9.96.3
- 192.168.1.0/24 через 192.168.42.10 dev ppp0
- 192.168.42.10 dev ppp0 proto ядро область ссылка src 192.168.42.1
Есть удаленный vpn-клиент, подключенный к ip 192.168.42.10.
Этот клиент — маршрутизатор MikroTik, предоставляющий удаленную локальную сеть 192.168.1.0/24.
Используя статический маршрут, добавленный мной (192.168.1.0/24 через 192.168.42.10 dev ppp0), я могу связаться с устройствами 192.168.1.0/24.
еще один сервер Ubuntu 20.04 lts, для простоты названный B-сервером со следующими сетевыми интерфейсами:
- петля
- enp1s0 (wan) PUBLIC-IP/23
- enp8s0 (локальная сеть) 10.9.96.4/20
и эта таблица маршрутизации (публичные маршруты намеренно опущены):
- 10.9.96.0/20 dev enp8s0 proto ядро область ссылка src 10.9.96.4
По сути, мне нужно получить доступ к устройствам 192.168.1.0/24 с сервера B, но я не могу заставить это работать.
Я также пытался добавить статический маршрут: 192.168.1.0/24 через 10.9.96.3 dev enp8s0
на этом сервере, но безуспешно. Я вижу, что пакеты, предназначенные для 192.168.1.X, достигают сервера A, но затем они не перенаправляются на интерфейс ppp0, я полагаю (поэтому я также пробовал некоторые правила iptables).
Как решить эту проблему?
На обоих серверах брандмауэр отключен.
решение1
ПРИМЕЧАНИЕ: В этом ответе сеть 100.64.10.0/23представляет собой публичную сеть. Она не особенно важна, но существует только для того, чтобы сетевая конфигурация этих виртуальных узлов соответствовала тому, что вы описали в своем вопросе.
Ваша проблема в том, что хосты в сети 192.168.1.0/24 не знают, как подключиться к сети 10.9.96.0/20.
Исходя из того, что вы показали нам в своем вопросе, таблица маршрутизации на маршрутизаторе Microtik (192.168.42.10/192.168.1.1), вероятно, выглядит примерно так:
192.168.1.0/24 dev h1-eth0 proto kernel scope link src 192.168.1.1
192.168.42.0/24 dev h1-eth1 proto kernel scope link src 192.168.42.10
А таблица маршрутизации на сервере ServerA выглядит примерно так:
default via 100.64.10.1 dev serverA-eth0
10.9.96.0/20 dev serverA-eth1 proto kernel scope link src 10.9.96.3
100.64.10.0/23 dev serverA-eth0 proto kernel scope link src 100.64.10.10
192.168.1.0/24 via 192.168.42.10 dev serverA-eth2
192.168.42.0/24 dev serverA-eth2 proto kernel scope link src 192.168.42.1
На serverA, когда вы пингуете адрес в 192.168.1.0/24сети, ваш исходный адрес — 192.168.42.1. Маршрутизатор microtik имеет маршрут для этой сети, так что все отлично.
Если у serverBвас есть такая таблица маршрутизации:
default via 100.64.10.1 dev serverB-eth0
10.9.96.0/20 dev serverB-eth1 proto kernel scope link src 10.9.96.4
100.64.10.0/23 dev serverB-eth0 proto kernel scope link src 100.64.10.20
192.168.1.0/24 via 10.9.96.3 dev serverB-eth1
Затем, когда вы попытаетесь подключиться к адресу в 192.168.1.0/24сети, ваш исходный адрес будет 10.9.96.4. Маршрутизатор Microtik не знает, как достичь этого адреса (или пытается ответить через шлюз по умолчанию, что недопустимо).
Решение — добавить маршрут к маршрутизатору Microtik следующим образом:
ip route add 10.9.96.0/20 via 192.168.42.1
Сейчас:
- ServerB может пинговать маршрутизатор Microtik, поскольку маршрутизатор Microtik имеет допустимый маршрут обратно к serverB.
- ServerB может пинговатьдругойхостов в
192.168.1.0/24сети, поскольку эти хосты используют маршрутизатор Microtik (192.168.1.1) в качестве шлюза по умолчанию... и, как установлено в предыдущем пункте, маршрутизатор имеет соответствующий маршрут.
Я протестировал все это в смоделированной сетевой среде, созданной с использованиеммининет; вы можете найти конфигурациюздесьесли вам интересно.