OpenWrt の VPN ゾーン、転送、マスカレード：どれが必要か

VPN が OpenWrt に出会うたびに、三つの変更が混同されます。ポートを開くこと、転送を許可すること、マスカレードを有効にすることです。これらは別々の問いに答えるもので、通常はそのうち一つだけが本当の要件です。各コントロールを、それが統制するトラフィックの役割に沿って読めば、推測が判断に変わり、変更が誤っているときにどの症状を予期すべきかも分かります。思い出したチェックボックスではなく、失敗した役割の名前から始めてください。

コントロールに触れる前にトラフィックの役割を名づける

ゾーンの入力は、ルーター自身に何が届いてよいかを決めます。ゾーンの出力はルーターが自ら生成するトラフィックを対象とし、ゾーンの転送はゾーンを通過するトラフィックの既定値であり、マスカレードは出ていくときに送信元アドレスを書き換えるかどうかを決めます。これは四つの異なる問いであり、ゾーンポリシーは同じ値で四つすべてに一度に答えるため、ゾーン全体の変更は粗い道具になります。名前付きのルールなら、残りに触れずにそのうち一つに答えられます。

役に立つ地図はトラフィックの役割ごとのもので、何かが失敗したときに観察できるのはそれだからです。以下の各役割には、それを決めるコントロールが一つと、それを指し示す症状が一つあります：

ルーター上で待ち受けるものには狭い入力ルールが一つあればよい

ルーター上の OpenVPN サーバーはルーター宛てのトラフィックを受け取るため、その外側の接続はそれを運ぶゾーンの入力ポリシーに依存します。設定したトランスポートとポートを許可し、そのゾーンの他のすべては拒否のままにします。ポートのルール一つは、ゾーン全体の許可よりはるかに小さな変更であり、一年後にも説明できるのはこちらです。

そのルールを安全に保てる理由は二つあり、一つはサービスが実際に使うポートを名指ししていること、もう一つはゾーンの定義の隣に置かれて次の人がなぜ存在するのか分かることです。下の行は形だけを示すもので、ポートはサーバーに設定された値を表します。サービスを移すときは両方の場所でそのポートを変えてください、古いポートに残ったルールは監査まで見えないからです。

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

再読み込みの前に検証してください。ファイアウォールのファイルの構文エラーは、ルーターを動くルールセットのない状態にし得ます。fw4 を使うリリースでは、チェックは別のコマンドであり、壊れたブロックを黙って受け入れるのではなく、大きな音を立てて失敗します。チェックが通ってからはじめて再読み込みし、以前のファイルは元に戻せる場所に保管してください。

fw4 check
service firewall reload

クライアントの要求は入力ではなく転送を通る

認証のあと、LAN のサービスを求めるトンネルクライアントの要求は転送されるフローを生むため、それを決めるコントロールはトンネルゾーンと LAN ゾーンの間の転送関係です。トンネルのインターフェースを目的のゾーンに割り当て、そのうえで方向、送信元、サービスを宣言します。ゾーンの割り当てこそが転送ルールに意味を与えるもので、両者は一緒に読んで初めて意味を持ちます。トンネルゾーンを送信元、LAN ゾーンを宛先とする転送関係は一つの意図的な判断として読めますが、ゾーン全体の許可が二つあると事故として読めます。

ルーター自身への到達は今も入力の経路を使うため、ゲートウェイへの ping はその背後のファイル共有について何も語りません。この二つの失敗は別のブロックにあり、別の変更で直します。どちらかを変える前に、両方の経路を別々に書き出してください。

マスカレードはルーティングの判断であり、許可ではない

マスカレードは選択した外向きトラフィックの送信元アドレスを書き換えます。遠い側に戻りの経路がない出口設計を救うことができ、またアドレスを記録したりアドレスで承認したりするあらゆるサービスから個々のクライアントのアドレスを隠します。これを切るのは戻り経路についてのルーティングの選択であり、内向きの穴を閉じるセキュリティスイッチではありません。翻訳を有効にすると動き、切った瞬間に失敗するトンネルは、通常、戻り経路が欠けているのであって、ファイアウォールのルールが欠けているのではありません。

ルーティングされた代替案は、翻訳の代わりに遠い側に戻り経路を必要とします。どちらの選択肢もファイアウォールの許可やアプリケーションのアカウントを提供しないため、マスカレードを切っても、どこにも届かないトンネルクライアントが直ることはほとんどありません。IPv4 と IPv6 のポリシーも別々に扱ってください。翻訳の設定一つでは両方のファミリーを記述できないからです。

許可された要求と拒否された要求で判断を証明する

許可されるべき要求を一つと、拒否されるべき要求を一つ送り、それぞれの判断を下したコントロールを特定します。たまたま読み込まれたページは証拠ではなく、証拠は、一致したルールであり、それが一致したチェーンの中にあります。拒否は、すべてが許可されているのではなくポリシーが何かをしていることを示すので、成功と同じくらい重要です。

現在のリリースでは二つのコマンドがその証拠を与えます。要求が受け入れられると一致したルールのカウンターが動き、そのルールのログを有効にしていればログにドロップが表示されます：

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

ファイアウォールのポリシーを変える前に、まだ使える管理経路を確保し、設定の所有者の検証とロールバックの手順に従ってください。ルーターから閉め出される変更はテストの結果ではなく、二度目のインシデントです。観察のたびにゾーンとトラフィックの役割を横に記録し、結果の対が幸運なページ読み込みを描写するのではなくポリシーを説明するようにしてください。