xl2tpd: Fornece conectividade VPN L2TP / IPsec a uma sub-rede inteira sem usar uma rota padrão

1

Eu configurei uma VPN L2TP / IPsec usando OpenSwan e xl2tpd usando a opção ppp "nodefaultroute". O endereço IP virtual do servidor é definido como 10.10.31.1 e aloca endereços no intervalo 10.10.31.2-254. Isso configura os links PPP entre 10.10.31.1 < - > 10.10.31.2 etc. e isso funciona bem - os hosts conectados a VPN podem se comunicar com o servidor.

Como posso configurar o link ppp para que a extremidade do servidor se pareça com todo o intervalo 10.10.0.0 em vez de apenas esse endereço IP? Espero que os clientes de conexão rotearão quaisquer solicitações para essa sub-rede por meio da interface VPN, onde o servidor poderá capturá-las e atuar como um gateway. Indo na outra direção, a opção "proxyarp" permitirá que o servidor VPN capture o tráfego de volta para os clientes VPN.

Uma solução óbvia para isso é usar o servidor VPN como a rota padrão. Eu preferiria não fazer isso, de modo que apenas o tráfego específico dessa sub-rede passe pela VPN. Isso é possível?

    
por Tom 05.12.2012 / 06:09

1 resposta

0

Como eu suspeitava o problema é que eu sou um pouco de um numpty. Caso alguém encontre essa pergunta e esteja se perguntando a mesma coisa, estas são as principais coisas que você deve saber:

nodefaultroute não entra na sua configuração do servidor VPN. É algo para um cliente PPP. Os clientes PPP são responsáveis por decidir se deve ou não criar uma rota padrão. Esta é a caixa de seleção "Enviar todo o tráfego" no iOS.

Seu cliente PPP sempre criará uma rota para o gateway remoto, além de uma rota para a sub-rede remota. Desde que você tenha o encaminhamento de IP ativado em seu servidor VPN (/ proc / sys / net / ipv4 / ip_forward = 1 mais regras iptables apropriadas no linux) seu cliente poderá enviar o tráfego para hosts na sub-rede remota.

Você deve especificar proxyarp no arquivo ppp options.xl2tpd para os hosts na LAN do servidor VPN para poder enviar o tráfego de volta aos clientes. Isso criará uma entrada na tabela arp e ativará o opção proxy_arp no kernel. Isso permite que o servidor VPN aceite pacotes em nome de clientes VPN usando sua própria interface ethernet. Se você não quiser fazer isso ou precisar cruzar roteadores, parece que colocar os clientes VPN por trás do NAT é uma solução popular, embora eu mesmo não tenha testado isso.

Use a opção ms-dns ppp para fornecer um servidor de nomes para os clientes se eles vão usar a VPN como uma rota padrão. Caso contrário, um iPad irá reclamar que não está conectado à internet. / p>     

por 09.04.2013 / 14:56