LINUX.ORG.RU
решено ФорумAdmin

(Не)полная связность на L4

 , ,


0

1

Вводные:
есть две сети 1.1.1.0/24 и 2.2.2.0/24
Между ними файрвол, который является шлюзом
Условно примерно так:
1.1.1.0/24-----[(1.1.1.254)FW(2.2.2.254)]-----2.2.2.0/24

Хосты из 1.1.1.0/24 пингуют хосты в 2.2.2.0/24
Хосты из 2.2.2.0/24 пингуют хосты в 1.1.1.0/24
Хосты из 1.1.1.0/24 могут ходить на любые порты в 2.2.2.0/24
Хосты из 2.2.2.0/24 не могут ходить на любые порты в 1.1.1.0/24, потому что люди, отвечающие за связность, из-за недопонимания настроили ACL только в одну сторону. В другую сторону тоже скоро настроят, но связность нужна ещё вчера.
Доступ есть ко всем хостам, доустановка сторонних пакетов затруднена, хотелось бы обойтись максимально стандартными способами.

Задача: как обеспечить связность в обратную сторону(это времянка на день-два, поэтому любые костыли подойдут).

Пока пытаюсь сделать это через SSH туннель.
Идея примерно такая:
1. Выбираем пару произвольных хостов, вешаем на них по новому адресу, чисто под туннель, делаем туннель
1.1.1.123<--->2.2.2.234
На этом шаге хост 2.2.2.234 может подключиться к 1.1.1.123 на любые порты.
2. Хост 1.1.1.123 будет выступать маршрутизатором для остальных хостов в 1.1.1.0/24, поэтому на нём делаем маршрут 2.2.2.0/24 via 1.1.1.123
Хост 2.2.2.234 будет выступать маршрутизатором для остальных хостов в 2.2.2.0/24, поэтому на нём делаем маршрут 1.1.1.0/24 via 2.2.2.234
3.На хостах сети 1.1.1.0/24 делаем маршрут 2.2.2.0/24 via 1.1.1.123
На хостах сети 2.2.2.0/24 делаем маршрут 1.1.1.0/24 via 2.2.2.234

Ожидаемый результат: всё сходу работает через туннель
Актуальный результат: на втором шаге туннель ломается.

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

Вопрос: есть ли способ это разрулить? Ну или можно решить это принципиально иначе?

Ping mky, vel, AS, router, anc


Решение:
NETWORK1 - первая сеть, из которой открыты все порты во вторую сеть
REAL_IP_IN_NETWORK1 - изначальный адрес хоста в первой сети
NETWORK1_GATEWAY - дефолтный шлюз на хосте в первой сети
EXT_TUNNEL_IP_IN_NETWORK1 - внешний адрес туннеля на хосте в первой сети
INT_TUNNEL_IP_IN_NETWORK1 - внутренний адрес туннеля на хосте в первой сети

NETWORK2 - вторая сеть, из которой закрыты все порты в первую сеть
REAL_IP_IN_NETWORK2 - изначальный адрес хоста во второй сети
NETWORK2_GATEWAY - дефолтный шлюз на хосте в первой сети
EXT_TUNNEL_IP_IN_NETWORK2 - внешний адрес туннеля на хосте во второй сети
INT_TUNNEL_IP_IN_NETWORK2 - внутренний адрес туннеля на хосте во второй сети

Важное примечание: если убрать вторые адреса и прописывать маршруты между REAL_IP_IN_NETWORK1 и REAL_IP_IN_NETWORK2, то тот хост из второй сети не сможет взаимодействовать с этим (REAL_IP_IN_NETWORK1) хостом из первой сети, так как весь траффик между ними пойдет не по тунелю, а порты перекрыты.

1. На хосте REAL_IP_IN_NETWORK1 вешаем доп. адрес EXT_TUNNEL_IP_IN_NETWORK1 в сети NETWORK1 чтобы туннель строился именно с него:

ip a a EXT_TUNNEL_IP_IN_NETWORK1/32 dev eth0
ip r a EXT_TUNNEL_IP_IN_NETWORK2/32 via NETWORK1_GATEWAY dev eth0 src EXT_TUNNEL_IP_IN_NETWORK1

