Como fazer pacotes de saída do Apache através de uma determinada interface de rede quando conectado à VPN?

Question

Eu tenho um servidor apache que funciona perfeitamente até que eu me conecte à VPN e, em seguida, todas as conexões para o tempo limite do servidor.

Agora, no meu entender, o problema é que tun0 se torna a interface de saída padrão, portanto o apache fica confuso quanto ao envio de pacotes, então tentei corrigi-lo usando grupos de controle marcando pacotes saindo do apache e redirecionando-os por meio de eth0 como descrito nesta resposta SU impressionante , mas não funciona mais depois que eu atualizei meu sistema operacional Ubuntu para a versão 16.04 . Este é o meu diagrama de rede:

E aqui estão os detalhes da minha rede:

me@mypc:~$ ip route list
0.0.0.0/1 via 10.132.1.5 dev tun0 
default via 192.168.0.1 dev eth0  proto static  metric 100 
10.132.1.1 via 10.132.1.5 dev tun0 
10.132.1.5 dev tun0  proto kernel  scope link  src 10.132.1.6 
123.4.5.6 via 192.168.0.1 dev eth0 
234.5.6.7 via 192.168.0.1 dev eth0 
128.0.0.0/1 via 10.132.1.5 dev tun0 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.6  metric 100 

me@mypc:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:cc:a9:b3:c9:41  
          inet addr:192.168.0.6  Bcast:192.168.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:864897 errors:0 dropped:0 overruns:0 frame:0
          TX packets:467142 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1088053099 (1.0 GB)  TX bytes:220201868 (220.2 MB)
          Interrupt:17 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          ...

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:10.132.1.6  P-t-P:10.132.1.5  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:46622 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14950 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:60587170 (60.5 MB)  TX bytes:1396546 (1.3 MB)

Eu fiz mais testes e descobri que, se adicionar essa regra de roteamento:

sudo route add -host 123.4.5.6 gw 192.168.0.1

Eu me conecto ao servidor a partir de dispositivos conectados ao meu roteador usando o roteador ip 123.4.5.6 , mas não de qualquer outro endereço IP.

E depois de configurar os grupos de controle no apache e tentar o seguinte comando:

sudo cgexec -g net_cls:novpn wget http://www.whatsmyip.org/

e verificando o ip na pagina da web baixada seria meu ip do roteador 123.4.5.6 e não o meu vpn ip 10.132.1.6 .

Então eu acho que a solução de grupos de controle funciona de alguma forma, mas não com o apache e os pacotes de entrada estão sendo recebidos com sucesso pelo apache, mas nada está saindo.

Como posso configurar o apache para usar eth0 para enviar pacotes em vez de tun0 ?

    

Answer 1

Então você precisa dos dois gateways padrão; então a maneira de fazer isso, então, é com regras de rota:

1) Adicione um IP secundário à eth0 - ex .: 192.168.1.7 e reinicie o apache (parece que sua configuração é listen 0.0.0.0:80 , então você só precisa reiniciar o apache para que ele ouça o novo IP.

2) Altere as regras Nat no seu roteador para enviar o tráfego para este IP:

3) Criar uma nova rota padrão em uma tabela de rotas secundárias permite nomear a tabela 'apache':

echo "1 apache" >> /etc/iproute2/rt_tables

4) Adicione uma rota padrão a esta tabela através do seu roteador local.

ip route add default via 192.168.0.1 dev eth0 table apache

5) Finalmente, você precisa de uma regra para definir qual tráfego deve usar a tabela de rotas do apache.

ip rule add from 192.168.0.7 table apache

192.168.0.7 é um IP secundário e o Apache é o único processo que o utiliza, essa regra deve corresponder apenas ao tráfego que sai do apache em resposta a solicitações da web. Isso garantirá que somente esse tráfego específico será usado na nova tabela de rotas e não irá mexer com o tráfego da VPN ou com o comportamento de roteamento atual.

