Um killswitch VPN melhor usando UFW com tabela NAT?

Question

Objetivo

Dadas as seguintes interfaces em um Raspberry Pi:

• eth0 (192.168.0.0/24) - rede privada (ou seja, NAT)
• wlan0 (192.168.10.0/24) - Rede pública com acesso à Internet (por exemplo, LAN)
• tun0 (VPN) - conexão VPN

Construa um firewall que atinja o seguinte:

• Negar todo o tráfego de entrada para: wlan0 , tun0 (bloquear conexões de entrada)
• Encaminhar todo o tráfego de saída de eth0 para tun0 (bloquear conexões "laterais"; isto é, sem acesso à LAN)
  • Se tun0 estiver inativo, NÃO permita que eth0 use wlan0 (ou seja, VPN killswitch)

Exemplo principal

Eu já vi inúmeros exemplos de "VPN killswitch" neste ponto com o UFW e todos eles compartilham uma configuração comum:

# Defaults
ufw default deny outgoing
ufw default deny incoming

# Allow local over ethernet (without VPN)
sudo ufw allow out to 192.168.0.0/24 # Allow out to LAN
sudo ufw allow in to 192.168.0.0/24 # Allow in to LAN

# Allow outgoing over ethernet to VPN
sudo ufw allow out to [VPN] port 1194 proto udp

# Allow outgoing over tun0
sudo ufw allow out on tun0 # Allow out over VPN

Fontes:

• link
• link
• link
• link

Meu exemplo de NAT (alternativo)

Concedido, no meu aplicativo, eu tenho um dispositivo intermediário (Raspberry Pi) em jogo que atua como um roteador, firewall, DNS & Servidor DHCP e cliente VPN, por isso é uma configuração ligeiramente diferente. No entanto, parece que a tabela NAT ( /etc/ufw/before.rules ) manipula as instruções ufw allow out/in to 192.168.0.0/24 e praticamente direciona todo o tráfego de saída proveniente de eth0 para tun0 (segundo item objetivo) como é:

# NAT table to "forward" private network to VPN tunnel
*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.0.0/24 -o tun0 -j MASQUERADE
COMMIT

Isso deve "encaminhar" qualquer coisa vinda da rede privada ( eth0 ) para o túnel da VPN ( tun0 ), correto? Ou eu preciso de cláusulas FORWARD aqui também?

Depois disso, não tenho certeza se há mais alguma coisa que eu precise configurar, como:

# Set defaults (also see /etc/default/ufw)
sudo ufw default deny incoming
sudo ufw default deny outgoing

# Allow incoming requests to DNS/DHCP services (UDP) on eth0 interface only (i.e. Private Network -> Pi:43,67/udp)
sudo ufw allow in on eth0 from any to any port 53,67 proto udp

# Allow incoming requests to SSH service (TCP) on eth0 interface only (i.e. Private Network -> Pi:22/tcp)
sudo ufw allow in on eth0 from any to any port 22 proto tcp

# Allow outbound on wlan0 interface for VPN traffic only (i.e. Pi -> LAN:1194)
sudo ufw allow out on wlan0 from any to any port 1194 proto udp

# Allow all outbound traffic on eth0 (i.e. Pi -> Private Network)
sudo ufw allow out on eth0

# Allow all outbound traffic on VPN tunnel only (i.e. Pi -> VPN)
sudo ufw allow out on tun0

Nos testes que fiz ( traceroute , ping , etc.) apenas com a tabela NAT, posso ver minha conexão de saída para a Internet parar no Raspberry Pi quando eu desconectar a VPN. No entanto, o que eu ainda estou tentando confirmar é se isso abrange todos os possíveis cenários de vazamento (por exemplo, DNS, etc.).

Observação: também estou usando dnsmasq , então o Raspberry Pi também é o servidor DNS emitido pelo servidor DHCP para clientes na rede privada. Gostaria de saber se tudo o que preciso fazer é configurar dnsmasq para encaminhar consultas de DNS por meio de tun0 (se possível), ou optar por encaminhar para o DNS público (ou seja, 8.8.8.8, 8.8.4.4). Além disso, a partir de agora, essa configuração ainda bloqueia minhas conexões de saída, mas a emissão de sudo ufw allow out on wlan0 restaura essa conexão (com o killswitch VPN ainda em vigor). Então eu sinto que estou perto e talvez apenas mais algumas regras.

Agradeceria muito a alguém que examinasse esses detalhes e fornecesse feedback!

    

Answer 1

Então, acho que vou deixar essa resposta porque acredito que talvez tenha descoberto a parte que faltava (graças a /var/log/ufw.log ), a menos que outra pessoa veja o contrário:

# Allow DNS queries
# [UFW BLOCK] IN= OUT=wlan0 SRC=192.168.10.x DST=192.168.10.1 LEN=66 TOS=0x00 PREC=0x00 TTL=64 ID=50892 DF PROTO=UDP SPT=22617 DPT=53 LEN=46 
sudo ufw allow out on wlan0 from any to any port 53 proto udp

Então, meu conjunto de regras atual é assim agora (observe a saída padrão):

Status: active
Logging: on (low)
Default: deny (incoming), deny (outgoing)
New profiles: skip

To                         Action      From
--                         ------      ----
53,67/udp on eth0          ALLOW IN    Anywhere
22/tcp on eth0             ALLOW IN    Anywhere

1194/udp                   ALLOW OUT   Anywhere on wlan0
Anywhere                   ALLOW OUT   Anywhere on eth0
Anywhere                   ALLOW OUT   Anywhere on tun0
53/udp                     ALLOW OUT   Anywhere on wlan0

Comandos:

# Allow incoming requests to DNS/DHCP services (UDP) on eth0 interface only (i.e. Private Network -> Pi:43,67/udp)
sudo ufw allow in on eth0 from any to any port 53,67 proto udp

# Allow incoming requests to SSH service (TCP) on eth0 interface only (i.e. Private Network -> Pi:22/tcp)
sudo ufw allow in on eth0 from any to any port 22 proto tcp

# Allow outbound on wlan0 interface for DNS and VPN traffic only (i.e. Pi -> LAN:1194)
sudo ufw allow out on wlan0 from any to any port 53,1194 proto udp

# Allow all outbound traffic on eth0 (i.e. Pi -> Private Network)
sudo ufw allow out on eth0

# Allow all outbound traffic on VPN tunnel only (i.e. Pi -> VPN)
sudo ufw allow out on tun0

# Set defaults (also see /etc/default/ufw)
sudo ufw default deny incoming
sudo ufw default deny outgoing

Isso também é combinado com a entrada da tabela NAT em /etc/ufw/before.rules mencionada na postagem original para manipular eth0 -> tun0 "roteamento".

E, finalmente, meu /etc/dnsmasq.conf contém a seguinte entrada server :

# Force VPN by selecting public DNS
server=8.8.8.8

# Do not read from /etc/resolv.conf and friends for system DNS
no-resolv

# Do not poll /etc/resolv.conf and friends for system DNS
no-poll

A execução de um traceroute confirma que as solicitações enviadas para 8.8.8.8 estão acima da VPN e, por configuração (DHCP implícito), o cliente usará como padrão o Pi para seu DNS, que por sua vez usa essa configuração.

Isso é um embrulho!