二つのOpenVPNパケット経路のためのShorewallゾーン
暗号化されたOpenVPNトランスポートを復号済みのクライアントトラフィックから分離し、トンネルに専用ゾーンを与え、クライアントが必要とする1つのサービスのみを許可します。
二つのパケットフローがOpenVPNを終端するShorewallゲートウェイを通過し、暗号化されているのはそのうち一つだけです。一つ目はインターネット側インターフェースのVPNリスナーへのクライアントのトランスポートです。二つ目はトンネルインターフェースを出る復号済みの要求で、オフィスのサーバーやゲートウェイ上のサービスに向かいます。一つ目を満たすルールは二つ目には何もしないため、ポリシーを編集する前に両方を図にしてください。
ポリシーを編集する前に二つのフローを描く
フローを送信元・宛先・プロトコル・ポートを持つ行として書きます。外側の経路では送信元はクライアントの公開アドレス、宛先はゲートウェイのリスナーポートで、Shorewallはこれをインターネットからファイアウォールへのトラフィックとして扱います。内側の経路では送信元はトンネルのアドレス範囲、宛先は承認済みのサービスです。一人の管理者が両方を保守していても、二つの行の所有者は異なります。
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
要求がゲートウェイ自体で終わる場合、たとえばリゾルバーや管理へのアクセスに限って行を追加します。ホスト上のサービスは転送経路ではなくホスト入力ポリシーに従います。この二つを混ぜると、狭いトンネルルールが管理インターフェースを露出させてしまいます。
トンネルゾーンとインターフェースの範囲を割り当てる
ロードウォリアーゾーンは/etc/shorewall/zonesで宣言し、トンネルインターフェースは/etc/shorewall/interfacesで接続し、外側の接続は/etc/shorewall/tunnelsで記述します。列の順序とオプション名がメジャーバージョン間で変わっているため、インストール済みリリースの構文に合わせてください。ガイドの例のポートは、デーモンが実際に待ち受けるポートと違うポートを許可する理由にはなりません。数字が一致するからといってTCPとUDPが交換可能なわけではありません。
ガイドはtun+でインターフェースをまとめます。トンネルが複数あるホストでは、そのワイルドカードが信頼レベルの異なる二つ目のVPNを同じゾーンに置くことがあります。範囲は実際に存在するインターフェースに対して見直し、インターフェース名を手で編集するのではなく、命名を接続マネージャーのライフサイクルに委ねてください。
歴史的なガイドにははるかに古いOpenVPN設定例が含まれており、その暗号化の助言を現在の配備にコピーすべきではありません。代わりにゾーンとフローのモデルを借りてください。暗号の基準はゲートウェイで保守されているOpenVPNポリシーから取ります。
分類した経路だけを許可する
VPNゾーンからLANへの広い許可は出発点の図であり、完成したポリシーではありません。許可するクライアント送信元、実際のサービスアドレス、プロトコル、ポートを書きます。狭い追加はすでに一致している広い許可を取り消さないため、次にその上にあるルールとゾーンの既定値も読みます。ゲートウェイホストへのトラフィックは、それを通過して転送されるトラフィックとは別の関係です。
クライアント間のトラフィックには独自の判断が必要です。OpenVPNのclient-to-clientとShorewallのroutebackはどちらもクライアント同士が到達できるかに影響し、一つのLANアプリケーションを動かすためだけに有効にすべきではありません。テストする前に、隔離をどこで強制するかを決めてください。
応答経路も同じ計画に含めてください。サービスまたはそのルーターが、トラフィックをトンネル範囲に戻す方法を知っている必要があり、そうでなければ設計が意図した範囲内で送信元を明示的に変換する必要があります。
検証し、その後で両方の経路を証明する
何かを再起動する前に設定を検証し、新しいポリシーが誤っている場合に備えて独立した管理セッションを開いたままにします。
shorewall checkクリーンなチェックの後、設定を適用し、Shorewallが読み込んだ内容を読み返します。これらの読み取りは、ファイルが語っているように見えることではなく、実行中のポリシーを記述します。
shorewall show zones
ip route get 192.168.10.20同じクライアントから、新たに許可された要求と意図的に拒否された要求をひとつずつ試します。OpenVPNのハンドシェイクの成功は外側のやり取りだけを証明し、許可されたサービスと拒否されたリソースが、意図した内側のポリシーを証明します。トンネルインターフェースの名前とアドレスはセッション間で変わりうるため、その後クライアントを再接続して繰り返します。結果が異なる場合は、ルールを広げるのではなくゾーンの範囲を修正してください。