Eu tenho um VPS rodando o Centos 6.8 onde eu instalei o servidor do SoftEther VPN com uma ponte local.
O intervalo de VPN VPN é 192.168.86.0/24. Os endereços IP da VPN do cliente são fornecidos pelo servidor DHCP do SoftEther VPN Server. Há adaptador de rede virtual usado para a ponte local do SoftEther, porque eu gostaria de acessar alguns serviços no VPS através da VPN (no SoftEther isso não é possível sem ponte local). O endereço do gateway padrão da VPN é 192.168.86.3.
O VPS tem um endereço IPv4 público na interface eth0, além de ter criado um alias eth0: 0 com o IPv4 addr 192.168.86.2 (isso está fora do intervalo fornecido pelo DHCP da VPN e difere do gateway padrão da VPN). / p>
Quando eu conecto a partir do Windows PC, tudo parece estar certo. Eu posso pingar tanto o 192.168.86.3 (que é a interface de rede do servidor SoftEther VPN para clientes VPN conectados) quanto o 192.168.86.2 (que está fora do servidor VPN, sendo uma interface de rede "física" no VPS).
No entanto, não consigo me conectar a nenhum serviço em execução no VPS por meio da conexão VPN - nem SSH na porta 22 (nenhum dos dois endereços, .2 nem .3), nem posso conectar a um servidor da web simples como raiz na porta 80 no VPS (usando nodejs). Conexões diretas (para o endereço IPv4 público), no entanto, funcionam.
O que exatamente eu perdi? Eu deveria olhar para a configuração do SSHD para as interfaces, ou o problema poderia estar na configuração do iptables, ou é algo para ser corrigido no SELinux? Receio não ter ideia de onde procurar o problema.
A única coisa que acredito ter certeza é que isso não está diretamente relacionado ao servidor SoftEther VPN - antes de ativar a função de ponte local, eu não conseguia pingar nenhum dos endereços IP da VPN, exceto o gateway padrão, agora o alias local 192.168.86.2 tornou-se visível e responde aos pings.
ip addr no VPS retorna isso:
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 no VPS retorna isso:
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
Parece que o servidor SoftEther VPN não configura um endereço IPv4 em tap_tap01 (interface de rede virtual da SoftEther para a ponte). Curiosamente, é possível fazer ping de ambos os endereços IPv4 de dentro da sessão VPN, mas a rede VPN é inacessível / invisível no VPS. O que é contrário ao que eu esperaria da ponte local.
Você provavelmente descobrirá que os serviços httpd / node e sshd etc são iniciados antes do servidor VPN. Nesse caso, os serviços só serão vinculados às interfaces disponíveis quando forem iniciadas. Você precisará configurar o sistema para iniciar os serviços após o servidor VPN. Você também deve garantir que os serviços estejam configurados para vincular a todos os endereços disponíveis.