2. На хосте REAL_IP_IN_NETWORK2 вешаем доп. адрес EXT_TUNNEL_IP_IN_NETWORK2 в сети NETWORK2 чтобы туннель строился именно на него:
ip a a EXT_TUNNEL_IP_IN_NETWORK2/32 dev eth0
ip r a EXT_TUNNEL_IP_IN_NETWORK1/32 via NETWORK2_GATEWAY dev eth0 src EXT_TUNNEL_IP_IN_NETWORK2

3. Поднимаем туннель c REAL_IP_IN_NETWORK1, чтобы в дальнейшем завернуть в него пакеты на заблокированные порты. После установления соединения на обоих хостах появляются интерфейсы tun0
ssh -b EXT_TUNNEL_IP_IN_NETWORK1 -w 0:0 EXT_TUNNEL_IP_IN_NETWORK2

4. На хосте REAL_IP_IN_NETWORK1 вешаем внутренний туннельный адрес INT_TUNNEL_IP_IN_NETWORK1 на tun0:
ip a a INT_TUNNEL_IP_IN_NETWORK1/32 peer INT_TUNNEL_IP_IN_NETWORK2 dev tun0
ip link set dev tun0 up

5. На хосте REAL_IP_IN_NETWORK2 вешаем внутренний туннельный адрес INT_TUNNEL_IP_IN_NETWORK2 на tun0:
ip a a INT_TUNNEL_IP_IN_NETWORK2/32 peer INT_TUNNEL_IP_IN_NETWORK1 dev tun0
ip link set dev tun0 up

6. На хосте REAL_IP_IN_NETWORK2 прописываем маршрут в NETWORK1 через INT_TUNNEL_IP_IN_NETWORK2:
ip r a NETWORK1 via INT_TUNNEL_IP_IN_NETWORK1 dev tun0 src REAL_IP_IN_NETWORK2

7. На хосте REAL_IP_IN_NETWORK1 прописываем маршрут в NETWORK2 через INT_TUNNEL_IP_IN_NETWORK1:
ip r a NETWORK2 via INT_TUNNEL_IP_IN_NETWORK2 dev tun0 src REAL_IP_IN_NETWORK1

8. На хостах в NETWORK2 прописываем маршрут в NETWORK1 через REAL_IP_IN_NETWORK2
ip r a NETWORK1 via REAL_IP_IN_NETWORK2

9. На хостах в NETWORK1 прописываем маршрут в NETWORK2 через REAL_IP_IN_NETWORK1
ip r a NETWORK2 via REAL_IP_IN_NETWORK1

★★★★★

Вопросов больше чем ответов.
1.

пытаюсь сделать это через SSH туннель

Покажите как именно.
2.

Хост 1.1.1.123... поэтому на нём делаем маршрут 2.2.2.0/24 via 1.1.1.123

Завернули сами на себя и удивляетесь что не работает. Что бы было понятно, с таким же успехом можно и 8.8.8.8 завернуть к себе ip r a 8.8.8.8/32 via 1.1.1.123 и удивляться почему он не отвечает.

Пока всё.

anc ★★★★★ ()
Ответ на: комментарий от anc

Покажите как именно

С сети 1.1.1.0/24:
1. ssh -w 0:0 хост_в_2.2.2.0
2. После этого появляются tun0 интерфейсы. Вешаем на них адреса и переводим в Up


Завернули сами на себя и удивляетесь

Нууу, да, в виду специфичности сценария надо как-то самого себя за волосы вытащить

zolden ★★★★★ ()
Последнее исправление: zolden (всего исправлений: 1)
Ответ на: комментарий от zolden

2. После этого появляются tun0 интерфейсы. Вешаем на них адреса и переводим в Up

Ну вот. via через что должно быть? :) Через тот который «Вешаем на них адреса» ну не через самого же себя.
На всякий случай что бы вы ещё не напутали, пункт 3 по описанию верный. Сейчас говорим только про пункт 2 в котором ошибка.

anc ★★★★★ ()

почему бы не попробовать поднять туннель ipip или ipgre ?

Если в каждой подсети есть машинка с линуксом, то это не должно быть проблемой.

