Как расшарить внешнюю VPN сеть во внутреннюю

[bureaua]

Ubuntu Server 18.04

eth0: -- внешняя сеть провайдера
eth1: -- внутренняя сеть
cscotun0 -- интерфейс, который создается при VPN подключении (Ubuntu Server выступает клиентом) с Ubuntu Server

Код: [Выделить]


  External      |   Internal
  network       |    network
   ______       |
  |      |      |   
  | eth0 |      |    ______
  |______|      |   |      |
                |   | eth1 |
     |          |   |______|
 __________     |
|          |    |
| cscotun0 |    |
|__________|    |
                |



Каким образом с внутренней сети можно получить доступ к сети VPN подключения?
Создавать bridge (br0) на eth0 и cscotun0, а потом прописывать
iptables -t nat -A POSTROUTING -o br0 -j MASQUERADE
?

Потому как на данный момент, после
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
пакеты пробрасываются в сеть eth0, при этом VPN сеть остается недоступной

А при
sudo iptables -t nat -A POSTROUTING -o cscotun0 -j MASQUERADE
VPN сеть также остается недоступной с внутренней сети

Настроив с помощю arno-iptables-firewall машины с VPN сети начали пинговатся, но при попытке открыть web страницу с внутреннего сервера на стороне VPN -- ответ в браузере получаю такой как будто пробую зайти без подключенного VPN
То есть удаленный сервер за VPN считает что я захожу с другого IP (не того который получил при VPN соединении )

после того как прописав в файле hosts имя хоста -- заработало только для тех сайтов сервера которых вообще не пинговались.
Но вопрос в том, а без прописывания в hosts, что нужно дополнительно выполнить, прописать роуты? Так при подключении, VPN сам их прописал на Ubuntu Server

[AnrDaemon]

Для начала вам стоит понять простую вещь - с точки рения сервера cscotun0 ничем от eth0 не отличается.
Все отличия задаются маршрутизацией, вот её и крутите.
Потом уже беритесь за брандмауэр.

[bureaua]

Вроде как пофиксил.
Работает в связке с
arno-iptables-firewall + dnsmasq

Единственное что когда свич на eth1 отключается -- приходится делать переконфигурацию

[bureaua]

А как это так может быть что бы nslookup выдавал один IP адрес ресурса, а при пинге -- другой? (с компа что во внутренней сети)
Подскажите в какую сторону копать...

[eyakubovskiy]

А как это так может быть что бы nslookup выдавал один IP адрес ресурса, а при пинге -- другой? (с компа что во внутренней сети)
Подскажите в какую сторону копать...

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

PS: на след день понял, что написал здесь бред не относящийся к проблеме

[bureaua]

>> А у вас проблемы из-за этого?
Да, веб ресурсы, размещенные на удаленном внутреннем сервере (см. архитектуру сети в первом посте),  не открываются

[eyakubovskiy]

Архитектура в первом посте у вас некорректно нарисована. Когда у вас поднимается VPN -это такой же равнозначный интерфейс как и физический. Т.е. все интерфейсы должны быть нарисованы в один ряд.
10 минут перечитывал, что написали - очень сложно понять.
Есть сервак с тремя картами. Одна из них виртуальная и создается при VPN подключении.
Нас интересуют две сети - по сторону внутренней карты сервака и по сторону VPN-карты.
Клиент у вас в локальной сети сервера, а целевой сервер в сети VPN.
Все верно?

Далее описываю логику для данной схемы.
Во-первых, сервер должен быть шлюзом и клиент его должен считать шлюзом (eth1). Иначе весь трафик будет рулиться другим устройством.
Во-вторых, вам nat не нужен если вы хотите с целевым устройством общаться как в одной сети. В ином случае целевое устройство будет общаться с cscotun0, а не с сетевой картой клиентской машины. Но NAT тоже допустим. Все зависит от задачи.
В-третьих, нужно прописать маршрут. Шлюз должен знать, что в подсеть за VPN-картой или на перечень IP в этой подсети трафик из внутренней сети (или с сервера, или любой трафик) в сеть VPN нужно слать через cscotun0.
В-четвертых, должны быть правила разрешающие хождение трафика между двумя сетями в обе стороны.

Пользователь добавил сообщение 12 Февраля 2019, 23:29:42:Если без ната - в впн сети сервер Ubuntu тоже должен быть шлюзом.
Пользователь добавил сообщение 12 Февраля 2019, 23:44:21:Если сервер не шлюз - маршрутизация тоже возможно, но на шлюзах нужно тогда прописывать маршруты для перенаправления трафика на интерфейсы сервера.
Пользователь добавил сообщение 12 Февраля 2019, 23:47:47:

А как это так может быть что бы nslookup выдавал один IP адрес ресурса, а при пинге -- другой? (с компа что во внутренней сети)
Подскажите в какую сторону копать...

Это возможно. Не гарантирую, но может дело в том, что пинг идет по протоколу  icmp и возможно, что для него у вас другие правила прописаны

[AnrDaemon]

eyakubovskiy, у человека просто iptables головного мозга. Любую проблему сразу кидается решать через iptables, независимо от того, где именно она возникла.

[bureaua]

Все верно?

Да, верно

... где именно она возникла.

Вместо того что бы обзываться, лучше бы помогли бы мне разобраться тем самым предотвратив "глупые вопросы" с моей стороны в следующий раз.

[AnrDaemon]

Топик читать не пробовали?