Задать вопрос

Vitaly

Комментарии

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

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

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

    @vitalysokolov Автор вопроса
    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
    Написано

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

    @vitalysokolov Автор вопроса
    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
...
    Написано

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

    @vitalysokolov Автор вопроса
    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
    Написано

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

    @vitalysokolov Автор вопроса
    Итак, клиент (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-сервер, а через провайдера.
    Написано

  • Как грамотно изолировать сервисы на linux-сервере?

    @vitalysokolov Автор вопроса
    Sanes, Алексей Черемисин Давайте прекратим эту дискуссию. Спасибо вам за советы!
    Написано

  • Как грамотно изолировать сервисы на linux-сервере?

    @vitalysokolov Автор вопроса
    Sanes, мы тоже используем git, разумеется. Просто товарищи предлагают добавить docker для deployment'а, поэтому и возник вопрос, не перебор ли запускать docker-контейнеры внутри виртуальной машины. Сервер для разработки, не продакшен, но всё равно нужно, чтобы работало быстро.
    Написано

  • Как грамотно изолировать сервисы на linux-сервере?

    @vitalysokolov Автор вопроса
    А вот, например, для веб-проекта, состоящего из нескольких микро-сервисов на python и NodeJS, использующих также PostgreSQL, MongoDB и RabbitMQ (и над которым я работаю не один, т.е. мне надо дать доступ другим программистам), подойдёт вариант выделить отдельную виртуальную машину через KVM, в которую установить debian, и там каждый сервис запускать в docker? Или это уже перебор и docker лучше не использовать?
    Написано

  • Как грамотно изолировать сервисы на linux-сервере?

    @vitalysokolov Автор вопроса
    https://habr.com/en/post/455598/
    Написано

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

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

    Каждый раз, когда такое происходит, мне приходится выполнять:
    sudo ifconfig en0 down
sudo route -n flush
sudo ifconfig en0 up


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

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

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

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

    @vitalysokolov Автор вопроса
    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.
    Написано

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

    @vitalysokolov Автор вопроса
    Да, у меня 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
    Написано

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

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

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

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

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

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

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

    @vitalysokolov Автор вопроса
    Sergey, никак не связаны и физически в разных странах
    Написано

  • Как в python проверить, пустой ли атрибут?

    @vitalysokolov Автор вопроса
    h0w4rd, ну так я и сделал. Проблема в том, что в бд записывается err: null. А я хочу, чтобы если err is None, то в бд не записывался err.
    Мне пришлось написать отдельную функцию, которая проверяет атрибуты у объекта, и, если они пустые, то не добавляет этот атрибут в объект. Но я думал, что в python есть более элегантное решение наподобие JS:
    {err && "err": err}
    , что-нибудь такое
    Написано

  • Как в python проверить, пустой ли атрибут?

    @vitalysokolov Автор вопроса
    В случае тернарного выражения атрибут все равно создается в бд со значением null
    await db[collection_name].insert_one(
    {"err": err if err else None})
    Написано

  • Почему chromium driver не завершает процесс после закрытия браузера в Selenium?

    @vitalysokolov Автор вопроса
    Действительно, quit() не помогает. Приходится его pkill'ом прибивать.
    Написано