vel ★★★★★ ()
Ответ на: комментарий от anc

На примере поддиванного. С обеих сторон у меня tun15 параметр -w в команде ssh -w 15:15
Клиент:

11: tun15: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.12.0.2 peer 10.12.0.1/30 scope global tun15
       valid_lft forever preferred_lft forever

Сервер
12: tun15: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/[65534]
    inet 10.12.0.1 peer 10.12.0.2/30 scope global tun15

У меня схема сложнее, и мне нужен pbr с defgw через сервер
Но роли особой не играет у вас всё проще.
Клиент
ip r s table 101 # Это как раз отдельная таблица для pbr
default via 10.12.0.1 dev tun15

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

Ну вопросов вообще много возникает.

А будет ли вообще ходить ipip/gre?

Если он ходит, то один раз поднять и ping-ом его поддерживать. Ведь это же временная мера.

Если будет работать, то выдать всем в каждой подсети доп. маршрут.

vel ★★★★★ ()
Ответ на: комментарий от vel

Ну фактически мы приходим к пункту 2 ТС. Не настроишь тунель с роутингом «не будет не коня ни шашки». Виды туннелей на вкус и цвет. Я вас правильно понял?

anc ★★★★★ ()
Ответ на: комментарий от anc

Большое спасибо вам с vel за содействие, я предполагаю, мы пришли к общему знаменателю, что на данном этапе неважно какого типа туннель, при необходимости я могу попробовать поменять SSH на ipip/gre

Вот адреса:
Хост1-Сеть1.1.1/24

eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:15:01:1c brd ff:ff:ff:ff:ff:ff
    inet 1.1.1.143/24 brd 1.1.1.255 scope global eth0
       valid_lft forever preferred_lft forever
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 1.1.1.123 peer 2.2.2.234/32 scope global tun0
       valid_lft forever preferred_lft forever
# ip r g 2.2.2.234
2.2.2.234 dev tun0  src 1.1.1.123

# ip r g 2.2.2.0/24                                                                                                                  
2.2.2.0 via 1.1.1.254 dev eth0  src 1.1.1.143


Хост2-Сеть2.2.2/24
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:15:1a:d0 brd ff:ff:ff:ff:ff:ff
    inet 2.2.2.22/24 brd 2.2.2.255 scope global eth0
       valid_lft forever preferred_lft forever
tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 2.2.2.234 peer 1.1.1.123/32 scope global tun0
       valid_lft forever preferred_lft forever
# ip r g 1.1.1.123
1.1.1.123 dev tun0  src 2.2.2.234

# ip r g 1.1.1.0/24
1.1.1.0 via 2.2.2.254 dev eth0  src 2.2.2.22

zolden ★★★★★ ()
Последнее исправление: zolden (всего исправлений: 1)

Что-то так много сообщений в треде, лень вчитываться.

на втором шаге туннель ломается.

Либо вы как-то отдельно выделяете транспортные пакеты тунеля и маршрутизируете их отдельно (маркировка в iptables + ip rule).

Либо выделяете для этих «шлюзов» отдельные (дополнительные) ip-адреса в этих сетях, (если там достаточно адресного пространства) и прописываете /32 маршрут через FW. То есть на 1.1.1.23/24 добавляете адрес 1.1.1.123/32 и делаете команду:

ip route add 2.2.2.234/32 via 1.1.1.254
и аналогично на 2.2.2.34/24 добаляете 2.2.2.2.234/32 и маршрут к 1.1.1.123/32. При этом эти компы не должны взаимодействовать с дополнительных адресов, 2.2.2.234 не должен пытаться достучаться до портов 1.1.1.123, только до 1.1.1.23. Ну и ssh-тунель должен устанавливать 1.1.1.23 с адреса 1.1.1.123 (опция ″-b″, надеюсь она работает вместе с ″-w″).

И эти адреса нужно добавлять на eth0, на tun вешать адреса из другой сети, чтобы не было путаницы.

mky ★★★★★ ()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от zolden

Выделите отдельную сеть для туннеля. В вашем случае не имеет смысла использовать адресацию существующих сетей. 1.1.1.0 и 2.2.2.0. Как приведенный мной реальный пример можно взять туже 10.12. если она нигде больше не задействована.

