A conexão de saída de um cliente OpenVPN para uma LAN atrás de um servidor OpenVPN é encaminhada pelo kernel do servidor?

Question

É claro que o tráfego entre a VPN e o resto da rede está passando tun0. Para esse tráfego, FORWARDa cadeia é consultada normalmente e você pode controlar quem pode se conectar onde. Se ip_forwardnão estiver habilitado, o tráfego não será encaminhado.

Quando client-to-clientnão é usado, o tráfego entre clientes usa o mesmo caminho: aparece no sistema operacional do servidor a partir da tun0interface, roteia corretamente usando a tabela de roteamento do sistema operacional, atravessa o firewall e a única diferença é que ele decide que o destino está atrás tun0, então o pacote é saiu através dele.

Não é muito eficiente, porque o processo OpenVPN está no espaço do usuário, enquanto o tun0 está no espaço do kernel, e resulta em pelo menos duas mudanças de contexto para cada pacote.

Quando client-to-clientutilizado, porém, os pacotes entre clientes não aparecem no tun0, a cadeia de firewall do servidor FORWARDnão é consultada e o ip_forwardcontrole não influencia seu encaminhamento. O próprio processo OpenVPN se torna um roteador, com tabela de roteamento própria, independente do sistema operacional host. Você pode vê-lo com o statuscomando da interface de gerenciamento ou despejá-lo no arquivo de status. Você pode controlar rotas dentro deste "roteador" com iproutediretiva (acredito que signifique "rota interna"), que só é válida no client-config-dirarquivo do cliente ou na configuração dinâmica gerada por script.

O mais fácil é não pensar na VPN como algo especial. Uma vez estabelecido o túnel, esqueça, ele agora é apenas uma interface regular adicional em cada computador (servidor e clientes), com todas essas interfaces conectadas a algum roteador simples e regular. E considere o roteamento e o firewall usuais.

Finalmente percebi que você fez ping no endereço deo próprio servidor VPNembora atribuído a outra interface. Este pacote énão será encaminhadode qualquer maneira, porque seu destino é o próprio servidor, portanto ip_forwardnão influencia como esse pacote é processado, e ele está atravessando INPUTa cadeia do firewall e a resposta será atravessada OUTPUT(por exemplo, não FORWARDa cadeia como fariam se não fossem destinadas ao próprio sistema). O pacote entrará no sistema tun0(e será visto lá), mas você não o verá eth0porque não será enviado. Será processado localmente. O mesmo se aplica às respostas.

Não importa (para o código relacionado ao roteamento) onde no sistema o endereço está atribuído (qual interface) ou qual endereço do sistema você usa para acessá-lo. O que importa é se pertence ao sistema ou não.

A questão de segurança relacionada é que algumas pessoas pensam que se vincularem o serviço a algum endereço IP atribuído a alguma interface, cortarão o acesso a esse serviço através de outras interfaces.Isto está errado.Se outros sistemas que vivem atrás de outras interfaces tiverem rota para o IP ao qual o serviço está vinculado, eles ainda assimserá capazpara acessar o serviço. Esta não é uma forma correta de proteger o serviço; configuração adequada do firewall é.

Outro problema relacionado é que algumas pessoas usam ping -I <local-address> <address-to-ping>ou até mesmo ping -I <interface> <address-to-ping>e pensam que selecionam diretamente quais pings de interface serão enviados. Novamente, isso está errado. Dessa forma, você só pode selecionar quaisEndereço de Origemos pings terão, mas não a interface para enviá-los; a interface será selecionada pelo código de roteamento estritamente de acordo com a tabela de roteamento baseada apenas no endereço de destino do pacote (presumo que nenhuma configuração de VRF ou RPDB foi feita, mas isso é algo avançado e as pessoas que o configuraram sabem sobre esse recurso de qualquer maneira ).

Answer 1