observe que os comandos ip não persistem após a reinicialização. Para torná-los persistentes, adicione-os à sua interface para criar scripts para serem executados toda vez que o laptop for reinicializado.

P. Saindo da minha velha resposta e fiz isso como uma nova resposta, pois esta é uma solução muito diferente.

    

Answer 2

Gerenciar 2 rotas padrão e obter algum tráfego para ir através de um e alguns para ir através do outro é uma grande dor e eu recomendo que você evite, se possível. Se você não quiser acessar a internet através da VPN, sua configuração pode ser bastante simplificada, o que resolveria os problemas. Você realmente precisa acessar a internet através da VPN? também o que é o significado de 10.132.1.5 Eu não entendo porque o seu uso para rotear para outros hosts em 10.132.1.x? você já tem um IP nessa sub-rede 10.132.1.xe deve estar conectado diretamente.

Se você não quiser acessar a Internet através da VPN e não precisar rotear via 10.32.1.5, você pode simplificar sua tabela de roteamento para:

default via 192.168.0.1 dev eth0  proto static  metric 100 
10.132.1.0/24 dev tun0  proto kernel  scope link  src 10.132.1.6 
169.254.0.0/16 dev eth0  scope link  metric 1000 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.6     metric 100 

O que também resolverá o problema do apache. Por que apenas essas rotas? em primeiro lugar:

10.132.1.0/24 dev tun0  proto kernel  scope link  src 10.132.1.6 

deve ser a única rota que você precisa para chegar a todos os hosts do outro lado da vpn. Como esta rota corresponde a 10.232.1.0 - 10.232.1.254 se houver outro endereço 10.xxx na rede vpn, você pode ampliar a rota para 10.0.0.0/8 Se você não entende o que os / 8/24 bits significam sugiro que você leia O que é a "barra" após o IP? / a> ou google para "notação CIDR". fará com que o bit / 32/1 faça mais sentido.

essas rotas antigas juntas definem sua rota padrão via VPN

0.0.0.0/1 via 10.132.1.5 dev tun0 
128.0.0.0/1 via 10.132.1.5 dev tun0

A divisão em duas rotas (uma para a primeira metade da Internet e a segunda para o restante) significa que elas têm maior prioridade porque são mais específicas que a sua rota padrão:

default via 192.168.0.1 dev eth0  proto static  metric 100 

O problema é que agora você precisa incluir explicitamente rotas que são ainda mais específicas, para forçar o tráfego através do seu roteador local (192.16.8.0.1).

123.4.5.6 via 192.168.0.1 dev eth0 
234.5.6.7 via 192.168.0.1 dev eth0 

Sem a rota padrão via VPN, essas rotas não são necessárias. Se você precisar rotear o tráfego via 10.232.1.5 e precisar manter os conjuntos de rotas padrão, eu recomendaria usar regras de rota em vez de substituir a rota padrão. As regras de roteamento são mais flexíveis, mas como você faz isso é para combinar o IP de origem com o gateway padrão, portanto todo o tráfego proveniente do seu VPN IP (10.1.232.6) vai para a rota padrão da VPN e todo o tráfego proveniente do seu IP local (192.168. 0.6) usa seu ISP como a rota padrão. consulte link para obter um guia sobre como fazer isso.

    

Answer 3

Basta dizer ao apache para ouvir em vários endereços IP.

Acho que você vai querer ter essas linhas na sua configuração.

Listen 192.168.0.6:80
Listen 10.132.1.6:80

Isso diz ao apache para "ligar" a porta 80 em cada um desses endereços IP. Se você estiver usando hosts virtuais, também precisará adicionar essas linhas a suas configurações.

Sidenote

Se você não estiver usando um, recomendo usar um IP estático em eth0 e no servidor VPN.

Se você não conseguir configurar um IP estático na VPN, há soluções alternativas que você pode fazer. Um poderia ser gerar as entradas Listen relevantes depois de se conectar à VPN. Ou talvez haja uma solução limpa que use nomes de host (se você tiver um servidor DNS).

Documentação oficial:

• Documentação do Apache (bind)