Почему сервер видит реальный ip вместо ip VPN?

Question

[Vitaly]

Есть сервер-1 с openvpn-сервером; сервер-2 с apache, mongod и проч.

На компьютере запущен VPN-клиент. Проверяю свой ip через whatismyipaddress.com, либо любой другой онлайн-сервис — определяется ip-адрес сервера-1, всё ок.

Захожу на сайт, работающий на сервере-2 и смотрю лог apache. Вместо ip-адреса сервера-1 (с openvpn) определяется мой реальный ip-адрес от провайдера.

Повторяю тест с mongodb. Захожу под vpn и смотрю лог — там тоже ip-адрес от провайдера вместо ip-адреса openvpn-сервера.

Почему так? И как это вообще называется? Ip leakage? Но почему утечку видит только мой сервер, а whatismyipaddress.com, например, нет?
Собственно мне нужно было настроить правила в iptables, чтоб доступ к mongo, postgresql был разрешён только через VPN.

server.conf

port 1194

proto udp
dev tun
ca ca.crt
cert rdv-strasbourg.crt
key rdv-strasbourg.key  # This file should be kept secret

dh dh.pem

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist /var/log/openvpn/ipp.txt

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 208.67.222.222"
push "dhcp-option DNS 208.67.220.220"

client-to-client

keepalive 10 120
tls-auth ta.key 0 # This file is secret
cipher AES-256-CBC
auth SHA256
user nobody
group nogroup
persist-key
persist-tun

status /var/log/openvpn/openvpn-status.log

verb 3
explicit-exit-notify 1%

Правила iptables, касающиеся openvpn:

*nat
# :PREROUTING ACCEPT [0:0]
# :INPUT ACCEPT [0:0]
# :OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
-A OUTPUT -o tun+ -j ACCEPT
COMMIT


*filter
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

-A OUTPUT -j ACCEPT

# Openvpn
-A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT
-A INPUT -i tun+ -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT

-A INPUT -j REJECT
-A FORWARD -j REJECT

--policy INPUT DROP
--policy FORWARD DROP
--policy OUTPUT ACCEPT

COMMIT

Comments

[Sergey]

А как связаны сервер1 и сервер2?

[Vitaly]

Sergey, никак не связаны и физически в разных странах

[Vitaly]

Sergey, нет, пардон. Они связаны только через dns. На сервере-1 находится primary DNS (ns1.domain.com), на сервере-2 — slave (ns2.domain.com). Но я не думаю, что это важно в данном контексте.

[Sergey]

Виталий Соколов, с компа сделайте трассировку до сервера2, увидите через какие хосты идёт. Через vpn или мимо него.
Днс сервера не должны влиять на ип адреса.

[Vitaly]

Sergey, Спасибо за подсказку, трассировка показала, что пакеты действительно шли не через сервер. Я до сих пор не понимаю, почему при этом 2ip.ru определял мой ip как ip openvpn-cервера, но ладно.
Назревает новый вопрос: как заставить клиентский vpn выполнять `sudo route -n flush` ? Добавить это в конфиг openvpn на клиенте?

[Sergey]

Виталий Соколов, надо добавлять дефолтный маршрут, потому что могут быть разные маршруты, нужные пользователю.

Answer 1

[nApoBo3]

Сам по себе vpn ничего не скрывает. Скрывает или nat, или proxy. Плюс через vpn вообще не может быть доступен ваш внешний адрес, поскольку для трафика внутри туннеля адрес источника это адрес туннельного интерфейса, а не адрес вашего интернет соединения.
Скорее всего трафик до нужных вам сервисов идёт не через туннель. Смотрите трассировку.

Comments

[Vitaly]

Да, так и есть. Траффик шёл не через туннель. На MacOS помогло sudo route -n flush
Но я не понимаю, как настроить так, чтобы при каждом подключении к VPN (у меня несколько VPN), выполнялась эта команда, да еще и от рута. Потому что руками каждый раз делать ifconfig en0 down, потом обнулять таблицу, потом опять ifconfig en0 up неудобно.

