Tentando se conectar a servidores em uma lan remota com cliente vpn softether e iptables nat ip_forwarding

Question

Eu implementei um servidor vpn softether em um servidor aws conectado a outras instâncias em uma LAN. Eu posso ssh no servidor com ssh [email protected] sem problema. Eu segui este guia

Meu objetivo é permitir que eu acesse servidores aws remotos em uma LAN com ssh [email protected] ou http://hostname.domainname.com do meu laptop usando o vpn. O ssh agora está funcionando, mas não consigo descobrir como obter uma página da web. Minha razão para querer uma página web através de uma vpn é que o site é um backend de administração que eu quero limitar o acesso aos usuários provenientes dos endereços IP da vpn.

Adicionei net.ipv4.ip_forward = 1 ao sysctl e

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

route add -net 10.0.0.0/8 gw 10.0.1.10

ifconfig -a

vpn_tun0  Link encap:Ethernet  HWaddr 00:ac:a3:58:1f:78  
inet addr:10.0.1.11  Bcast:10.0.1.255  Mask:255.255.255.0
inet6 addr: fe80::2ac:a3ff:fe58:1f78/64 Scope:Link

netstat -nr

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
10.0.0.0        0.0.0.0         255.0.0.0       U         0 0          0 vpn_tun0
10.0.1.0        0.0.0.0         255.255.255.0   U         0 0          0 vpn_tun0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

no servidor no vpnserver:

DhcpTable

ID              |21
Leased at       |2015-06-08 (Mon) 08:49:46
Expires at      |2015-06-08 (Mon) 14:23:06
MAC Address     |00-AC-A3-58-1F-78
Allocated IP    |10.0.1.11
Client Host Name|Inspiron-1564

no meu laptop vpnclient

VPN Client>accountlist
AccountList command - Get List of VPN Connection Settings
Item                        |Value
----------------------------+----------------------------------------------------
VPN Connection Setting Name |my_connection
Status                      |Connected
VPN Server Hostname         |hostname.domainname.com:5555 (Direct TCP/IP Connection)
Virtual Hub                 |lan-internal
Virtual Network Adapter Name|tun0

    

Answer 1

Ok, então seguindo em link eu tenho o que pode ser uma pergunta realmente estúpida para perguntar, mas se tudo que você precisa é acesso a portas específicas, como http / https você já tentou SSH Tunneling? É muito mais fácil do que configurar uma VPN. Em última análise, você ssh de uma máquina para outra e, em seguida, faz com que a máquina de destino estabeleça uma conexão para frente com algo e faça com que essa conexão seja encaminhada de volta à sua máquina local.

Digamos que você possa acessar a parte pública (DMZ) de uma máquina AAAA que pode, por sua vez, acessar uma máquina privada BBBB e desejar se conectar a um serviço HTTPS (porta 443) e supondo que sua área de trabalho já tenha um serviço rodando em 443, então você vai ter o serviço escutar localmente em 4443.

   ssh -L4443:B.B.B.B:443 [email protected]

Em seguida, faça o login e abra um navegador local e vá para link ou, se preferir, adicione uma entrada ao arquivo de hosts, enviando 127.0. 0.1 para pretendido.vhost.name e, em seguida, vá para link

Se você realmente precisa de uma vpn, então ...

Você pode fazer ping no endereço IP dos lados local e oposto do túnel do seu laptop? Você pode fazer ping em uma máquina diferente na rede de sites oposta? Se você não pode tentar tracerout ele, e veja se você receber um eco de volta a partir dos locais locais e remotos do túnel (se não, o seu encaminhamento está errado).

Quais são os vários endereços de rede? Você pode tentar dizer rota, qual dispositivo você está esperando para enviar tráfego, caso contrário, tem que ser capaz de inferir.

Eu estava relendo isso e pensei em adicionar algumas notas que possam facilitar para qualquer um que tente seguir o que eu sugeri: -

Para tornar possível o acesso ao link e ter esse túnel, você precisa adicionar uma entrada ao seu arquivo de hosts. No linux isso é / etc / hosts no Windows é c: / windows / system32 / drivers / etc / hosts De qualquer forma você vai precisar de privilégios de administrador para salvar o arquivo (sudo para linux, abra o bloco de notas como administrador no windows). Em seguida, adicione a seguinte linha: -

127.0.0.1        intended.vhost.name

A outra coisa que mencionei foi a criação de um túnel de escuta em uma máquina, que pode perfurar um firewall. Como discutido anteriormente rodando ssh -L4443: BBBB: 443 adminuser @ AAAA irá abrir um terminal ssh na máquina AAAA, e enquanto isso, irá encapsular o tráfego da porta local (o -L) 127.0.0.1:4443 para BBBB: 443 (o 127.0.0.1 está implícito). Assumindo que sua máquina local é C.C.C.C e você deseja abrir a porta 4443 naquele IP, para que outras máquinas acessem, você pode fazer isso: -

ssh -LC.C.C.C:4443:B.B.B.B:443 [email protected]

Vale a pena notar aqui que se você adicionar um parâmetro -T, você altera o comportamento do ssh, para abrir a conexão ssl, depois o túnel e não iniciar o terminal dentro dele.

