Очень прошу о помощи знатоков, так как уже очаялся и абсолютно не уверен в правильности текущего используемого решения. Прошу сильно не пинать - гуглил все, что только можно - везде подобные ситуации описываются по-разному, да и к тому же не встречал ни разу ситуацию, идентичную моей.
-------------------------------
Суть вопроса:
правильно настроить шлюз на виртуалке (vmware) debian 9.9 для хождения в интернет второй вируталки (так же debian) через данный шлюз. Хочу уточнить, что схема работает на данный момент, но я очень сомневаюсь, что работает правильно и так, как хотелось бы.
Исходные данные:
Виртуалка debian-шлюз:
Имеет 3 сетевых (вируальных, естественно) адаптера:
1a) eth0 - с помощью которого debian имеет исходный выход в интернет - это custom type-адаптер, с включенным NATом, DHCP; настройка "connect host to this network" - отключена;
настройки в нетворк менеджере внутри виртуалки у соединения: "Автоматически по DHCP, только адрес", то бишь DNSы я указал публичные (допустим, 8.8.8.8 - не столь важно);
итого допустим, что
IP 192.168.19.5
mask 24
gateway 192.168.19.2
DNS 8.8.8.8
2a) tun0 - tun0 - запущенный на виртуалке OPENVPN-клиент от некоего VPN-сервера/провайдера c
IP 10.0.5.5
gateway 10.0.5.1
DNS 208.67.222.222
3a) eth1 - адаптер "созданной" виртуальной локалки, также custom-type; здесь такие настройки сетевого адаптера: NAT - нет, DHCP - нет, connect to host - нет;
настройки в нетворк менеджере внутри виртуалки у этого соединения: "Общий с другими компьютерами", с указанным статическим ip, допустим, 192.168.2.1, маской 24 и шлюзом 192.168.2.1
Виртуалка #2 (условно, дебиан-клиент):
находится в одной виртуальной локалке со шлюзом и имеет 1 сетевой адаптер eth0, идентичный адаптеру 3a) дебиан-шлюза, с настройками в нетворк менеджере:
статический IP 192.168.2.2
маска 24
gateway 192.168.2.1
DNS, допустим, 77.88.8.8
Задача - нужно, чтобы:
дебиант-клиент выходил в интернет через локалку 3а) интерфейса (соединение eth1) дебиан-шлюза;
в свою очередь, eth1 дебиан-шлюза должен раздавать интернет клиенту по средствам eth0 этого же дебиант-шлюза через tun0 того же дебиан-шлюза.
То бишь: ETH0-клиента --> ETH1-шлюза --> TUN0-шлюза --> ETH0-шлюза --> хостовой физический адаптер --> интернет.
Я думаю, что многие сейчас покрутят пальцем у виска. Я очень прошу, помогите разобраться с правильно работающей схемой, ибо я не уверен, что сейчас роутится-натится-работает так, как описано в желаемой схеме-задаче выше.
Для чистоты "эксперимента" хотелось бы услышать от знающих людей именно решение, хотя бы в кратце, и, подчеркну, если таковое вообще реально по вашему мнению. Не сочтите за наглость...
Надеюсь, что кто-нибудь откликнется!
Заранее спасибо!
tun0 у вас не задействован.
Вообще не ясно зачем в схеме tun0? Вы чего этим хотите добиться?
Сейчас у вас такая схема:
ETH0-клиента --> ETH1-шлюза --> ETH0-шлюза --> хостовой физический адаптер --> интернет
И в текущей конфигурации вы туда никак не воткнете tun0.
Если вам нужно ходить в инет через ВПН, то насройте на дебиан-клиент ВПН клиента. И настройте ВПН сервер так, чтобы он был шлюзом по умолчанию для клиентов.
Тогда схема будет такая:
TUN0-клиента --> ETH0-клиента --> ETH1-шлюза --> TUN0-шлюза --> ETH0-шлюза --> хостовой физический адаптер --> интернет
res2001, большое спасибо за ответ!
То есть на дебиан-шлюзе, вместо нынешнего впн-клиента, приконнекченного к серверу некоего стороннего vpn-сервиса, поднять VPN-сервер, верно? А получится ли? ведь шлюз изначально по нату получает интернет от хостовой. Соответственно, белого IP нет - только серый 192.168.19.5. Вопрос наверно глупый, так как я абсолютно запутался, но разве с дебиан-клиента получится приконнектиться к поднятому vpn серверу шлюза, который не имеет внешнего ip?
P.S. шлюз на шлюзе из настроек соединения eth1 убрал, спасибо! Вот, уже первая моя ошибка. Почему работало с оным (с указанным шлюзом для eth1) - не пойму... Уффф, скоро голова лопнет =(
res2001, задача - максимально (на сколько это возможно в пределах одного хоста и двух крутящихся на нем вируалок - шлюза и клиента), скажем так, "отдалить" хоста от конечного клиента. Сделать, на сколько это возможно, опять же, эффект НЕнахождения (сорри за кривой венегрет) хоста и конечной виртуалки-клиента в одной (фактически - получается так) сети. Я, разумеется понимаю, что все это звучит бредово, наверно, и что в итоге все пути безусловно сводятся к хосту, но.... в той или иной степени, как говорится, "и мы все тоже братья", и наш траффик в итоге тоже льется на ограниченное кол-во пограничных маршрутизаторов и прочее... Именно поэтому на шлюзе VPN клиент от стороннего сервиса. Ранее была мысль пустить через TOR траффик шлюза, но проблема в том, что на клиенте ни в коем случае нельзя точку выхода с TOR-IPадресом.
В целом та схема, которую я предложил в первом посте подходит.
Если вам нужно моделировать разные сбойные ситуации в сети, то это вряд ли подойдет. Для этого есть другое решение.
res2001, цели легальные, если Вы в этом смысле!
То есть получается, необходимо, поднять на шлюзе VPN-сервер. Тогда встает вопрос, как мне коннектиться с клиента к шлюзу по средствам VPN? Внутренний адрес шлюза:проброшенный порт (от шлюза к клиенту)? В сторону какого протокола VPN сервера мне смотреть?
DeforondA, Пришла еще мысль в голову про "отдаление" клиента с использовнием стороннего ВПН.
Настраиваете ВПН клиент на дебиан-клиенте для подключения к стороннему ВПН серверу. На дебиан-шлюзе ВПН оставляете в первоначальном виде. ВПН сервер не должен быть шлюзом по умолчанию для клиентов. На дебиан-клиенте прописываете маршрут по умолчанию через ВПН адрес дебиан-шлюза, отдельно прописать маршрут через ETH1 шлюза к сети оператора ВПН.
Схема прохождения пакетов от дебиан-клиента в интернет будет такая:
TUN0-клиента --> ETH0-клиента --> ETH1-шлюза --> ETH0-шлюза --> сторонний ВПН сервер --> ETH0-шлюза --> TUN0-шлюза --> ETH0-шлюза --> интернет
В сторону какого протокола VPN сервера мне смотреть?
Рекомендую OpenVPN. Хотя это на любителя. Если вы хорошо владеете чем-то другим, то используйте другой протокол.
как мне коннектиться с клиента к шлюзу по средствам VPN?
У вас обе ВМ в одной сети, так что проблем не будет с подключением.
По настройке клиента и сервера полно мануалов.
Последний предложенный мной вариант - это большой изврат, возможны сложности в настройке ВПН и маршрутизации. Но в целом схема видится рабочей. Хоть я и не представляю для каких практических задач может понадобиться подобное "отдаление" клиента.
Если работать и больше ничего. Начните с https://www.whonix.org/. Там есть гейтвей и воркстейшен. Простая инструкция. Потом подпимите впн-клиента на гейтвее, как на обычном линуксе и все будет работать.
Если разобраться.
1. Делаем 2 ВМ: Шлюз, вПК. В настройках вирт. адаптера объединяем их в один сегмент локальной сети. Шлюз - 2 адаптера: первый - внешний пусть пока будет НАТ или мост, если у вас есть домашняя сеть с роутером; второй - локальный, там указываете имя сегмента вирт. локальной сети. И Виртуалбокс и ВМВарь это умеют.
2. Настройте Шлюз как обычно, чтобы он пускал в сеть вПК. Это класическая тема, ищите мануалы в сети snat + forwarding. Как настроите и проверите, можно дальше двигаться.
3. На Шлюзе настраивайте впн-клиент до внешнего впн-сервера. Проверяте чтобы локально работало через впн-сервер и дефолтовый маршрут был на впн-сервер. Логично, что тогда и вПК будет ходить в инет также. Ему-то пофиг, что там с трафиком после того, как он отправил его своему дефолтовому гейтвею.
4. Научиться контролировать статус соединения, чтобы не было утечки, когда впн на Шлюзе не работает. И запросы к ДНС или на Шлюзе обрабатывались, или через впн шли.
Сложный
Простой
Простой