[Karpion]

nat и proxy точно так же ничего не скрывают - в том смысле, в каком это хочет Виталий Соколов !

[nApoBo3]

Karpion, приведите пример раскрытия сетевого адреса отправителя с стороны получателя используя данные транспортного уровня при нахождении отправителя за нат?

[Karpion]

nApoBo3, Ну, начнём с того, что Виталий Соколов и не просил что-либо скрывать. Перечитайте исходный вопрос: задача в том, чтобы "доступ к mongo, postgresql был разрешён только через VPN". Слово "скрывать" пустили в дискуссию Вы.

[nApoBo3]

Karpion, как это относится к вашему утверждению?
В вопросе есть формулировка "утечка", это раскрытие закрытой информации.

[Karpion]

nApoBo3, Есть такое слово. Но проблема - не в нём.

Пусть Виталий Соколов придёт и нас рассудит. Ведь проблема явно не в том, что его IP-адрес раскрывается ег серверу; а в том, что его сервисы доступны кому угодно.

[Vitaly]

nApoBo3, да, в вопросе я написал " Ip leakage", но не был уверен, что это именно так называется.
Судя по всему нет, потому что при сбросе таблицы маршрутизации на клиенте пакеты идут через openvpn-сервер и мой реальный ip от провайдера не виден.

[Vitaly]

Karpion, нет. Все сервисы вроде Mongo (доступ к которым нужен только мне, а не всем подряд) закрыты правилами iptables для ip-адреса VPN-сервера.
Т.е. проблема не в том, что к MongoDB может подключиться кто угодно, а наоборот — иногда меня самого не пускают из-за того, что в MacOS изменилась таблица маршрутизации и пакеты идут не через VPN, а через моего провайдера напрямую, т.е. вместо ip-адреса VPN-сервера виден ip-адрес, выданный провайдером.

Каждый раз, когда такое происходит, мне приходится выполнять:

sudo ifconfig en0 down
sudo route -n flush
sudo ifconfig en0 up

Моя задача сейчас — это понять почему так происходит и найти решение, чтобы не выполнять вышеуказанные команды постоянно при изменении маршрутов.

[Karpion]

Виталий Соколов, Так, поехали ещё раз:

1. У каждого компьютера с поддержкой Интернет-протоколов изначально есть IP-адрес 127.0.0.1 на loopback-интерфейсе.
   
2. После подключения к провайдеру (или к лок.сети, которая как бы провайдер) - на компьютере появляется второй IP-адрес на сетевой карте (выданный по DHCP или записанный статически).
   
3. После установления VPN-соединения - появляется третий IP-адрес на VPN-интерфейсе.
   

Итак, клиент (MacOS) устанавливает VPN-соединение с сервером (Linux), на котором крутятся DB-сервисы. По какому IP-адресу Вы обращаетесь к СУБД - по второму (LAN) или по третьему (VPN)?

Как выглядит таблица маршрутизации в моменты, "когда соединение правильное" и "когда соединение неправильное"?

[Vitaly]

Итак, клиент (MacOS) устанавливает VPN-соединение с сервером (Linux), на котором крутятся DB-сервисы. По какому IP-адресу Вы обращаетесь к СУБД - по второму (LAN) или по третьему (VPN)?

Я обращаюсь с третьего IP-адреса (ip VPN-сервера, 78.ХХ.ХХ.ХХ) на статический ip-адрес сервера с БД 51.ХХ.ХХ.ХХ (на этом сервере VPN не используется).
Соответственно, чтобы пускать пользователей, использующих VPN, в iptables на сервере с БД я добавил правило:

-A INPUT -s 78.XX.XX.XX -p tcp --dport 27017 -j ACCEPT