anc ★★★★★ ()
Ответ на: комментарий от mky

Либо выделяете для этих «шлюзов» отдельные (дополнительные) ip-адреса в этих сетях, (если там достаточно адресного пространства) и прописываете /32 маршрут через FW.

Я кстати пытался уже так(если я правильно уловил идею) сделать. Но такой маршрут у меня прописать не получилось, как я понимаю, туннельные адреса считаются directly connected и их нельзя через другой шлюз зарулить

zolden ★★★★★ ()
Ответ на: комментарий от anc

Как приведенный мной реальный пример можно взять туже 10.12

Имеется в виду, взять другую сеть именно для туннельных пиров(т.е. в неё не будет маршрута через фаервол, до которого у меня нет доступа)?

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Должно быть примерно так:

tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.1.1.123 peer 10.2.2.234/32 scope global tun0
       valid_lft forever preferred_lft forever
То, что вы на tun0 назначаете 1.1.1.123 неправильно и работает пока arp_filter=0, что не гарантируется в случайно взятом дистрибутиве. Так как про arp_filter мало кто знает, я просто оставлю это здесь, чтобы потом кто-нибудь другой, делающий подобное и нагуливший эту тему, знал про эти грабли.

mky ★★★★★ ()
Ответ на: комментарий от zolden

В текущем же

1.1.1.123 peer 2.2.2.234/32

А, ещё маршрут через tun прописывать с src, чтобы с самого хоста сокеты без bind() шли с нужного адреса:

ip route add 2.2.2.0/24 via 10.2.2.234 dev tun0 src 1.1.1.143

mky ★★★★★ ()
Последнее исправление: mky (всего исправлений: 1)
Ответ на: комментарий от mky

Сорян, исправил прошлый комментарий после того как перечитал ответ, получился рамсинхрон.
Как по феншую прописать маршруты на остальных хостах? Через эти новые туннельные адреса?

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Маршруты на остальных хостах через адреса из их сетей: 1.1.1.123 (или 1.1.1.143) для первой сети. И форвардинг не забыть включить на 1.1.1.123 (и прохождение пакетов в iptables FORWARD, а то там DROP бывает по-умолчанию).

mky ★★★★★ ()
Ответ на: комментарий от mky

Что-то не взлетело сходу, опять коннект потерялся

Текущее понимание схемы:
1. Выбираем пару произвольных хостов(по одному с каждой сети): 1.1.1.143 и 2.2.2.22
2. Посредством ssh -w делаем туннель между 1.1.1.143 и 2.2.2.22
3. После подключения появляюся tun0 интерфейсы, вешаем на них адреса из новой подсети:
1.1.1.143:

ip a a 100.64.1.143/32 peer 100.64.1.22 dev tun0

2.2.2.22
ip a a 100.64.1.22/32 peer 100.64.1.143 dev tun0

т.о, внутренние адреса туннеля получаются:
100.64.1.143<--->100.64.1.22

На этом шаге хост 100.64.1.22 может подключиться к 100.64.1.143 на любые порты.
4. Хост 1.1.1.143 будет выступать маршрутизатором для остальных хостов в 1.1.1.0/24, поэтому на нём делаем маршрут
ip r a 2.2.2/24 via 100.64.1.22 dev tun0 src 1.1.1.143

5. Хост 2.2.2.22 будет выступать маршрутизатором для остальных хостов в 2.2.2.0/24, поэтому на нём делаем маршрут
ip r a 1.1.1/24 via 100.64.1.143 dev tun0 src 2.2.2.22

6. На остальных хостах сети 1.1.1.0/24 делаем маршрут
ip r a 2.2.2/24 via 1.1.1.143

7. На остальных хостах сети 2.2.2.0/24 делаем маршрут
ip r a 1.1.1/24 via 2.2.2.22


На шагах 4-5 связность между пирами туннеля теряется

zolden ★★★★★ ()
Ответ на: комментарий от zolden

Перед шагом 4 делаем на хосте 1.1.1.143 :

