Не удается подключиться к sshd через vpn

У меня есть VPS под управлением Centos 6.8, на котором я установил SoftEther VPN-сервер с локальным мостом.

Диапазон IP-адресов VPN: 192.168.86.0/24. IP-адреса VPN клиента предоставляются DHCP-сервером SoftEther VPN Server. Для локального моста SoftEther используется виртуальный сетевой адаптер, потому что я хотел бы получить доступ к некоторым сервисам на VPS через VPN (в SoftEther это невозможно без локального моста). Адрес шлюза VPN по умолчанию - 192.168.86.3.

VPS имеет общедоступный IPv4-адрес на интерфейсе eth0, плюс я создал псевдоним eth0: 0 с адресом IPv4 192.168.86.2 (это выходит за пределы диапазона, предоставляемого DHCP для VPN, и отличается от шлюза VPN по умолчанию).

Когда я подключаюсь с ПК с Windows, все вроде как надо. Я могу пинговать как 192.168.86.3 (который является сетевым интерфейсом VPN-сервера SoftEther для подключенных VPN-клиентов), так и 192.168.86.2 (который находится вне VPN-сервера, являясь «физическим» сетевым интерфейсом на VPS).

Однако я не могу подключиться к какой-либо службе, работающей на VPS, через VPN-соединение - ни SSH на порту 22 (ни один из двух адресов, .2 или .3), и я не могу подключиться к простому веб-серверу, работающему как root на порту 80. на VPS (с использованием nodejs). Однако прямые подключения (к общедоступному IPv4-адресу) работают.

Что именно я пропустил? Следует ли мне изучить конфигурацию SSHD для интерфейсов, или проблема может быть в настройке iptables, или это нужно исправить в SELinux? Боюсь, я понятия не имею, где искать проблему.

Единственное, в чем я уверен, это то, что это не имеет прямого отношения к серверу SoftEther VPN - до того, как я активировал функцию локального моста, я не мог проверить связь IP-адресов VPN, кроме шлюза по умолчанию, теперь локальный псевдоним 192.168.86.2 стал видимым и отвечает на эхо-запросы.

ip addr на VPS возвращает это:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:00:46:07 brd ff:ff:ff:ff:ff:ff
    inet 46.28.111.205/24 brd 46.28.111.255 scope global eth0
    inet 192.168.86.2/24 brd 192.168.86.255 scope global eth0:0
    inet6 2a02:2b88:2:1::4607:1/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe00:4607/64 scope link
       valid_lft forever preferred_lft forever
4: tap_tap01: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500
    link/ether 00:ac:56:ec:e5:3c brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2ac:56ff:feec:e53c/64 scope link
       valid_lft forever preferred_lft forever

ip route на VPS возвращает это :

192.168.86.0/24 dev eth0  proto kernel  scope link  src 192.168.86.2
46.28.111.0/24 dev eth0  proto kernel  scope link  src 46.28.111.205
169.254.0.0/16 dev eth0  scope link  metric 1002
default via 46.28.111.1 dev eth0

Похоже, что VPN-сервер SoftEther не настраивает адрес IPv4 на tap_tap01 (виртуальный сетевой интерфейс SoftEther для моста). Интересно, можно выполнить эхо-запрос обоих адресов IPv4 из сеанса VPN, но сеть VPN недоступна / невидима на VPS. Что противоречит тому, что я ожидал от местного моста.

1
задан 27 October 2016 в 08:36
1 ответ

Скорее всего, вы обнаружите, что службы httpd / node, sshd и т. Д. Запускаются до сервера VPN. В этом случае службы будут привязываться только к интерфейсам, которые доступны при запуске. Вам нужно будет настроить систему для запуска служб после сервера VPN. Вы также должны убедиться, что службы настроены для привязки ко всем доступным адресам.

0
ответ дан 4 December 2019 в 05:40

Теги

Похожие вопросы