Когда "соединение правильное", таблица следующая:
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
0/1 10.8.0.5 UGSc 141 0 utun2
default 192.168.1.1 UGSc 9 0 en0
10.8.0.1/32 10.8.0.5 UGSc 0 0 utun2
10.8.0.5 10.8.0.6 UHr 48 0 utun2
78.ХХ.ХХ.ХХ/32 192.168.1.1 UGSc 1 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 43 11085435 lo0
128.0/1 10.8.0.5 UGSc 6 0 utun2
169.254 link#7 UCS 1 0 en0 !
192.168.1 link#7 UCS 3 0 en0 !
192.168.1.1/32 link#7 UCS 1 0 en0 !
192.168.1.1 a8:5e:45:29:2:78 UHLWIir 4 26 en0 1200
192.168.1.7 0:11:32:48:bf:e7 UHLWIi 6 75 en0 1184
192.168.1.137/32 link#7 UCS 1 0 en0 !
192.168.1.137 28:cf:e9:18:7:13 UHLWI 0 1 lo0
192.168.1.167 70:70:d:14:48:12 UHLWIi 1 11 en0 1195
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 4 en0 !
224.0.0/4 link#7 UmCS 1 0 en0 !
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
255.255.255.255/32 link#7 UCS 0 0 en0 !

Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UHL lo0
fe80::%lo0/64 fe80::1%lo0 UcI lo0
fe80::1%lo0 link#1 UHLI lo0
fe80::%awdl0/64 link#11 UCI awdl0
fe80::3895:61ff:fedf:43c8%awdl0 3a:95:61:df:43:c8 UHLI lo0
fe80::%utun0/64 fe80::b4f3:e489:7c5b:9264%utun0 UcI utun0
fe80::b4f3:e489:7c5b:9264%utun0 link#13 UHLI lo0
fe80::%utun1/64 fe80::6e62:86ea:6369:3d08%utun1 UcI utun1
fe80::6e62:86ea:6369:3d08%utun1 link#14 UHLI lo0
ff01::%lo0/32 ::1 UmCI lo0
ff01::%awdl0/32 link#11 UmCI awdl0
ff01::%utun0/32 fe80::b4f3:e489:7c5b:9264%utun0 UmCI utun0
ff01::%utun1/32 fe80::6e62:86ea:6369:3d08%utun1 UmCI utun1
ff02::%lo0/32 ::1 UmCI lo0
ff02::%awdl0/32 link#11 UmCI awdl0
ff02::%utun0/32 fe80::b4f3:e489:7c5b:9264%utun0 UmCI utun0
ff02::%utun1/32 fe80::6e62:86ea:6369:3d08%utun1 UmCI utun1

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

[Vitaly]

Karpion, вот что сегодня обнаружилось:
при подключенном VPN если я делаю трассировку сервера с openvpn, то пакеты идут не через VPN, и виден ip от моего провайдера.

~ » traceroute 78.XX.XX.19                                                                                                          
traceroute to 78.XX.XX.19 (78.XX.XX.19), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  1.746 ms  0.941 ms  1.047 ms
 2  85.XX.XX.1 (85.XX.XX.1)  2.779 ms  2.110 ms  2.622 ms
 3  * * *

При трассировке другого ресурса, пакеты идут через openvpn.
Т.е. при обращении к серверу-2 (где Mongo и проч.), всё ок, маршрутизация правильная через сервер-1 (с openvpn) и мой ip определяется как ip-адрес openvpn-сервера (78.XX.XX.19).
Но почему сервер-1 с openvpn (78.XX.XX.19) видит мой ip не как 78.XX.XX.19, а как ip от провайдера?

traceroute ya.ru
traceroute to ya.ru (87.250.250.242), 64 hops max, 52 byte packets
 1  10.8.0.1 (10.8.0.1)  49.248 ms  48.095 ms  48.284 ms
 2  static.1.XX.XX.78.clients.your-server.de (78.XX.XX.1)  49.483 ms  49.439 ms  50.649 ms
 3  core24.fsn1.hetzner.com (213.239.229.69)  48.905 ms
    core23.fsn1.hetzner.com (213.239.229.65)  50.174 ms
    core24.fsn1.hetzner.com (213.239.229.69)  48.273 ms
 4  core4.fra.hetzner.com (213.239.229.73)  125.631 ms
    core1.fra.hetzner.com (213.239.229.77)  53.272 ms  53.503 ms
 5  core8.fra.hetzner.com (213.239.245.126)  53.957 ms  55.444 ms
    core8.fra.hetzner.com (213.239.245.86)  53.646 ms
 6  fra1-b1-xe-0-1-3.yndx.net (5.45.200.40)  53.449 ms  53.983 ms  53.648 ms
 7  ya.ru (87.250.250.242)  78.497 ms  78.351 ms  77.743 ms

