Возможен ли SelfInterface NAT?

Question

[WSGlebKavash]

Схема

Интерфейсы:

eth0:
IP: 192.168.40.5
Маска подсети: 255.255.255.0
Шлюз: 192.168.40.1
tun0:
IP: {CLIENT_IP}
Маска подсети: 255.255.128.0
Шлюз: {VPN_GATEWAY}

Что имеем: ПК на Linux с двумя сетевыми интерфейсами: проводное соединение и виртуальный интерфейс VPN. Для доступа к интернету VPN программа использует проводной интерфейс. Клиент из этой же локальной сети хочет пустить свой траффик через VPN, т. е. использовать как маршрут по умолчанию. Он указывает адрес шлюза: 192.168.40.5. На ПК IPtables настроен следующим образом:

iptables -t nat -A POSTROUTING -o tun0 -s 192.168.40.0/24 -j SNAT --to-source {VPN_GATEWAY}

. Однако доступ к сетям за VPN клиент не получает. Никаких других брандмаузеров не используется.
Возможен ли кольцевой (SelfInterface) NAT в принципе? Если да, то как настроить?

Comments

[theurs]

Маскарад используй. (зы на такие вопросы чатгпт отвечает почти идеально)

[res2001]

Для начала разрешить пересылку пакетов: net.ipv4.ip_forward
Можно NAT на ВПН интерфейс повесить.
Или настроить маршрутизацию на ВПН клиенте. Клиент, видимо, ничего не знает о вашей сети за ВПН, поэтому ответные пакеты идут не туда. Некоторые ВПН сервера умеют добавлять маршруты клиентам (OpenVPN например) при подключении.

[Alexey Dmitriev]

А я бы для начала посоветовал перестать принимать тяжелые вещества. Тогда фантазии о каких-то "SelfInterface NAT" и назначении на маршрузитируемый tun0 интерфейс в отдельном домене адресов из локалки перестанут лезть в голову при наличии отдельного интерфейса tun0 и стандартной схемы - маршрутизация + SNAT\MASQUERADE, которая описана в интернетах миллионы раз.

[WSGlebKavash]

Alexey Dmitriev,

и назначении на маршрузитируемый tun0 интерфейс в отдельном домене адресов из локалки

А кто это пытается делать? Мне наоборот нужен классический NAT, где входным интерфейсом будет проводное соединение, а выхнодным - tun0.

Answer 1

[hint000]

VPN_GATEWAY - это адрес, назначенный интерфейсу tun0, верно?
Вообще, мне нравится такой ход мыслей.
Но нужно убедиться, что ipv4.ip_forward=1, т.к. нужна пересылка пакетов между eth0 и tun0. Далее убедиться, что iptables в цепочке FORWARD не блокирует такую пересылку. Далее прогнать traceroute или mtr с хоста клиента до любого адреса в интернете - пытаются ли пакеты идти на дальний конец VPN или не пытаются. Если пытаются, то доходят ли. Если не пытаются, то проблема с маршрутизацией или форвардингом. Если пытаются без ответа, то либо проблема с NAT, либо какая угодно проблема на дальнем конце VPN. Если и после этого яснее не стало, то остаётся "тяжелая артиллерия" - проверка с tcpdump.

А так в целом схема работоспособна.

Comments

[WSGlebKavash]

hint000,

VPN_GATEWAY - это адрес, назначенный интерфейсу tun0, верно?

Вовсе нет. Это адрес маршрута по умолчанию, выдаваемого VPN сервером.

[shurshur]

WSGlebKavash, это ошибка, надо CLIENT_IP.

Собственно, суть nat в том и состоит, что он подменяет IP проходящего пакета на свой.

[hint000]

WSGlebKavash, вот не зря вам в комментарии посоветовали MASQUERADE - он бы оградил от этой ошибки, по сути делал бы SNAT, но подменяя именно на тот адрес, который нужно, без явного указания этого адреса. А если явно указывать через SNAT, то нужно как говорит shurshur .

[WSGlebKavash]

shurshur, Заработало. Большое спасибо!

Answer 2

[Талян]

слушай у меня такая же ситуация была - у клиентов было 192.168.0.0 дома на роутере и у нас в конторе такая же сеть (ну так сделал админ - капец еще и по маске 24).

В микротике есть тип НАТ - Netplan. Ты с точки зрения роутера маршрутизируешь трафик с родной сети в другую а уже построутинг подменяет адрес назначения с фейкового (с которым не конфликтует сеть предприятия) на адрес клиента хоть по 32 маске.

Надо глянуть просто тебе как на iptables реализовать netplan