Интерфейс подключения OpenVPN не подключается к общедоступному IP-адресу сервера через туннель
У меня есть сервер с 1 интерфейсом, подключенным к tap0 . Также клиент с 2 интерфейсами, которые имеют общедоступное подключение к Интернету ( eth1 и eth2 ) и туннель для интерфейса 2,так что я могу отправлять трафик через tap0 и фактически отправлять данные через eth2 .
если я делаю
curl ifconfig.co
, я получаю публичный IP-адрес eth1 . Если я сделаю
curl ifconfig.co --interface eth2
, я получу публичный IP-адрес eth2 , а если я сделаю
curl ifconfig.co --interface tap0
, я получу публичный IP-адрес сервера (он прошел через туннель, так что все в порядке).
tap0 находится в подсети 192.168.0.0/24 (другие - 192.168.1.0/24 и 192.168.3.0/24 , поэтому нет конфликт здесь), и я могу правильно подключиться к 192.168.0.1 , 192.168.0.22 (который является локальным IP-адресом сервера) и т. д.
Я установил на сервере маршрутизатор ( 192.168.0.1 ) перенаправление портов, которые мне нужны, на машину по адресу 192.168.0.22 (iperf3, 80, OpenVPN и т. Д.).
Короче говоря, я думаю, что я все работает правильно до этого момента.
Проблема возникает, когда я хочу подключиться к общедоступному IP-адресу сервера. Допустим, общедоступный IP-адрес 1.2.3.4 через VPN. Если я сделаю
curl 1.2.3.4
, я получу всю необходимую информацию, поскольку соединение идет через eth1 к маршрутизатору сервера, который перенаправляет его на локальный компьютер, на котором находится сервер. Но если я сделаю
curl 1.2.3.4 --interface tap0
НИЧЕГО НЕ ПРОИСХОДИТ!
Проверяя клиента tap0 с помощью tcpdump, я вижу, что запрос создан
Но этот запрос никогда не достигает tap0 на сервере (проверено eth0 на сервере на наличие входящих UDP-пакетов OpenVPN, и новые пакеты не поступают, когда этот создается клиентом tap0 ). Это eth0 на сервере при подключении к чему-либо еще от клиента:
Это становится расшифрованным пакетом на tap0 , и нет необходимости говорить, что расшифрованный пакет не появляется на tap0 , когда там нет UDP-пакета.
Я не знаю, что это такое. происходит здесь. Я думал, что все пакеты, которые проходят через tap0 на клиенте, будут отправляться на сервер без ограничений, но это не похоже на тот случай.
Кроме того, если я перейду на серверную машину 192.168.0.22 и выполняю curl для общедоступного IP-адреса, я получаю соединение с веб-сервером, и curl получает результат, поэтому у сервера не возникает проблем с подключением к самому себе.
Diagram ([ Не убивай меня ):
Что я могу сделать, чтобы подключения к общедоступному IP-адресу моего сервера работали при отправке через tap0 ?
Понятно! Я думаю, что это скорее обходной путь, чем другие вещи, но он работал так, как ожидалось.
Просто нужно было создать правило iptables , которое изменит пункт назначения пакетов, если источник и пункт назначения соответствуют общедоступным IP сервера и IP туннеля:
iptables -t nat -A OUTPUT -s [client tap0 IP] -d [server public IP] -j DNAT --to-destination [server local IP]
И готово! Прекрасно работает с MP-TCP.
Во-первых, вы должны принять, что для того, чтобы VPN оставалась подключенной, соединения от VPN-клиента к VPN-серверу должны происходить за пределами VPN.
Во-вторых, вы должны понимать, что curl 1.2.3.4 --interface tap0 ничего не меняет о маршрутизации на вашем клиенте. Все, что он делает, это контролирует исходный IP-адрес пакета. Если вы подключаетесь к внешнему IP-адресу VPN-сервера, он все равно будет выходить напрямую, а не волшебным образом попасть в туннель.
В любом случае внимательно посмотрите на свою таблицу маршрутизации , она расскажет вам, как пакеты будут проходить.
Что я могу сделать, чтобы подключения к общедоступному IP-адресу моего сервера работали при отправке через tap0?
Стандартный ответ: нет.Используйте разделенный DNS или что-то еще, чтобы, когда ваша VPN работает, вы используете внутренние адреса.
Сложный / хакерский ответ: если все ваши клиенты основаны на Linux, вы могли бы что-то сделать с маршрутизацией и настройкой политики, чтобы трафик OpenVPN все еще пересекался общедоступная сеть, а не OpenVPN-трафик использует туннель. Но это почти наверняка будет чрезвычайно сложно настроить и потребует некоторых странных сценариев. Я этого не делал и не знаю никаких руководств.