Почему при подключении к серверу-донору VPN показывает настоящий IP?

Question

[Александр]

Настроил OpenVPN-сервер на VDS. Всё работает, всё отлично. Кроме VPN на VDS ещё есть сайты и открыт доступ по SSH. И почему-то, если подключаться к VDS по HTTP(S) или по SSH из-под VPN, которое запущено на том же самом VDS, то отображается реальный IP (IP от интернет-провайдера). Почему так происходит?

server.conf

port 161
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh.pem

cipher AES-256-CBC

server 10.10.15.0 255.255.255.0
ifconfig-pool-persist ipp.txt

push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "redirect-gateway def1"

keepalive 10 120
comp-lzo
user openvpn
group openvpn
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 5

client.ovpn

# --------------------------------------------------------
# Настройки для подключения к VPN на vpn.example.com
# -- Версия настроек от 14.08.2019
# --------------------------------------------------------

client
dev tun
proto udp
remote vpn.example.com 161
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
key-direction 1
block-outside-dns
cipher AES-256-CBC
comp-lzo
verb 3

<ca>
# Тут сертификат ЦС
</ca>
<cert>
# Тут сертификат клиента
</cert>
<key>
# Ключ клиента
</key>

Comments

[pcdesign]

Покажите конфиги сервера и клиента.

[Александр]

pcdesign, дополнил вопрос

[pcdesign]

Александр, я вот у себя пробую на ssh, на том же серваке, что и openvpn и вижу такую картину

# who|grep root
root     pts/7        2019-08-21 10:36 (10.3.3.6)

Методом сравнения все станет ясно.

Покажите еще
iptables -t nat -nvL

[Александр]

pcdesign,

я вот у себя пробую на ssh, на том же серваке, что и openvpn и вижу такую картину

У меня там IP от интернет-провайдера вместо IP из VPN-сети

iptables -t nat -nvL

Chain PREROUTING (policy ACCEPT 2835K packets, 316M bytes)
 pkts bytes target     prot opt in     out     source               destination
2836K  316M PREROUTING_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0
2836K  316M PREROUTING_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
2836K  316M PREROUTING_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain INPUT (policy ACCEPT 2735K packets, 308M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 129K packets, 11M bytes)
 pkts bytes target     prot opt in     out     source               destination
 129K   11M OUTPUT_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 132K packets, 12M bytes)
 pkts bytes target     prot opt in     out     source               destination
 229K   20M POSTROUTING_direct  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 229K   20M POSTROUTING_ZONES_SOURCE  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 229K   20M POSTROUTING_ZONES  all  --  *      *       0.0.0.0/0            0.0.0.0/0
96347 7613K MASQUERADE  all  --  *      eth0    10.10.15.0/24        0.0.0.0/0
    0     0 MASQUERADE  all  --  *      eth0    10.10.15.0/24        0.0.0.0/0

Chain OUTPUT_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING_ZONES (1 references)
 pkts bytes target     prot opt in     out     source               destination
 225K   19M POST_public  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           [goto]
 3926  566K POST_public  all  --  *      +       0.0.0.0/0            0.0.0.0/0           [goto]