Вот таблица маршрутизации:

netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.8.0.5           UGSc          103       21   utun2
default            192.168.1.1        UGSc            1        0     en0
10.8.0.1/32        10.8.0.5           UGSc            0        0   utun2
10.8.0.5           10.8.0.6           UHr            26        0   utun2
78.XX.XX.19/32     192.168.1.1        UGSc            4       34     en0
127                127.0.0.1          UCS             0        6     lo0
127.0.0.1          127.0.0.1          UH             36  8748657     lo0
128.0/1            10.8.0.5           UGSc            6        0   utun2
169.254            link#7             UCS             1        0     en0      !
192.168.1          link#7             UCS             5        0     en0      !
192.168.1.1/32     link#7             UCS             1        0     en0      !
192.168.1.1        a8:5e:45:29:2:78   UHLWIir         4      409     en0   1102
192.168.1.7        0:11:32:48:bf:e7   UHLWIi          4    61253     en0    318
192.168.1.11       0:15:99:a6:a3:10   UHLWI           0        0     en0   1068
192.168.1.137/32   link#7             UCS             1        0     en0      !
192.168.1.137      28:cf:e9:18:7:13   UHLWI           0        4     lo0
192.168.1.153      f0:98:9d:17:99:13  UHLWI           0       12     en0     83
192.168.1.167      70:70:d:14:48:12   UHLWIi          2     1334     en0    318
192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        5     en0      !
224.0.0/4          link#7             UmCS            2        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
224.6.7.8          1:0:5e:6:7:8       UHmLWI          0        0     en0
255.255.255.255/32 link#7             UCS             0        0     en0      !

Internet6:
Destination                             Gateway                         Flags         Netif Expire
default                                 fe80::%utun0                    UGcI          utun0
default                                 fe80::%utun1                    UGcI          utun1
::1                                     ::1                             UHL             lo0
fe80::%lo0/64                           fe80::1%lo0                     UcI             lo0
fe80::1%lo0                             link#1                          UHLI            lo0
fe80::%awdl0/64                         link#11                         UCI           awdl0
fe80::d0ba:68ff:fe4c:2af5%awdl0         d2:ba:68:4c:2a:f5               UHLI            lo0
fe80::%utun0/64                         fe80::d1a9:650d:77ab:b806%utun0 UcI           utun0
fe80::d1a9:650d:77ab:b806%utun0         link#13                         UHLI            lo0
fe80::%utun1/64                         fe80::1c41:b570:cae1:4d85%utun1 UcI           utun1
fe80::1c41:b570:cae1:4d85%utun1         link#14                         UHLI            lo0
ff01::%lo0/32                           ::1                             UmCI            lo0
ff01::%awdl0/32                         link#11                         UmCI          awdl0
ff01::%utun0/32                         fe80::d1a9:650d:77ab:b806%utun0 UmCI          utun0
ff01::%utun1/32                         fe80::1c41:b570:cae1:4d85%utun1 UmCI          utun1
ff02::%lo0/32                           ::1                             UmCI            lo0
ff02::%awdl0/32                         link#11                         UmCI          awdl0
ff02::%utun0/32                         fe80::d1a9:650d:77ab:b806%utun0 UmCI          utun0
ff02::%utun1/32                         fe80::1c41:b570:cae1:4d85%utun1 UmCI          utun1

[nApoBo3]

Потому что маршрут до него через провайдера. Иначе как вы на него попадете?

[Vitaly]

nApoBo3, точно. Но вот я подключаюсь через другой VPN и делаю трассировку. Пакеты опять почему-то идут в обход VPN:

