Rota de tráfego VPN de saída através do proxy transparente local

Question

Eu tenho um droplet Digital Ocean (semelhante a uma instância do Amazon EC2) executando o Ubuntu Server 12.04.3 x64 com o strongswan 5.1.1 (criado a partir do código-fonte) e o squid 3.4.2 (também construído a partir do código-fonte) instalado.

Tanto o VPN strongswan quanto o proxy squid funcionam muito bem individualmente, com algumas pequenas mudanças de regra iptables entre os testes, é claro.

O que eu gostaria de fazer é poder iniciar a conexão VPN a partir do meu computador / dispositivo e fazer com que o tráfego da VPN de saída seja roteado automaticamente pelo proxy do squid local.

Ou seja, o fluxo de tráfego deve ser algo assim:

Cliente - > VPN - > Proxy - > Internet

Infelizmente, não consigo descobrir uma boa maneira de fazer esse tipo de conexão funcionar. Um amigo apontou que a cadeia de saída da tabela NAT no iptables pode ser minha solução, sugerindo uma regra como esta:

iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 3128

Embora faça sentido para mim, logicamente, como isso pode funcionar, não parece estar fazendo isso. Não vejo nenhum pacote seguindo a regra (verificando periodicamente o pacote de entrada / saída conta com um comando iptables-save) enquanto tento carregar o conteúdo enquanto estiver conectado à VPN.

Lembre-se, eu não sou especialista em iptables ou linux, então por favor, tenha paciência comigo aqui se algo que eu disser (ou algo que eu disser) for bobo / estúpido / obviamente-maldito-problema. ;)

Estou aberto a sugestões sobre como resolver isso, mas remover um componente não é uma solução. Eu preciso tanto da VPN quanto do Proxy rodando assim. Mudar versões de qualquer dos componentes também não é o ideal, embora seja muito mais viável.

Eu forneci tanto o ipsec.conf quanto o squid.conf, bem como o meu script de regra atual do iptables.

P.S. Se você perceber, há algumas coisas relacionadas ao uso do RADIUS para autenticação. Não se preocupe com isso. Não está sendo usado atualmente e não deve ter nenhum efeito sobre essa questão.

Script iptables:

iptables -F
iptables -t nat -F
iptables -t mangle -F

iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT

export WAN=eth0
export vpnclients=10.100.0.0/255.255.0.0

# Allow access to our SSH server from the WAN
iptables -A INPUT -p TCP --dport ssh -i ${WAN} -j ACCEPT

# Add the rules for NAT
# iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-port 3128
iptables -t nat -A POSTROUTING -o ${WAN} -j MASQUERADE

iptables-save

ipsec.conf:

config setup
ca ipsec
        cacert=ca.pem
        auto=add

conn %default
        ikelifetime=60m
        keylife=20m
        ike=aes256-sha1-modp1024!
        esp=aes256-sha1!
        leftcert=vpn-server.crt
        leftauth=pubkey
        rightsendcert=never
        leftsendcert=always
        eap_identity=%identity%
        leftfirewall=yes
        auto=add

conn ikev1
        keyexchange=ikev1
        rightauth=pubkey
        rightauth2=xauth
        rightsourceip=10.100.0.0/16
        right=%any
        rightid=%any
        rightdns=8.8.8.8,8.8.4.4
        leftsourceip=<my_server_ip>
        leftsubnet=0.0.0.0/1,128.0.0.0/1,::/1,8000::/1

conn ikev2
        keyexchange=ikev2
        rightsourceip=10.100.0.0/16
        right=%any
        rightid=%any
        rightauth=eap-radius

squid.conf:

#dummy name used
cache deny all
forwarded_for off

#for debugging, enable in production
strip_query_terms off

cache_effective_user proxy
cache_effective_group proxy
client_dst_passthru on
host_verify_strict off
http_port 3130 intercept
http_port 3128
https_port 3129 intercept ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/dev/squid.pem

always_direct allow all
ssl_bump server-first all

# the following two options are unsafe and not always necessary:
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER

# Change these to your local DNS servers
dns_nameservers 8.8.8.8 8.8.4.4
coredump_dir /var/cache/squid

http_access allow all
http_reply_access allow all

    

Answer 1

Eu tive exatamente o mesmo problema, e depois de quase 1 dia, eu pude resolver esse problema. Esta solução é para qualquer um que leia isso no futuro.

Target: o mesmo que o OP que eu estava tentando acessar

Cliente - > VPN - > Proxy - > Internet

Configuração: Ubuntu 16.04

VPN: L2TP usando xl2tpd e pptpd, bem como strongswan para criptografia A configuração da VPN e o servidor Squid Proxy estão na mesma máquina.

Pool de IPs privados para distribuir IPs para clientes: 172.21.118.0/24

Como o OP esperado, você precisa executar -j REDIRECT --to-port 3128 em alguma tabela nat (PREROUTING ou OUTPUT).

Pesquisando e registrando com as diferentes tabelas, aqui está o caminho que cada pacote proveniente de 172.21.118.0/24 segue:

mangle PREROUTING - > nat PREROUTING - > mangle FORWARD - > filtrar FORWARD - > mangle POSTROUTING - > nat POSTROUTING

Eu entendi como este trabalho, usando uma ótima ilustração do ciclo de vida do pacote iptables:

Fonte: link

Como se viu, essa configuração não envia nada na cadeia OUTPUT, portanto, o único lugar para redirecionar uma porta é a cadeia PREROUTING.

A solução é simplesmente:

iptables -t nat -I PREROUTING  -i ppp0 -s 172.21.118.1/24 -j REDIRECT --to-ports 3128

Também não se esqueça de fazer SNAT no seu IP público para acessar a internet:

iptables -t nat -A POSTROUTING -j SNAT -s 172.21.118.2/24 --to-source ${IP} -o eth0
#Alternatively but slower:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE