Ajuda de roteamento por favor, baseada em políticas?

0

Meu roteador doméstico é uma caixa Arch linux personalizada. Para alguma privacidade / segurança adicional, eu configurei como um cliente OpenVPN para um servidor OpenVPN, rodando em um VPS que eu operei. Todo o tráfego da minha casa passa por este túnel VPN 24/7. Esta configuração funciona perfeitamente.

Ocasionalmente, eu gostaria que algum tráfego ignorasse o túnel VPN e usasse minha conexão regular não VPN. Os endereços IP de destino são numerosos e variados, portanto, não é possível simplesmente codificar rotas estáticas.

Em vez disso, pensei em configurar uma instância do servidor openvpn no roteador, disponível para clientes na LAN, e depois usar o roteamento baseado em diretivas para rotear todo o tráfego dessa sub-rede VPN (de clientes conectados) diretamente pela conexão com a Internet. , ignorando o túnel pelo qual todo o tráfego da Internet passa. Dessa forma, os clientes da minha rede doméstica poderiam se conectar a essa VPN interna e acessar a Internet sem passar pelo túnel VPN do roteador.

Isso parece viável? Estou correto em pensar que eu poderia usar o roteamento baseado em fonte através de uma tabela de roteamento separada para ignorar o túnel vpn do cliente do roteador? Quaisquer armadilhas ou detalhes (relacionados ao iptables, ou tabelas de roteamento) para estar ciente de fazer isso funcionar?

Obrigado antecipadamente.

    
por archie 25.02.2018 / 17:58

2 respostas

0

Se eu entendi corretamente, a operação normal de um host na sua rede é apenas usar a Internet com seu DHCP, ou a configuração da LAN fornecida da mesma forma, e sua rota padrão está fora do serviço VPN, digamos interface tun0

No entanto, ocasionalmente, você não deseja usar a rota tun0 padrão para atividades de rede em um ou mais hosts. Em vez de desligar o serviço VPN para toda a sua rede, você propõe estabelecer um túnel VPN do host LAN para seu servidor linux, digamos tun1 , com sua própria sub-rede, digamos subnetB , diferente do host LAN comum rede, digamos subnetA . Você gostaria de ter o tráfego de subnetA padrão roteado por tun0 , mas o tráfego da% localsubnetB da VPN local para não sair pelo túnel, mas passar por eth0 , untunnelled.

Sugiro, em vez de criar uma rota de política baseada na origem com base em subnetA ou subnetB , que você use a interface de entrada para atribuir a política: Entrada de tráfego em eth1 sai em tun0 . A entrada de tráfego em tun1 sai em eth0 .

    
por 26.02.2018 / 05:12
0

Então, para acompanhar, tive sucesso seguindo meu plano inicial.

Eu configurei um servidor openvpn no roteador, acessível somente a partir da LAN local. Se um cliente em minha rede local deseja acessar a Internet e ignorar a conexão vpn'd que o roteador normalmente roteia todo o tráfego interno para a Internet, ele se conecta a essa VPN interna. Este servidor vpn está configurado para distribuir endereços IP estáticos com base no certificado do cliente. Em seguida, o script cl-connect.sh cria uma tabela de roteamento separada e regras de roteamento para que os endereços IP predeterminados específicos atribuídos aos clientes na VPN interna sejam roteados por meio de uma tabela de roteamento alternativa, que informa a todas essas conexões a saída para a Internet usando não a interface tun0 de todo o roteador, mas a interface eth0 unvpn-d que se conecta diretamente ao meu ISP. Quando os clientes da rede local se desconectam, o script cl-disconnect.sh também exclui as rotas.

Desta forma, todo o tráfego da minha rede doméstica ainda vai para a Internet mais ampla através do roteador e sua interface tun0 para a VPN do roteador, por padrão. Mas os clientes que se conectam a este novo servidor vpn interno têm seu tráfego roteado para a Internet, ignorando a VPN em todo o roteador e com o endereço IP atribuído pelo meu provedor.

Eu acho que me pergunto se de alguma forma usando o openvpn é um exagero, e uma configuração simples do servidor proxy (squid?) pode ser menos sobrecarga para o roteador. Mas, no entanto, isso está funcionando. Obrigado a todos que entraram na conversa.

    
por 03.03.2018 / 18:16