traceroute to 78.XX.XX.19 (78.XX.XX.19), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  2.111 ms  0.960 ms  1.039 ms
 2  85.XX.XX.1 (85.249.40.1)  2.187 ms  2.376 ms  2.159 ms
 3  * * *

85.XX.XX.1 - это сеть провайдера.

А до яндекса правильный маршрут:

traceroute to ya.ru (87.250.250.242), 64 hops max, 52 byte packets
 1  10.8.0.1 (10.8.0.1)  59.271 ms  59.733 ms  59.158 ms
 2  51.XX.XX.1 (51.XX.XX.1)  59.658 ms  59.633 ms  59.031 ms
 ...

netstat -nr                                                                                                                                       vsokolov@Vitalys-MacBook-Pro
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.8.0.5           UGSc           85       42   utun2
default            192.168.1.1        UGSc            0        0     en0
10.8.0.1/32        10.8.0.5           UGSc            0        0   utun2
10.8.0.5           10.8.0.6           UHr            16        0   utun2
51.XX.XX.80/32    192.168.1.1        UGSc            1        0     en0
78.XX.XX.19/32     192.168.1.1        UGSc            1       34     en0
127                127.0.0.1          UCS             0        6     lo0
127.0.0.1          127.0.0.1          UH             36  8876745     lo0
128.0/1            10.8.0.5           UGSc            4        0   utun2
169.254            link#7             UCS             1        0     en0      !
192.168.1          link#7             UCS             5        0     en0      !
192.168.1.1/32     link#7             UCS             1        0     en0      !
192.168.1.1        a8:5e:45:29:2:78   UHLWIir         6      474     en0   1118
192.168.1.7        0:11:32:48:bf:e7   UHLWIi          4   156438     en0   1166
192.168.1.11       0:15:99:a6:a3:10   UHLWI           0        0     en0   1160
192.168.1.100      98:1:a7:10:d6:5    UHLWI           0        2     en0    932
192.168.1.106      54:26:96:d1:f4:c7  UHLWI           0        0     en0    755
192.168.1.137/32   link#7             UCS             1        0     en0      !
192.168.1.137      28:cf:e9:18:7:13   UHLWI           0        6     lo0
192.168.1.167      70:70:d:14:48:12   UHLWIi          2      227     en0    933
224.0.0/4          link#7             UmCS            2        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
224.6.7.8          1:0:5e:6:7:8       UHmLWI          0        0     en0
255.255.255.255/32 link#7             UCS             0        0     en0      !

Internet6:
...

на 51.XX.XX.80/32 и 78.XX.XX.19/32 работают openvpn-сервера, в данный момент я подключен к 51.XX.XX.80.

Отключаюсь от VPN, выполняю

sudo ifconfig en0 down && sudo route -n flush && sudo ifconfig en0 up

Результат :

78.XX.XX.19          192.168.1.1          done
route: write to routing socket: No such process
got only -1 for rlen

После этого таблица маршрутизации выглядит так:

Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc          115        0     en0
127                127.0.0.1          UCS             0        6     lo0
127.0.0.1          127.0.0.1          UH             36  8883209     lo0
169.254            link#7             UCS             1        0     en0      !
192.168.1          link#7             UCS             4        0     en0      !
192.168.1.1/32     link#7             UCS             1        0     en0      !
192.168.1.1        a8:5e:45:29:2:78   UHLWIir        34       56     en0   1187
192.168.1.7        0:11:32:48:bf:e7   UHLWIi          3      449     en0   1176
192.168.1.11       0:15:99:a6:a3:10   UHLWI           0        0     en0   1198
192.168.1.137/32   link#7             UCS             0        0     en0      !
192.168.1.167      70:70:d:14:48:12   UHLWIi          2       11     en0   1148
192.168.1.255      ff:ff:ff:ff:ff:ff  UHLWbI          0        6     en0      !
224.0.0/4          link#7             UmCS            2        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
224.6.7.8          1:0:5e:6:7:8       UHmLWI          0        0     en0
255.255.255.255/32 link#7             UCS             0        0     en0      !

