web-dev-qa-db-ja.com

ローカルの透過プロキシを介して発信VPNトラフィックをルーティングします

私は、strongswan 5.1.1(ソースから構築)とsquid 3.4.2(これもソースから構築)の両方がインストールされたUbuntu Server 12.04.3x64を実行しているDigitalOceanドロップレット(Amazon EC2インスタンスに類似)を持っています。

Strongswan VPNとsquidプロキシはどちらも個別に問題なく機能しますが、もちろん、テスト間でいくつかのマイナーなiptablesルールが変更されます。

私がやりたいのは、コンピューター/デバイスからVPN接続を開始し、発信VPNトラフィックをローカルのsquidプロキシ経由で自動的にルーティングできるようにすることです。

つまり、トラフィックの流れは次のようになります。

クライアント-> VPN->プロキシ->インターネット

残念ながら、この種の接続を機能させるための良い方法を理解できないようです。友人は、iptablesのNATテーブルの出力チェーンが私の解決策かもしれないと指摘し、次のようなルールを提案しました:

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

これがどのように機能するかは論理的には理にかなっていますが、そうではないようです。 VPNに接続しているときにコンテンツを読み込もうとすると、ルールに従ったパケットが表示されません(iptables-saveコマンドで着信/発信パケット数を定期的にチェックします)。

念のために言っておきますが、私はiptablesやlinuxの専門家ではないので、私が言ったこと(または私が言ったこと)がばかげている/ばかげている/明らかに気の毒な問題である場合は、ここで我慢してください。 ;)

私はこれを解決する方法についての提案を受け入れていますが、コンポーネントを削除することは解決策ではありません。 VPNとプロキシの両方をこのように実行する必要があります。どちらかのコンポーネントのバージョンを変更することも理想的ではありませんが、はるかに実現可能です。

Ipsec.confとsquid.confの両方、および現在のiptablesルールスクリプトを提供しました。

P.S.お気づきの方もいらっしゃると思いますが、認証にRADIUSを使用することに関連するものがいくつかあります。心配しないでください。現在は使用されていないため、この質問に影響はありません。

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
4
Joshua Sleeper

私はまったく同じ問題を抱えていましたが、ほぼ1日後に、この問題を解決することができました。このソリューションは、将来これを読む人のためのものです。

ターゲット:私が到達しようとしていたOPと同じ

クライアント-> VPN->プロキシ->インターネット

セットアップ:Ubuntu 16.04

VPN:xl2tpdとpptpdを使用するL2TP、および暗号化用のstrongswanVPNセットアップとSquidプロキシサーバーは同じマシン上にあります。

クライアントにIPを配布するためのプライベートIPプール:172.21.118.0/24

OPが期待するように、いくつかのNATテーブル(PREROUTINGまたはOUTPUT)で-j REDIRECT --to-port 3128を実行する必要があります。

さまざまなテーブルを使用してプローブおよびログを記録します。172.21.118.0/ 24から発信される各パケットのパスは次のとおりです。

mangle PREROUTING-> nat PREROUTING-> mangle FORWARD-> filter FORWARD-> mangle POSTROUTING-> nat POSTROUTING

Iptablesパケットのライフサイクルのすばらしい図を使用して、これがどのように機能するかを理解しました。

enter image description here ソース: http://64-bit.de/dokumentationen/netzwerk/e/002/DE-IPTABLES-HOWTO-3.html

結局のところ、このセットアップはOUTPUTチェーンで何も送信しないため、ポートをリダイレクトする唯一の場所はPREROUTINGチェーンです。

ソリューションは単純です:

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

また、インターネットにアクセスするために、パブリックIPにSNATすることを忘れないでください。

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
1
Moataz Elmasry