現在実行中のシステムはHTTPおよびHTTPSトラフィックを直接送受信できる必要がありますが、他のすべてのトラフィックはVPNを通過する必要があります。
私の設定は次のとおりです
x2 インターフェイス: eth0 (ローカルネットワーク、ルータの背後) および tun0 (openvpn クライアント)
現在、すべてのトラフィックはVPN経由でルーティングされます。可能かどうか知りたいです。いいえVPNを介してhttpおよびhttpsトラフィック（80、443）をルーティングします。
これは、システムとopenvpnクライアントが起動したときのルーティングテーブルです。
0.0.0.0/1 via 10.8.13.5 dev tun0
default via 192.168.1.1 dev eth0
10.8.13.1 via 10.8.13.5 dev tun0
10.8.13.5 dev tun0 proto kernel scope link src 10.8.13.6
128.0.0.0/1 via 10.8.13.5 dev tun0
176.67.168.144 via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.56
192.168.1.1 dev eth0 scope link
他の同様の質問を読みましたが、答えはトラフィックを再ルーティングしないかブロックするだけです。
よろしくお願いします:)
答え1
ルーティングはIPレイヤ3にあります。 TCPはレイヤ4にあるため、ルーティングだけではこの問題を解決するのに十分ではありません。
つまり、興味深いトラフィックが必要です。次に表示iptables、選択したパケットにタグを付けます。ip rulefwmark別々のルーティングテーブルを使用してください。その後、ローカルの送信元/受信トラフィックケースに2つの追加の修正を適用する必要があります。これはルーティングケースよりも困難です。もちろん、すべての設定はローカルシステムで行われます。
ルーティングテーブル80（一致するシンボル名を追加できますが/etc/iproute2/rt_tables必須ではありません）とタグは0x80「任意に」選択されます。
ip route add table 80 192.168.1.0/24 dev eth0 scope link src 192.168.1.56
ip route add table 80 default dev eth0 via 192.168.1.1
-Iiptablesルールが遅すぎて接続されていないことを確認するために使用されます。現在の規則に従って、必要に応じて並べ替え方法を確認する必要があります。
iptables -t mangle -N markports
iptables -t mangle -I PREROUTING 1 -j CONNMARK --restore-mark
iptables -t mangle -I OUTPUT 1 -m mark --mark 0 -j markports
iptables -t mangle -I OUTPUT 2 -j CONNMARK --save-mark
iptables -t mangle -A markports -p tcp --dport 80 -j MARK --set-mark 0x80
iptables -t mangle -A markports -p tcp --dport 443 -j MARK --set-mark 0x80
ip rule add fwmark 0x80 lookup 80
このブログ：Netfilter Connmark » Linux以上！に関する良い情報を提供してくださいCONNMARK。
これは機能しますが、実際には、ルートが通過しようとしたときに最初のルーティング決定で誤ったデフォルトの発信IPを選択しますtun0。タグによる小切手パスの再指定mangle/OUTPUT(この内容を参照)一般的なネットワーク図のNetfilterとパケットフロー明確にするために）このIPは変更されません。処理中のトラフィックがローカルで開始されずにルーティングされる場合、この問題は発生しません。サービスであることを確認するために別々のネットワーク名前空間を使用するソリューションは、デスクトップで機能しない可能性があります。したがって、これにはその上に1つのレイヤーが必要ですMASQUERADE（またはより複雑な場合）。SNAT
iptables -t nat -I POSTROUTING 1 -m mark --mark 0x80 -j MASQUERADE
今、発信元IPは正確ですが、まだ機能していません。リバースパスフィルタほぼ同じ理由で戻りパスで発生します。以前に行われたルーティング決定は、当分の間PREROUTING知られていないfwmark（たとえ前の回路図mangle/PREROUTINGこれは明らかにそうでないルーティング決定の前に配置されるため、戻りトラフィックパケットはなりすましと見なされ、早期に廃棄されます。eth0インターフェースrp_filterこれを可能にするには、緩いモードに設定する必要があります。これにより、NAT の背後にいくつかの（非常にマイナーな）セキュリティ問題が発生する可能性がありますが、ルーティングされていない場合は回避できません。
echo 2 > /proc/sys/net/ipv4/conf/eth0/rp_filter
永久に設定する方法を見つける必要があります（たとえば、echo net.ipv4.conf.eth0.rp_filter=2 > /etc/sysctl.d/90-local-loose-mode.conf後で何も変更しない場合）。
OPと同様の設定で名前空間を使用してテストした結果は大丈夫でした。
注：DNS要求は引き続きトンネルを通過します。一部のローカライズされたWebサービスは期待どおりに機能しない場合があります。