Internet6:
...

И после этого маршрутизация правильная, пакеты идут через 51.XX.XX.1

traceroute to 78.XX.XX.19 (78.XX.XX.19), 64 hops max, 52 byte packets
 1  10.8.0.1 (10.8.0.1)  64.342 ms  62.760 ms  63.825 ms
 2  51.XX.XX.1 (51.XX.XX.1)  61.261 ms  64.956 ms  62.824 ms
 3  192.168.143.254 (192.168.143.254)  62.720 ms  61.876 ms  64.577 ms
...

[Karpion]

Медленно и занудно повторяю в очередной раз:

IP-адрес 78.XX.XX.19 - это адрес от провайдера; или это адрес на VPN-соединении?
Дайте мне таблицу маршрутизации до установления VPN-соединения и после.

IP-адрес на VPN-соединении можно публиковать открыто - извне он недоступен. Но можно пропускать вывод всех команд через что-то типа | sed s/81\.15\.211\./81.XX.YY./ Причём менять можно много адресов, задав много масок замены. Особенно актуально эта замена для провайдерского адреса сервера.

На VPN-соединении лусше вешать адреса типа 192.158.*.* .

[nApoBo3]

Виталий Соколов, пакеты идут в соответствии с прописанными маршрутами

0/1 10.8.0.5 UGSc 85 42 utun2
Это до яндекса
51.XX.XX.80/32 192.168.1.1 UGSc 1 0 en0
78.XX.XX.19/32 192.168.1.1 UGSc 1 34 en0
Это до ваших vpn серверов.

А вот во второй таблице я вообще не вижу ваших vpn интерфейсов, по идее она такой будет когда вы не подключены ни к одному из них.

Вы уверены, что вторую таблицу снял когда подключение актовно и роут снимали именно для этой таблицы?
Что у вас за vpn?

[Vitaly]

Karpion,
78.XX.XX.19 - ip-адрес веб-сервера
51.XX.XX.80 - ip-адрес на VPN-соединении
85.XX.XX.ХХ - ip-адрес провайдера

До подключения к VPN (51.XX.XX.80) таблица такая:

~ » netstat -nr                                                                               
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.1.1        UGSc          104        0     en0
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH            336  5257932     lo0
169.254            link#7             UCS             0        0     en0      !
192.168.1          link#7             UCS             0        0     en0      !
192.168.1.1/32     link#7             UCS             1        0     en0      !
192.168.1.1        a8:5e:45:29:2:78   UHLWIir         9       15     en0   1200
192.168.1.137/32   link#7             UCS             0        0     en0      !
224.0.0/4          link#7             UmCS            1        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
255.255.255.255/32 link#7             UCS             0        0     en0      !

Подключаюсь к VPN (51.XX.XX.80), всё в порядке, всё работает корректно

~ » netstat -nr                                                                                     
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.8.0.5           UGSc          132        0   utun1
default            192.168.1.1        UGSc            7        0     en0
10.8.0.1/32        10.8.0.5           UGSc            0        0   utun1
10.8.0.5           10.8.0.6           UHr            20        0   utun1
<b>51.XX.XX.80/32    192.168.1.1        UGSc            1        0     en0</b>
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH            334  5304842     lo0
128.0/1            10.8.0.5           UGSc            6        0   utun1
169.254            link#7             UCS             0        0     en0      !
192.168.1          link#7             UCS             2        0     en0      !
192.168.1.1/32     link#7             UCS             1        0     en0      !
192.168.1.1        a8:5e:45:29:2:78   UHLWIir         4       61     en0   1179
192.168.1.7        0:11:32:48:bf:e7   UHLWIi          3     1636     en0    779
192.168.1.137/32   link#7             UCS             1        0     en0      !
192.168.1.137      28:cf:e9:18:7:13   UHLWI           0        1     lo0
192.168.1.167      70:70:d:14:48:12   UHLWIi          2      106     en0    773
224.0.0/4          link#7             UmCS            1        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
255.255.255.255/32 link#7             UCS             0        0     en0      !