Quando eu fiz isso antes, eu configurei um usuário na máquina local (digamos tunneluser) e criei um conjunto de chaves ssh para ele em ~ tunneluser / .ssh e então assegure o arquivo ~ tunneluser / .ssh / id_rsa .pub é listado nas máquinas remotas ~ adminuser / .ssh / authorized_keys, então a conexão ssh será iniciada sem solicitar uma senha. Como um recurso de segurança, você pode configurar o tunneluser remotamente, com / bin / false como seu shell (em / etc / passwd), então a conexão falhará se você perder o parâmetro -T.

Uma maneira simples de implementar isso é incluí-lo em um script em /etc/init.d que é executado após a rede (usualling em rc3.d). Eu sugeriria uma camada de segurança (evite rodar como root) usando

sudo -u tunneluser "ssh -T -i/home/tunneluser/.ssh/id_rsa.pub -LC.C.C.C:4443:B.B.B.B:443 [email protected]"

Note, porém, que se o IP que você deseja escutar (o: 4443 listado acima) for uma 'porta privilegiada' (ou seja, entre o intervalo normalmente usado pelos serviços do sistema), será necessário executar o ssh como root , para obter permissão para ouvir lá.

Qualquer usuário de janela precisa simplesmente acessar o link e ele veria o site que estava em link .

Se a máquina no CCCC não tiver um bloqueio de serviço: 443, use isso em vez de: 4443 e link seriam equivalentes a link

Como um aparte, se a intenção for revertida, digamos que você está em uma máquina com acesso a CCCC você quer fazer um furo através da DMZ via máquina AAAA de tal forma que usuários que possam acessar BBBB, possam acessar o CCCC via túnel, sem ser capaz de acessá-lo diretamente, você usa -R em vez de -L (e o soquete de escuta está no lado remoto, em vez de local do túnel). Eu incluo -T para mostrar como é usado.

ssh -T -RB.B.B.B:4443:C.C.C.C:443 [email protected]

    

Answer 2

Não há diferença no roteamento necessário para ssh e http. Ambos estão rodando sobre TCP e não estão executando nenhum truque com o tráfego IP subjacente.

De acordo com a sua pergunta, ambos estão usando o mesmo nome de host, mas você não mencionou se esse nome de host é resolvido para apenas um ou vários endereços IP. Usando o comando telnet , você pode verificar se uma conexão pode ser estabelecida na porta 22 e na porta 80 do servidor. Ele também informará ao longo do caminho o endereço IP ao qual ele está se conectando.

A partir da pergunta, posso ver que você está executando seus servidores ssh e http no mesmo nome de host do seu servidor VPN. Isso pode ser um problema. O problema real aqui não é tanto que eles estejam usando o mesmo nome de host, mas que estejam usando o mesmo endereço IP. Mesmo se você usasse nomes de host diferentes apontando para o mesmo endereço IP, ainda assim poderia ser um problema, mas os diferentes nomes de host poderiam obscurecer a origem do problema.

A razão pela qual pode ser um problema conectar-se a um serviço no mesmo IP que o servidor VPN tem a ver com o roteamento. O problema é que, se uma entrada da tabela de roteamento direcionando o tráfego através da VPN também cobrir o endereço IP do servidor VPN, os pacotes para o servidor VPN não serão enviados pela rede, mas sim pela interface da VPN. Isso introduzirá um loop de roteamento, onde cada vez que um pacote passa pelo loop, ele será criptografado mais uma vez e ficará um pouco maior, mas não chegará mais perto do destino.

Uma solução que algumas soluções VPN usam para evitar isso é que uma entrada de tabela de roteamento cobrindo apenas o IP do servidor VPN é criada antes de fazer qualquer outra alteração. Dessa forma, o tráfego para o servidor VPN nunca passará pela VPN. Mas o tráfego para qualquer outro serviço hospedado no mesmo IP também nunca passará pela VPN.

A solução mais simples para isso é usar dois endereços IP diferentes para acessar VPN e outros serviços hospedados na mesma caixa. Normalmente, um servidor VPN terá endereços IP suficientes atribuídos a ele, ou seja, outro endereço IP, que pode ser usado para esse fim.

Então, por que funcionaria para ssh e não http? As informações na sua pergunta apontam para um possível motivo.

Você menciona que deseja limitar o serviço http a ser acessado apenas pelos usuários que se conectarem de um endereço IP da VPN. Se você já tiver esses filtros, isso pode ser o motivo. A conexão simplesmente não está passando pela conexão VPN e, portanto, fica bloqueada pelos filtros. A razão pela qual isso funcionaria ao usar ssh em vez de http poderia ser que o sshd seja configurado para permitir conexões de qualquer endereço IP e não apenas do intervalo de VPN.

Outra explicação possível é que os serviços ssh e http não estão vinculados ao mesmo endereço IP. Talvez ssh esteja vinculado a qualquer endereço e http esteja ligado a apenas um endereço específico.

Essas duas razões não são de forma alguma uma lista completa de explicações possíveis, mas simplesmente aquelas que parecem mais prováveis, dadas as informações em sua pergunta.