ip route add 2.2.2.22 via 1.1.1.254 dev eth0 src 1.1.1.143

и «зеркально» на 2.2.2.22. С хоста 2.2.2.2 доступа до портов 1.1.1.143 не будет. Лучше выделить отдельные адреса.
На хосте 1.1.1.143:

ip addr add 1.1.1.123/32 dev eth0
ip route add 2.2.2.234/32 via 1.1.1.254 dev eth0 src 1.1.1.123
ssh -w ... 2.2.2.234
ip addr add 100.64.1.123/32 peer 100.64.1.234 dev tun0
ip route add 2.2.2.0/24 via 100.64.1.234 dev tun0 src 1.1.1.143
На хосте 2.2.2.22:
ip addr add 2.2.2.234/32 dev eth0
ip route add 1.1.1.143/32 via 2.2.2.254 dev eth0 src 2.2.2.234
ip addr add 100.64.2.234/32 peer 100.64.1.123 dev tun0
ip route add 1.1.1.0/24 via 100.64.1.123 dev tun0 src 2.2.2.22
Сначала на обоих хостах выполнить команды касательно eth0, потом поднять тунель, потом касательно tun0, потом прописывать маршруты на хостах сети.

mky ★★★★★ ()
Ответ на: комментарий от zolden

У меня ошибка. На хосте из сети 2 вместо:

ip route add 1.1.1.143/32 via 2.2.2.254 dev eth0 src 2.2.2.234
ip addr add 100.64.2.234/32 peer 100.64.1.123 dev tun0

нужно:

ip route add 1.1.1.123/32 via 2.2.2.254 dev eth0 src 2.2.2.234
ip addr add 100.64.1.234/32 peer 100.64.1.123 dev tun0

После установления тунеля посмотрите в выводе ″netstat″ или ″ss″, что соединение установлено с адреса 1.1.1.123.

mky ★★★★★ ()
Ответ на: комментарий от mky

Ээ. А что за адрес 100.64.1.234?
Количество адресов и сложность схемы растут на глазах, поэтому попробую задокументировать идею с использованием переменных. Посмотри, пожалуйста, всё ли правильно я понял

NETWORK1 - первая сеть, из которой открыты все порты во вторую сеть
REAL_IP_IN_NETWORK1 - изначальный адрес хоста в первой сети
NETWORK1_GATEWAY - дефолтный шлюз на хосте в первой сети
EXT_TUNNEL_IP_IN_NETWORK1 - внешний адрес туннеля на хосте в первой сети
INT_TUNNEL_IP_IN_NETWORK1 - внутренний адрес туннеля на хосте в первой сети

NETWORK2 - вторая сеть, из которой закрыты все порты в первую сеть
REAL_IP_IN_NETWORK2 - изначальный адрес хоста во второй сети(из которой закрыты все порты в первую сеть)
NETWORK2_GATEWAY - дефолтный шлюз на хосте в первой сети
EXT_TUNNEL_IP_IN_NETWORK2 - внешний адрес туннеля на хосте во второй сети
INT_TUNNEL_IP_IN_NETWORK2 - внутренний адрес туннеля на хосте во второй сети


1. На хосте REAL_IP_IN_NETWORK1 вешаем доп. адрес EXT_TUNNEL_IP_IN_NETWORK1 в сети NETWORK1 чтобы туннель строился именно с него:

ip a a EXT_TUNNEL_IP_IN_NETWORK1/32 dev eth0
ip r a EXT_TUNNEL_IP_IN_NETWORK2/32 via NETWORK1_GATEWAY dev eth0 src EXT_TUNNEL_IP_IN_NETWORK1

2. На хосте REAL_IP_IN_NETWORK2 вешаем доп. адрес EXT_TUNNEL_IP_IN_NETWORK2 в сети NETWORK2 чтобы туннель строился именно на него:
ip a a EXT_TUNNEL_IP_IN_NETWORK2/32 dev eth0
ip r a REAL_IP_IN_NETWORK1/32 via NETWORK2_GATEWAY dev eth0 src EXT_TUNNEL_IP_IN_NETWORK2

