宛先ドメインに基づくルーティングは不可能ではありません。適切なツールがあれば、それほど難しいことではありません。
特別なクライアント側の構成をほとんど、またはまったく必要としない方法をいくつか紹介します。これらはすべて、OpenVPN を使用して接続していることを前提としています。これは他の VPN で実現できるはずですが、VPN が起動された後、さらに手動で構成する必要がある場合があります。
例として、非 VPN 経由でルーティングするドメインに「example.com」、「us1.example.com」、「us2.example.com」、および「geoblocked.com」を使用します。
すべてのコマンドは root として実行する必要があります。
方法 1 - OpenVPN
ルーティングしている IP アドレスが変更されない静的 IP を持っていることが確実な場合にのみ、これをお勧めします。
長所:
- 非常にシンプル
短所:
- 決してない IP を持つドメインに対してのみ信頼できます 変更
- すべてのドメインとサブドメインに明示的なエントリが必要
方法:
次の行を OpenVPN 構成に追加します:
route example.com 255.255.255.255 net_gateway
route us1.example.com 255.255.255.255 net_gateway
route us2.example.com 255.255.255.255 net_gateway
route geoblocked.com 255.255.255.255 net_gateway
OpenVPN を再起動します。
それだけですが、これらの IP アドレスが変更された場合は、VPN を再起動する必要があります。
注意 :allow-pull-fqdn も指定する必要があると言う情報源もあります 、しかし、私の経験ではそうではないようでした。 YMMV.
方法 2 - ポリシー ベースのルーティング
ポリシー ベースのルーティングは、特定の基準に基づいてルーティングする機能です。通常は送信元アドレスまたはプロトコルですが、この場合、ルーティングの前に宛先ドメイン名を検査し、マークされたパケット (「fwmark」) を使用します。
したがって、最初に行う必要があるのは、VPN routedpackets 用に別のテーブルを作成することです。これにより、VPN を通過するパケットをマークし、マークされたパケットを非 VPN インターフェースに渡すことができます。 (これは 1 つのアプローチであり、VPN がメイン テーブルを介して通常どおりルーティングを実行し、非 VPN トラフィック用に別のテーブルを作成するなど、これにアプローチする他の多くの方法があることを覚えておいてください。)
カーネルは十分に新しく、適切なモジュールを備えている必要がありますが、最新のシステムではおそらくデフォルトのカーネルに含まれています。
名前「vpn_table」(ルーティング テーブル名)、数字「201」(ルーティング テーブル ID) および「3」(fwmark) は任意に選択されます。
新しいルーティング テーブルを作成します (ルートとして):
echo 201 vpn_table >> /etc/iproute2/rt_tables
OpenVPN を構成する:
次のスクリプトをどこかに作成し (「/etc/openvpn/client/setup-routing」と呼んでいます)、実行可能にします:
#!/bin/bash
ip route add 0.0.0.0/1 via $route_vpn_gateway dev $dev scope global table vpn_table
ip route add 128.0.0.0/1 via $route_vpn_gateway dev $dev scope global table vpn_table
sysctl -w net.ipv4.conf.$dev.rp_filter=2
# You can optionally leave the next two lines out but run the `ip rule add`
# command at each boot instead
ip rule del fwmark 3 table vpn_table &>/dev/null # This might fail but that's ok
ip rule add fwmark 3 table vpn_table
上記のスクリプトの変数は、OpenVPN によって環境変数として読み込まれます。また、これにより all へのルーティングが設定されることに注意してください 「vpn_table」ルーティング テーブルの VPN ゲートウェイ経由のアドレス。 VPN セットアップがより複雑なルーティングを必要とする場合は、OpenVPN のドキュメントを参照し、それに応じて調整してください。
以下を OpenVPN 構成に追加してください:
## Policy routing
route-noexec
script-security 2
route-up /etc/openvpn/client/setup-routing
「route-noexec」行は、OpenVPN がサーバーからルートをフェッチすることを許可しますが、実際にルートを設定することはできません。代わりに、ルートアップ スクリプトが呼び出されます。ユーザー定義スクリプトを呼び出すには、「script-security 2」が必要です。
マークされたパケットをルーティングするために必要な設定はこれだけですが、実際にパケットをマークする方法を設定する必要があります。 2 つのオプションは、ipset で dnsmasq を使用するか、squid プロキシを設定することです。
方法 2a - ipset と dnsmasq を使用したポリシー ベースのルーティング
dnsmasq ベースのルーターで既にこれを実行している場合、またはクライアントがプロキシ構成をサポートしていない場合は、この方法をお勧めします。これは事実上、ドメイン名が検索されるたびにルーティング テーブルを更新するキャッシング DNS と同じです。
長所:
- サブドメインの処理
- プロキシにアクセスできないデバイスで動作します (存在しますか?)
短所:
- リファラー フィールドを処理しない (方法 2b を参照)
- 複雑な ipset と iptables の設定が必要
- VPN 接続システムをルーターとして設定する必要があります (専用インターフェースが必要です)
- ipset がどの程度拡張可能かはわかりません (私の使用例は ccTLD 全体です)
これは、dnsmasq が既に構成およびセットアップされており、専用インターフェース「eth1」に接続されたクライアントのゲートウェイおよび DNS サーバーとして機能していることを前提としています。
ipset を作成します:
ipset create SKIP_VPN_IPSET iphash
iptables に ipset パケットをマークするように指示します (n.b.、これは 必須 後に行われます ipset リストの作成):
# Mark ALL packets coming in on eth1 - change this to the interface dnsmasq listens on
iptables -A PREROUTING -i eth1 -t mangle -j MARK --set-mark 3
# REMOVE mark on any addresses that match our ipset
iptables -A PREROUTING -t mangle -m set --match-set SKIP_VPN_IPSET dst -j MARK --set-mark 0/3
注意 :上記のコマンド (ipset そして iptables ) は、ブートごとに実行する必要があります。または、お使いの OS が iptable ルールと ipsets を保存/復元するためのオプションを提供している場合があります。
注 2 :逆 ! --match-set が文書化されています しかし、試してみると、すべてのパケットが消えてしまいました.
以下を dnsmasq.conf に追加してください:
ipset=/example.com/geoblocked.com/SKIP_VPN_IPSET
明らかに、ルーティングするドメイン名に関係なく、その行も調整します。これにより、ALL も追加されます サブドメインを ipset に追加するため、明示的に指定する必要はありません。 TLD を使用しても機能します。
dnsmasq を再起動し、クライアントが VPN 接続システムをゲートウェイと DNS の両方として使用するように設定します (これは、DHCP サーバーとして設定されている場合に暗示されるはずです)。
方法 2b - squid を使用したポリシー ベースのルーティング
これは私のお気に入りの方法で、接続に使用する PS4 やその他のデバイスでうまく機能します。
長所:
- サブドメインの処理
- リファラー フィールドを処理します
- 既存のルーターを交換する必要はありません
- クライアント (ブラウザ) はオプションでそれを使用するかどうか
短所:
- クライアントはプロキシ接続をサポートする必要があります
これは、squid の設定が機能しており、squid の設定に関する基本的な知識があることを前提としています。
次の行を squid.conf に追加します:
# redirect example domains
acl domain_to_remote_proxy dstdomain .example.com
acl ref_to_remote_proxy referer_regex [^.]*\.example.com.*
# redirect geoblocked domain
acl domain_to_remote_proxy dstdomain .geoblocked.com
acl ref_to_remote_proxy referer_regex [^.]*\.geoblocked.com.*
# mark packets that we want routed through the VPN
tcp_outgoing_mark 0x03 !ref_to_remote_proxy !domain_to_remote_proxy
ドメインごとに 2 つの行があり、サブドメインが一致していることに注意してください。最初の行は宛先ドメインをチェックし、2 行目は「Referer」ヘッダーと一致します。これは、画像、CSS、JavaScript などの Web ページのコンテンツを取得するときにブラウザーがリファラーを送信するため、便利です。これは、サイトが要求したコンテンツが別のドメイン (example-cdn.com など) でホストされている場合でも、VPN 以外のアドレスを介してルーティングされることを意味します。
クライアントで、通常のように接続をセットアップしますが、このシステムのプロキシ サーバーとポートを使用するようにプロキシ設定を設定します。ほとんどのデバイス (ゲーム コンソールを含む) では、システム全体の構成が可能です。 PC では、ほとんどのブラウザは、システム設定とは無関係にプロキシを使用するように構成できます。
最終的な注意 - 私の使用例は、実際には特定のドメインを VPN 経由でルーティングし、その他すべてを非 VPN 経由でルーティングすることです。メソッドは上記と似ていますが、逆になっています。
ドメイン名に基づいてルーティングを管理することは避けることをお勧めします (ちなみに、ボーナス ポイントであるかどうかにかかわらず、ワイルドカード サブドメインを解決することも不可能です :D)
少し説明すると、次の理由により、これを行うべきではありません:
1) 一部のドメインでは IP が時々変更されます。
2) サブドメインでワイルドカードを一致させることは不可能です
3) 任意のドメインのすべてのサブドメインを知る/取得することは不可能です
4) ランダムなサブドメインは、ランダムな IP アドレスを持つことができます。
そのため、ブラウザ アドオン (および/または squid などのカスタム ローカル プロキシ) としてのソリューションが、問題に対する最良の選択肢です。
しかし、「FoxyProxy」アドオン (元々は Firefox アドオンですが、AFAIRC、Chrome バージョンも存在します) はまさにあなたが望むものです。
また、「FoxyProxy は有料サービスであり、既に VPN をお持ちです」という通知への回答:
FoxyProxyプラス は有料サービスですが、FoxyProxy ではありません。
FoxyProxy はアドオンで、主要なブラウザで利用できます:
標準版 (Firefox) |基本版 (Firefox)
標準版 (Chrom{e,ium}) |基本版 (Chrom{e,ium})
そのため、VPN 経由でいくつかのドメインにアクセスしたい場合は、次のことを行う必要があります:
1) foxyproxy がドメインのリストの squid インスタンスを通過するためのルールを作成します
2) および/またはイカのルールリストを書く
3) http/https トラフィックをキャプチャ 所有していません iptables で squid を実行し、次のようなルールで squid を指定します:
iptables -m owner -m multiport -t nat -A OUTPUT ! -o lo ! --uid-owner $squid_user_id -p tcp --dports 80,443,8080,... -j REDIRECT --to-ports $SQUID_PORT
(--syn -p tcp にはオプションが必要な場合があります)
4) 所有の http/https トラフィックをキャプチャする 次のようなルールで VPN にルーティングするようにマークします:
iptables -A OUTPUT -m owner --uid-owner $squid_user_id -j MARK --set-mark 11
5)
echo 11 forcevpn >> /etc/iproute2/rt_tables
ip rule add fwmark 11 table forcevpn
ip route add default via 10.0.0.1 table forcevpn
どこで 10.0.0.1 VPN 内のゲートウェイですか。または dev $VPN_IF を使用できます via 10.0.0.1 の代わりに ゲートウェイがなく、すべてのトラフィックを VPN インターフェースにプッシュしたい場合。
6) オプションで、 sudo sysctl ipv4.conf.all.rp_filter
=0 を実行する必要がある場合があります
===
そしてもう 1 つ:
http(s) 以外の TCP トラフィックで同じマジックを実行したい場合は、プロキシチェーンのようなものが必要になり、同様のキャプチャ マジックを実行します。
そして、UDP でその魔法を使いたいのであれば、悪いニュースがあります:UDP をプロキシできるプロキシを私は知りません (このプロトコルの性質上) :)
⇓⇓⇓ 編集 ⇓⇓⇓
逆のことが必要な場合 (デフォルト gw =vpn、一部のドメインを ISP 経由で直接ルール化) は、次のようになります:
1) foxyproxy がドメインのリストの squid インスタンスを通過するためのルールを作成します
2) 所有するトラフィックを獲得する 次のようなルールで別の方法でルーティングするためにマークします:
iptables -A OUTPUT -m owner --uid-owner $squid_user_id -j MARK --set-mark 11
3)
echo 11 novpn >> /etc/iproute2/rt_tables
ip rule add fwmark 11 table novpn
ip route add default via ${ISP_GW} table novpn
どこで ISP_GW トラフィックを VPN サーバーにルーティングするために使用するゲートウェイです。一部のユーザーは dev ppp0 を使用したい場合があります (または ppp1 , ..., pppN ) via ${ISP_GW} の代わりに pptp を使用してインターネットに接続する場合に備えて。