traceroute:

1  10.8.0.1 (10.8.0.1)  62.132 ms  60.107 ms  58.605 ms
 2  <b>51.XX.XX.1</b> (51.XX.XX.1)  58.053 ms  58.082 ms  58.230 ms

Затем я отключаю VPN (51.XX.XX.80), подключаюсь к другому (78.ХХ.ХХ.19), и опять подключаюсь к первому VPN (51.XX.XX.80).
Вот тут начинается проблема.

~ » netstat -nr                                                                                     
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
0/1                10.8.0.5           UGSc           94        0   utun1
default            192.168.1.1        UGSc            3        0     en0
10.8.0.1/32        10.8.0.5           UGSc            0        0   utun1
10.8.0.5           10.8.0.6           UHr            25        0   utun1
<b>51.ХХ.ХХ.80/32    192.168.1.1        UGSc            1        0     en0
78.ХХ.ХХ.19/32     192.168.1.1        UGSc            1        0     en0</b>
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH            341  5330412     lo0
128.0/1            10.8.0.5           UGSc            7        0   utun1
169.254            link#7             UCS             0        0     en0      !
192.168.1          link#7             UCS             3        0     en0      !
192.168.1.1/32     link#7             UCS             1        0     en0      !
192.168.1.1        a8:5e:45:29:2:78   UHLWIir         6      203     en0   1198
192.168.1.7        0:11:32:48:bf:e7   UHLWIi          3     2572     en0    547
192.168.1.100      link#7             UHLWI           0        1     en0      !
192.168.1.137/32   link#7             UCS             1        0     en0      !
192.168.1.137      28:cf:e9:18:7:13   UHLWI           0        4     lo0
192.168.1.167      70:70:d:14:48:12   UHLWIi          2      164     en0    541
224.0.0/4          link#7             UmCS            1        0     en0      !
224.0.0.251        1:0:5e:0:0:fb      UHmLWI          0        0     en0
255.255.255.255/32 link#7             UCS             0        0     en0      !

И теперь, запуская трассировку до 78.ХХ.ХХ.19,
пакеты идут через сеть провайдера, а не через VPN:

1  192.168.1.1 (192.168.1.1)  1.716 ms  1.156 ms  1.045 ms
 2  <b>85.XX.XX.1</b> (85.XX.XX.1)  2.146 ms  2.824 ms  3.122 ms

[Vitaly]

nApoBo3, Я ещё раз повторил всё сначала и опубликовал результаты.
Использую openvpn

[nApoBo3]

78.ХХ.ХХ.19 это одновременно и веб сервер и VPN? Последняя таблица марштуризации, какие подключения активны?

[Vitaly]

nApoBo3, да, на 78.ХХ.ХХ.19 работает и веб-сервер, и openvpn-сервер тоже.
Последняя таблица маршрутизации снята, когда я подключен по VPN к 51.XX.XX.80.

[nApoBo3]

Почему в первом случае вы обращаетесь к 51.XX.XX.1, а во втором к 78.ХХ.ХХ.19?
Трафик до:
51.ХХ.ХХ.80/32
78.ХХ.ХХ.19/32
При наличии тунелей в любом случае будет идти через интернет, а не через тунели, иначе у вас тунели работать не будут.

Answer 2

[Karpion]

Я так понял, что есть два компьютера, между которыми есть VPN-соединение. Т.е. у них есть IP-адреса от провайдеров; и IP-адреса от VPN-соединения.
И с одного - идёт обращение на второй.

В простейшем случае:

1. Если первый компьютер обращается к VPN-IP-адресу второго - то обращение идёт через VPN; источник = VPN-IP-адрес первого компьютера.
   
2. Если первый компьютер обращается к провайдерскому IP-адресу второго - то обращение идёт через Интернет; источник = провайдерский IP-адрес первого компьютера; это так потому. Это так потому, что иначе - IP-пакеты, порождаемые VPN, не дойдет до второго компьютера как положено.
   

