仮想ゲートウェイ iptables

Question

Netfilter と NAT はここでは関係なく、ルーティングに関するものです。

政策規則が巡回するにつれて仮想プライベートネットリストまず、デフォルトのパスが原因で、このルートテーブルは常に一致し、ルート検索に対する回答を提供します。基本ゲートウェイ自体172.16.1.1を使用している場合、ルーティングテーブルは廃止されました。だから使用して言うことはありませんラン0これ以上ではありません。

したがって、初期パス選択ではラン0:

$ ip route get to 172.16.1.2
172.16.1.2 dev lan0 src 172.16.1.1 uid 1000 
    cache

このパスを選択すると、アドレスが 172.16.1.0/24 の 172.16.1.1 部分に設定されるため、次の使用に切り替わります。VPN0:

$ ip route get from 172.16.1.1 to 172.16.1.2
172.16.1.2 from 172.16.1.1 via 10.20.1.1 dev vpn0 table vpntable uid 1000 
    cache

修正は維持する例外を追加することです。ラン0この場合。

これにはいくつかの方法があり、すべて問題を解決する必要があります。通常、最初または最後の方法（最も簡単な方法）が使用されます。

VPN ルートテーブルへの LAN ルートの割り当て
```
ip route add 172.16.1.0/24 dev lan0 table vpntable
```
iif loまたは、LANを最初に解析してローカルトラフィックを取得します（ここでの特別な意味はローカルで開始されたトラフィック、実際には関係ありませんルオインターフェイス）とコールルーティングルール基本ルーティングテーブル。優先順位が低い後に追加され、呼び出される前に評価されます。仮想プライベートネットリストルーティングテーブル：
```
ip rule add iif lo to 172.16.1.0/24 lookup main
```
または前の箇条書きのバリエーション：VPNルールをスキップしてすぐに通話に移動する基本ルーティングテーブル：
```
ip rule add iif lo to 172.16.1.0/24 goto 32766
```
または、初期ルーティングルールのアドレスの代わりにインターフェイスを指定します（削除する必要があります）。
```
ip rule delete from 172.16.1.0/24 lookup vpntable
ip rule add iif lan0 lookup vpntable
```
これにより、ローカルアドレスがソースではないため、ローカルアドレスは実行されません。ラン0。

最初の方法とは異なり、最後の方法では、172.16.1.1ソース（まだMASQUERADEルールを介してNATを実行）にバインドすると、デフォルトでゲートウェイでVPNを使用できません。

Answer 1