
Observei um comportamento um tanto estranho que não consigo entender. Então configurei uma conexão OpenVPN conforme mostrado no gráfico abaixo. (É uma configuração TUN e cliente para cliente). Meus pensamentos estão direcionados para a rota do ping neste cenário: minha conexão openvpn
from client: 192.168.200.102 to LAN: 10.198.0.16
Em geral, não é nenhuma surpresa que este ping seja bem-sucedido, mas para minha compreensão, caso eu altere minhas configurações de iptables no servidor para
-P FORWARD DROP
e então até
net.ipv4.ip_forward = 0.
o tráfego nunca deve chegar ao destino com as configurações acima. Embora o tráfego seja bem-sucedido, ele nunca chega à interface LAN. O problema é que não consigo ver o tráfego (executando o analisador de pacotes de rede de dados tcpdump) chegando à interface LAN eth0 10.198.0.16. Mais parece que a interface tun está respondendo automaticamente ao tráfego, como se o IP da LAN fosse vinculado à interface tun, veja abaixo:
sudo tcpdump -i tun0 tcpdump: 16:34:21.391381 IP 192.168.200.102 > 10.198.0.16: ICMP echo request, id 14, seq 1885, length 64 16:34:21.391514 IP 10.198.0.16 > 192.168.200.102: ICMP echo reply, id 14, seq 1885, length 64
O que está acontecendo aqui? Pelo que entendi, a solicitação vinda do Cliente vai para a interface tun do servidor e será eventualmenteENVIADOpelo kernel para eth0, estou certo? Isso normalmente seria visível executando: sudo tcpdump -i tun0
ou sudo tcpdump -i eth0
?
O motivo pelo qual sou tão exigente com relação a isso é que considero um risco à segurança se não houver uma maneira de implementar regras para impedir que os clientes acessem a LAN no servidor. O que estou perdendo aqui, existe um processo OpenVPN que encaminha pacotes para a interface eth0 (conforme planejado para configuração cliente a cliente)?
Para que você possa me ajudar melhor com meu problema, anexei alguns diagnósticos abaixo.
Para o servidor
ip addr
`1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether b8:27:eb:5c:a6:e6 brd ff:ff:ff:ff:ff:ff inet 10.198.0.16/24 brd 10.198.0.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::ba27:ebff:fe5c:a6e6/64 scope link valid_lft forever preferred_lft forever 3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether b8:27:eb:09:f3:b3 brd ff:ff:ff:ff:ff:ff 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 192.168.200.1/24 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::87cd:fedd:92fc:cde/64 scope link stable-privacy valid_lft forever preferred_lft forever
`
ip route
default via 10.198.0.1 dev eth0 proto static 10.198.0.0/24 dev eth0 proto kernel scope link src 10.198.0.16 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.1 192.168.178.0/24 via 192.168.200.1 dev tun0 scope link
server openvpn.conf
tls-server mode server dev tun local 10.198.0.16 proto tcp-server port 1234 user openvpn group openvpn ca /etc/openvpn/cacert.pem cert /etc/openvpn/servercert.pem key /etc/openvpn/serverkey dh /etc/openvpn/dh2048.pem ifconfig-pool 192.168.200.2 192.168.200.103 255.255.255.0 client-config-dir /etc/openvpn/ccd ifconfig 192.168.200.1 255.255.255.0 keepalive 10 120 comp-lzo client-to-client push "topology subnet" topology "subnet" log /var/log/openvpn.log
Para o cliente
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 38:af:d7:a0:52:ec brd ff:ff:ff:ff:ff:ff 3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:28:f8:8d:1c:6f brd ff:ff:ff:ff:ff:ff inet 192.168.178.79/24 brd 192.168.178.255 scope global dynamic noprefixroute wlp2s0 valid_lft 859868sec preferred_lft 859868sec inet6 2a0a:a540:d54:0:bd79:eb10:5e26:548a/64 scope global temporary dynamic valid_lft 7190sec preferred_lft 3590sec inet6 2a0a:a540:d54:0:6086:b044:dff:2694/64 scope global dynamic mngtmpaddr noprefixroute valid_lft 7190sec preferred_lft 3590sec inet6 fe80::ad5c:6e18:87fa:dff4/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100 link/none inet 192.168.200.102/24 brd 192.168.200.255 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::5dfc:6b3a:3c4d:e9a4/64 scope link stable-privacy valid_lft forever preferred_lft forever
ip route
default via 192.168.178.1 dev wlp2s0 proto dhcp metric 600 169.254.0.0/16 dev wlp2s0 scope link metric 1000 10.198.0.0/24 via 192.168.200.1 dev tun0 192.168.200.0/24 dev tun0 proto kernel scope link src 192.168.200.102 192.168.178.0/24 dev wlp2s0 proto kernel scope link src 192.168.178.79 metric 600
client openvpn.conf
dev tun client nobind remote 11.22.33.44 proto tcp port 1234 ca /etc/openvpn/cacert.pem cert /etc/openvpn/user_cert.pem key /etc/openvpn/user comp-lzo verb 3 keepalive 10 120 log /var/log/openvpn.log
ccd for client
iroute 192.168.178.0 255.255.255.0
Responder1
É claro que o tráfego entre a VPN e o resto da rede está passando tun0
. Para esse tráfego, FORWARD
a cadeia é consultada normalmente e você pode controlar quem pode se conectar onde. Se ip_forward
não estiver habilitado, o tráfego não será encaminhado.
Quando client-to-client
não é usado, o tráfego entre clientes usa o mesmo caminho: aparece no sistema operacional do servidor a partir da tun0
interface, 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-client
utilizado, porém, os pacotes entre clientes não aparecem no tun0
, a cadeia de firewall do servidor FORWARD
não é consultada e o ip_forward
controle 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 status
comando da interface de gerenciamento ou despejá-lo no arquivo de status. Você pode controlar rotas dentro deste "roteador" com iproute
diretiva (acredito que signifique "rota interna"), que só é válida no client-config-dir
arquivo 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_forward
não influencia como esse pacote é processado, e ele está atravessando INPUT
a cadeia do firewall e a resposta será atravessada OUTPUT
(por exemplo, não FORWARD
a 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á eth0
porque 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 ).