困難な事柄に関する有用な記事を引き続き公開しています。
今日は、同時に複数の通信プロバイダーを介したさまざまなサービスの公開に焦点を当てます。
時間の経過とともに、ほとんどすべての組織が予約またはその他のニーズのための追加の通信チャネルを持っているという事実により、「これらの通信チャネルは企業サービスの同時公開に使用できますか?」
しばらく前に、この問題が当社で発生したため、外部境界の再構築が決定されました。
私たちの場合、4つのプロバイダーと次のサービスのリストがありました。
- HTTPサービス(約60サイト)
- XMPPサービス
- HTTPSエンタープライズメールサーバー(Exchange)
- VPNサービス
- Ssh
- IMAP、IMAPS、POP、POP3S、SMTP、SMTPS
- Owncloud
初期接続図は次のとおりです。
サービスを公開するほとんどの人にとっては、ほぼ同じに見えると思います。
このスキームは、1つのプロバイダーとの接続がなくなると、そのプロバイダーに関連付けられているサービスへのアクセスが失われるという点で不便です。
たくさんの外部サーバーの使用を避け、システム構成の利便性を維持したかったのです。
そして、以下をビルドします。
試行錯誤を通して、これはpfにとって非常に興味深い構成です。
int_if="vlan420" ext1_if="vlan410" ext2_if="vlan400" ext3_if="vlan440"
設定について少し説明します。
フロントエンド-http、https、smtp、imap、pop3プロキシモードで立っているnginxサーバー。 同時に、IMAP、SMTP、POP3サービスのマルチドメインサービスが提供されます。
jabber-XMPPメッセージングサーバー
vpn-openvpnサーバー
操作の原理は非常に単純で、pfルールを渡すときにパケットをマークすることに基づいています。
パブリッシュされたポートに到着するパケットは、特定の着信ルーターインターフェイスを通過するときにラベルを受け取ります。 さらに、このマークされたパケットは受信者サーバーに転送されますが、出発したパケットのラベルは状態テーブルに保存されます。 受信者サーバーからパケットが返されると、ラベルが計算され、パケットは元のインターフェイスとゲートウェイに送り返されます。 このようにして、セッションの整合性が維持されます。
公開されたサーバーのデフォルトゲートウェイは、上記のルールが処理されるルーターです。
注意! 指定されたスキームは、サーバーバランサー上のサービスの使用を意味しません!
サーバーバランサーは、着信接続と発信接続のみを処理する必要があります! サーバーバランサーにあるサービスを公開しようとすると、公開されたサービスが利用できないという問題が発生します。 これは、ローカルサービスを使用している場合、ラベルが失われ、着信パケットへの応答がインターフェイスに送信され、デフォルトゲートウェイがバランサーに構成されているためです。そのようなもの。 質問があります-書き込み。
Aborche 2013