私は、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
私はまったく同じ問題を抱えていましたが、ほぼ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パケットのライフサイクルのすばらしい図を使用して、これがどのように機能するかを理解しました。
ソース: 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