Chain POSTROUTING_ZONES_SOURCE (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain POST_public (2 references)
 pkts bytes target     prot opt in     out     source               destination
 229K   20M POST_public_log  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 229K   20M POST_public_deny  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 229K   20M POST_public_allow  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain POST_public_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain POST_public_deny (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain POST_public_log (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PREROUTING_ZONES (1 references)
 pkts bytes target     prot opt in     out     source               destination
2736K  308M PRE_public  all  --  eth0   *       0.0.0.0/0            0.0.0.0/0           [goto]
 100K 8190K PRE_public  all  --  +      *       0.0.0.0/0            0.0.0.0/0           [goto]

Chain PREROUTING_ZONES_SOURCE (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PREROUTING_direct (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PRE_public (2 references)
 pkts bytes target     prot opt in     out     source               destination
2836K  316M PRE_public_log  all  --  *      *       0.0.0.0/0            0.0.0.0/0
2836K  316M PRE_public_deny  all  --  *      *       0.0.0.0/0            0.0.0.0/0
2836K  316M PRE_public_allow  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain PRE_public_allow (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PRE_public_deny (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain PRE_public_log (1 references)
 pkts bytes target     prot opt in     out     source               destination

[res2001]

Где отображается реальный IP?
Как вы подключаетесь к VDS по ssh? Какой адрес указываете? То же для HTTP.

[Александр]

res2001, например, при вводе who | grep root, также при приветствии (Last login Xxxx from YY.yy.yy)

Как вы подключаетесь к VDS по ssh? Какой адрес указываете? То же для HTTP.

С помощью ключа. Указываю домен сервера, который преобразуется в белый IP-адрес сервера. Для HTTP(S) - один из доменов, который расположен на сервере и, соответственно, также преобразуется в белый IP-адрес

[res2001]

Александр,

Указываю домен сервера, который преобразуется в белый IP-адрес сервера.

Вот ответ на ваш вопрос. Как правильно ответил landergate внешний адрес ВПН сервера исключен из маршрутизации через ВПН не взирая на присутствие директивы
push "redirect-gateway def1"
Т.е. вы по факту ходите на ВДС не через ВПН, а на прямую. Это, кстати, легко проверить.
Подключайтесь к ВДС, указывая его внутренний ВПН адрес.
Можно заморочиться и поднять на ВДС ДНС сервер, который будет отдавать внутренние адреса для ваших доменов при подключенном ВПН.

[landergate]

да, можно подключаться по SSH используя внутренний IP сервера в VPN-сети
можно открывать через него и сайт, если придумать, как у себя заменить резолвинг этой днс-записи во внутренний адрес, но это действительно сильно усложняет настройку

Answer 1

[landergate]

Потому, что для возможности маршрутизировать ваш трафик через VPN, ваша таблица маршрутизации вынуждена исключать адрес самого VPN-шлюза, иначе она не сможет соединиться с VPN-шлюзом.

Если вам необходимо сокрытие адреса и на этом сервере, этого можно добиться подключением с другого места, т.е. либо перенеся VPN-сервер на другую ноду, либо используя сторонние прокси, либо используя Tor.

Ещё можно подключаться к серверу по SSH по его внутреннему IP в этой приватной сети, а затем входить на сайт через local port forwarding, настроив его, например, на 1234:127.0.0.1:80, а затем открывая у себя в браузере 127.0.0.1:1234. В этом случае в логах сайта подключения будут происходить с 127.0.0.1.
Возможные нюансы: 1) ссылки на сайте должны быть относительными, а не заполнены полным доменным именем, иначе в браузере они все будут выглядеть не как 127.0.0.1:1234/something/, а всё-время переключать на основной домен; 2) сам сайт для этого должен разрешать приём подключений без указания домена, иначе случится несовпадение location/vhost и сайт таким способом не откроется.

Comments

[Александр]

таблица маршрутизации должна исключать адрес самого VPN-шлюза

Как это сделать?

[landergate]

Александр, это ответ на вопрос, почему это происходит
вам ничего делать с этим не нужно

вы не сможете перенаправлять трафик через сервер, не исключив этот самый сервер из правил перенаправления

[Александр]

landergate, то есть при подключении к серверу из-под VPN, запущенного на том же сервере, всегда будет виден IP от провайдера и с этим ничего сделать нельзя?

[landergate]

Александр, да, потому что вы не сможете соединяться через ВПН, если доступ к серверу ВПН не будет прямым

я обновил ответ вариантами обхода

Answer 2

[younghacker]

Александр,
Если Вам необходимо спрятать сам факт подключения к серверу по ssh то Вам нужно на сервере настроить iptables так чтобы он разрешал соединения на ssh порт если пакет приходит на tun+ интерфейс.

-A INPUT -i tun+ -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT -m comment --comment "Accept all connections from tun interface"

И затем после подъёма vpn соединения с OpenVPN клиента подключайтесь на адрес ssh root@10.10.15.1 - судя по вашему конфигу это должен быть адрес tun интерфейса вашего OpenVPN сервера.

Несколько замечаний по топику:
DNS Leak отягощённый VPN с единственной точкой входа и выхода.
Или на более понятном языке - ваш провайдер, особенно хостинг, может видеть шифрованный и нешифрованный трафик одновременно. И как результат - получить ключики шифрования.
SSH трафик на внутренний IP - исключение. Его не увидят ни хостинг ни интернет провайдеры (при условии что последний не контролирует ваш роутер).
Также помним, что Win10 рассылает DNS запросы со всех интерфейсов несмотря на роуты. Fedora через другие нероутные интерфейсы тоже рассылает запросы на порт 80. Поэтому тонкая настройка файрвола необходима даже там.

Comments

[Александр]

Win10 рассылает DNS запросы со всех интерфейсов несмотря на роуты

Что с этим можно сделать?

[younghacker]

У винды всё сложно. А у десятки ещё сложнее. Никогда нельзя гарантировать что после очередного апдейта она не сделает это в обход даже стороннего файрвола который работает на той же машине.

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

Сторонние файрволы (не тестировал) но вроде бы какие-то были которые могут работать с правилами привязанными к интерфейсам.

"Хардкорная" блокировка - ставить свой внешний роутер который сам заблокирует все запросы кроме трафика на VPN сервер и NTP на доверенные серверы. Тогда можно гарантировать, что никакой DNS запрос или DNS over https не убежит наружу в обход VPN. Да и вообще в случае падения VPN эта схема гарантирует что ни один незашифрованный пакет не попадёт в чужие руки.

Answer 3

[pcdesign]

Если я не ошибаюсь, то надо отказаться от MASQUERADE в пользу SNAT
То есть удалить строки, где openvpn трафик засовывается в MASQUERADE, а вместо этого прописать:

iptables -t nat -I POSTROUTING -s 10.10.15.0/24  -j SNAT --to-source БЕЛЫЙ_IP_VDS

Кстати, SNAT быстрее работает, чем MASQUERADE