Разъясните фразу "Захожу на сайт, работающий на сервере-2" - буду думать дальше.

Чтобы какие-то сервисы были доступны только с VPN - проще всего блокировать их порты (сами определяйте, какие) на физическом интерфейсе. Если неясно - спрашивайте.

Comments

[Vitaly]

Да, у меня 2 сервера в разных странах.
На сервере-1 среди прочего работает openvpn-сервер.
На сервере-2 apache, MongoDB, PostgreSQL и т.д.

Начальная цель была заблокировать порты MongoDB, PostgreSQL, чтобы доступ к ним был открыт только внутри VPN, т.е. для ip-адреса сервера-1.
Я добавил ip-адрес сервера-1 в iptables сервера-2. Подключился к vpn c ноутбука, проверяю подключение — не пускает. Начал смотреть лог и обнаружил, что ip моего ноута с vpn на сервере-2 определился не как ip openvpn-сервера (как должно быть), а как ip моего провайдера.

Выяснилось, что проблема в таблице роутинга. Так что сейчас пытаюсь разобраться, как указать default route

[Karpion]

Манипуляции с default route Вам не помогут. Скорее Вы лишитесь доступа вообще.

Фраза "для ip-адреса сервера-1" показывает, что Вы невнимательно прочитали то, что я Вам пишу. У обоих серверов - по два IP-адреса: один от провайдера, второй для VPN (и ещё есть третий = 127.0.0.1/8).

Если MongoDB и PostgreSQL слушают провайдерский IP-адрес (принимают соединения на провайдерском IP-адресе) - то никакой VPN их не скроет от внешнего доступа. Пока Вы это не поймёте - Вы не сможете настроить систему.
Представьте себе, что у Вас есть некое здание, в котором есть ценные вещи. Чтобы защитить их - Вы прорыли подземный туннель в это здание из своего дома. Ну и фигли толку, если дверь в здание всё равно открыта? Максим - никто не видит, как Вы туда ходите; не видят, что Вы туда/оттуда носите. Но посторонние всё равно могут зайти.
Вам надо в iptables запретить обращения к этим сервисам (к их портам), приходящие через провайдера (т.е. не через VPN).

[Vitaly]

Karpion,

Если MongoDB и PostgreSQL слушают провайдерский IP-адрес (принимают соединения на провайдерском IP-адресе) - то никакой VPN их не скроет от внешнего доступа

В iptables у меня есть правило для Mongo:
-A INPUT -s <ip> -p tcp --dport 27017 -j ACCEPT,
где ip — это ip-адрес сервера-1, который я получаю на клиентской машине, подключаясь к VPN.
Стандартная политика для INPUT — DROP. Т.е. тут всё ок.

Проблема в другом: периодически я с этой клиентской машины на MacOS подключаюсь-отключаюсь от VPN, и в нужный момент, когда надо подключиться и зайти в MongoDB Compass через VPN, оказывается, что маршруты на MacOS не через openvpn-сервер. Приходится обнулять таблицу маршрутизации, переподключаться к VPN и только тогда я могу зайти в MongoDB Compass.

[nApoBo3]

Виталий Соколов,
есть один вариант, при котором у вас остаются публичными адреса, но при этом можно получать защищенный доступ прямо по ним, ipSec.
Вам VPN вообще зачем? Нарисуйте схему, сервера, публичные адреса, туннели, приватные адреса в туннелях, сервисы.

[Vitaly]

nApoBo3, VPN я использую для того, чтобы во-первых, пользоваться гео-ориентированными сервисами, которые закрыты для ip-адресов других стран, а во-вторых, для обеспечения безопасности своих сервисов (чтобы доступ к бд и проч. был только через VPN).
Как высвободится чуть времени, я загружу схему

[nApoBo3]

Если вы хотите обезопасить ваши ресурсы с помощью туннеля, то почему вы обращаетесь к ним по публичным адресам?
В таком случае ваши ресурсы должны быть закрыты для доступа по публичным адресам и доступны только по приватным( туннельным ) адресам.