3. Поднимаем туннель c REAL_IP_IN_NETWORK1, чтобы в дальнейшем завернуть в него пакеты на заблокированные порты. После установления соединения на обоих хостах появляются интерфейсы tun0
ssh -b EXT_TUNNEL_IP_IN_NETWORK1 -w 0:0 EXT_TUNNEL_IP_IN_NETWORK2

4. На хосте REAL_IP_IN_NETWORK1 вешаем внутренний туннельный адрес INT_TUNNEL_IP_IN_NETWORK1 на tun0 и прописываем через него маршрут в NETWORK2:
ip a a INT_TUNNEL_IP_IN_NETWORK1/32 peer INT_TUNNEL_IP_IN_NETWORK2 dev tun0
ip r a NETWORK2/24 via INT_TUNNEL_IP_IN_NETWORK2 dev tun0 src REAL_IP_IN_NETWORK1

5. На хосте REAL_IP_IN_NETWORK2 вешаем внутренний туннельный адрес INT_TUNNEL_IP_IN_NETWORK2 на tun0 и прописываем через него маршрут в NETWORK1:
ip a a INT_TUNNEL_IP_IN_NETWORK2/32 peer INT_TUNNEL_IP_IN_NETWORK1 dev tun0
ip r a NETWORK1/24 via INT_TUNNEL_IP_IN_NETWORK1 dev tun0 src REAL_IP_IN_NETWORK2

6. На хостах в NETWORK1 прописываем маршрут в NETWORK2 через REAL_IP_IN_NETWORK1
ip r a NETWORK2/24 via REAL_IP_IN_NETWORK1

7. На хостах в NETWORK2 прописываем маршрут в NETWORK1 через REAL_IP_IN_NETWORK2
ip r a NETWORK1/24 via REAL_IP_IN_NETWORK2

zolden ★★★★★ ()

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

Ну так и сделать до второго шага
2.2.2.234/32 via 1.1.1.254

AS ★★★★★ ()
Ответ на: комментарий от zolden

Вот теперь мне лень вчитываться :) Может позже внимательно перечитаю. Надеюсь советы были правильными. Однако вспомнился и rp_filter, тоже посмотрите что там.

anc ★★★★★ ()
Ответ на: комментарий от zolden

Как писал выше. Только точка точка тунель, с «придуманной» адресацией. Вроде достаточно. А дальше роутинг на каждой точке через соответствующий адрес. Имхо этого вполне достаточно.

anc ★★★★★ ()
Ответ на: комментарий от anc

Мм...Придуманная адресация в текущей схеме(я её задокументировал в изначальном топике) же есть(INT_TUNNEL_IP_IN_NETWORK1 и INT_TUNNEL_IP_IN_NETWORK2)
Имеется в виду что вторые адреса( EXT_TUNNEL_IP_IN_NETWORK1 и EXT_TUNNEL_IP_IN_NETWORK2) из текущих сетей излишни?

zolden ★★★★★ ()
Последнее исправление: zolden (всего исправлений: 1)
Ответ на: комментарий от zolden

Ага. Я про вариант чуть по другому с iproute2, без использования вторых адресов. Не всегда же существует такая возможность прописать второй адрес или она есть но не удобно.
Но как писал выше, вариант mky вполне имеет место быть.

anc ★★★★★ ()
Ответ на: комментарий от zolden

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

И, если с ip-адресами совсем напряг, а взаимодействие нужно, то делать для тунеля отдельный (выделенный) порт, по нему настраивать маркировку/маршрутизацию пакетов... Решаемо, но, боюсь, ещё больше бы сообщений в этой теме появилось.

mky ★★★★★ ()
Ответ на: комментарий от mky

Тут только один нюанс. Доступность самого клиента по IP 1.1.1.X. А оно сильно надо? Если можно и по IP туннеля достучаться. Вся остальная связность сети этого не касается.

anc ★★★★★ ()
Ответ на: комментарий от anc

А оно сильно надо?

За точным ответом не ко мне. Я предположил, что тунель будет поднимать постоянно включенная машина, то есть типа сервер, значит важно. Если бы ТС писал, что тунель поднимают коробочки типа бытовых маршрутизаторов с openwrt, я бы это не предполагал.

mky ★★★★★ ()