ViPNetの詳細：暗号ゲートウェイの機能を理解する

認定された暗号ゲートウェイが登場するまで、ネットワークエンジニアの生活は幸せで気楽なものでした。同意します。GOSTに従ってデータ伝送チャネルを暗号化するために設計されたソリューションを扱うことは簡単な作業ではありません。これらがよく知られていて理解しやすい製品であるなら、それは良いことです。同じ「S-Terra」を思い出してみましょう（すでに「S-TerraGateway」について書いています）。しかし、独自の暗号化プロトコルに基づくよりエキゾチックなソリューション、たとえば「Continent」（「SecurityCode」から）やViPNet Coordinator HW（「Infotex」から）をどうするか？この記事では、ViPNetの世界に飛び込みやすくし（いつか大陸についても話します）、自分が直面した問題とその解決方法について説明します。



本日、FSBとFSTECによって認定されたバージョン4.2.1についてお話しすることをすぐに予約します。現在のバージョン4.3.xでは、DGD（Dead Gateway Detection）や、ほぼシームレスな切り替えを提供する変更されたクラスタリングメカニズムなど、多くの興味深いものが登場していますが、今のところこれは将来のことです。キーコマンドと変数に焦点を当てて、構成コマンドとファイルの詳細については詳しく説明しません。これらの「キー」の詳細な説明は、ドキュメントに記載されています。



まず、すべてがどのように機能するかを理解しましょう。したがって、ViPNetコーディネーターはいくつかの機能を実行します。まず、これは暗号ゲートウェイ（CG）であり、サイト間VPNとRAVPNの両方を可能にします。次に、暗号化されたサービスデータ（ディレクトリとキー）またはクライアントアプリケーションのデータ（ファイル交換、ビジネスメール）を含むエンベロープのサーバールーターです。ちなみに、ViPNetネットワークのオブジェクトに関する情報（名前、識別子、アドレス、接続など）を含むファイルが格納されるのはディレクトリです。コーディネーターは、クライアントのサービス情報のソースでもあります。



さらに、ViPNetソフトウェアがインストールされていないネットワークコンピューターからのトラフィックをトンネリングできます。ちなみに、このソリューションを使用する人々は、オープンホストを「トンネルノード」ではなく「トンネル」と呼ぶことがよくあります。これは、トンネルがネットワーク間のPtP接続を参照する他のVPNソリューションに慣れているエンジニアにとっては混乱を招く可能性があります。



同じくInfotexによって開発されたIPlirは、ViPNetの暗号化プロトコルとして使用されます。トラフィックをカプセル化するために、トランスポートプロトコルIP / 241（トラフィックがブロードキャストドメインを離れない場合）、UDP / 55777、およびTCP / 80（UDPが使用できない場合）が使用されます。



安全な接続を構築するという概念は、2つのタイプのいわゆる「接続」に基づいています。前者（ノードレベル）はノード間の安全な接続を構築するために必要であり、後者（ユーザーレベル）はクライアントアプリケーションの操作に必要です。ただし、例外があります。ViPNet管理者ノードには両方のタイプの通信が必要です。



このスキームで何がうまくいかない可能性がありますか？実践が示すように、仕事には本当に多くの特殊性があり、「聴衆の助け」なしにすべての問題を直感的に解決できるわけではありませんが、何かを当然のことと見なす必要があります。

コーディネーターは利用できません

「コーディネーター/クライアント/トンネルはありません。何をすべきか？" -初心者がViPNetを設定するときに思いつく最も頻繁な質問。このような状況での唯一の正しいアクションは、コーディネーターのすべてのトラフィックの登録をオンにして、IPパケットログを調べることです。これは、あらゆる種類のネットワーク問題をトラブルシューティングするための最も重要なツールです。この方法では、80％のケースで節約できます。IPパケットログを操作すると、ViPNetネットワークノードの動作メカニズムをよりよく理解するのにも役立ちます。

封筒が届きません

しかし、残念ながら、IPパケットログはエンベロープに関しては役に立ちません。これらは、独自のジャーナルと独自のキューを持つトランスポートモジュール（mftp）を使用して配信されます。デフォルトでは、エンベロープはクライアントの「独自の」コーディネーター（つまり、ノードが登録されているコーディネーター）に送信され、次にコーディネーター間で構成されたサーバー間チャネルを介して（つまり、セキュアチャネルを介して直接送信されません）送信されます。これは、ビジネスメールで手紙を送りたい場合、クライアントはそれを封筒に詰めて、最初にコーディネーターに送ることを意味します。さらに途中で、さらに数人のコーディネーターがいる可能性があり、その後、エンベロープが宛先のノードに到達します。



これから2つの結論が続きます。まず、エンベロープを配信するために、クライアント間の通信をチェックする必要はありません（F5キーとメニューの対応するアイコンを押します）。次に、それらの間の接続がまだチェックされている場合、問題はサーバー間チャネルの1つにある可能性があるため、これは配信を保証しません。



明らかでない場合は、ジャーナルとエンベロープキュー、およびコーディネーターのログを使用して、サーバー間チャネルを介したエンベロープの通過、またはクライアントとコーディネーター間のエンベロープの通過を診断できます。また、ViPNetクライアントトランスポートモジュールは、エンベロープの直接配信、共有フォルダーを介した配信、またはSMTP / POP3用に構成できます（ただし、これは完全にエキゾチックなオプションです）。これらの設定については詳しく説明しません。

点滅の結果

スペアパーツなど、長期間使用されている古いハードウェアの現在のバージョンにアップグレードするのは問題になる可能性があります。その過程で、「サポートされていないハードウェア」エラーが表示される場合があります。これは、古いG1ラインの本当にサポートされていないハードウェアプラットフォーム（これらはHW100 E1 / E2およびHW1000Q1）があるか、BIOSセットアップの問題またはに埋め込まれている誤った情報について示しています。 DMI。 DMIを自分で管理するかどうかは、機器が役に立たない「レンガ」に変わるリスクがあるため、誰もが自分で決定します。 BIOSを使用すると、少し簡単になります。誤ったシステム設定は、HDDの無効化されたHT（ハイパースレッド）機能または無効化されたACHI（高度なホストコントローラーインターフェイス）モードにあります。問題が正確に何であるかを推測しないために、ファームウェアが生成されているUSBフラッシュドライブを参照できます。診断情報を含むファイルがその上に作成されます。特に、サポートされているすべてのプラットフォームがverbose.txtファイルに一覧表示され、確認した結果が表示されます。たとえば、エラーcpu :: Vendor（＃3）== 'GenuineIntel'24回=> [Failed]は、HTが無効になっていることを示している可能性があります。ちなみに、フラッシュは更新と混同されることがよくありますが、これらは異なるプロセスです。更新時にすべての設定が保存され、上記のパラメータはチェックされません。また、再フラッシュすると、工場出荷時の設定に戻ります。更新時にすべての設定が保存され、上記のパラメータはチェックされません。また、再フラッシュすると、工場出荷時の設定に戻ります。更新時にすべての設定が保存され、上記のパラメータはチェックされません。また、再フラッシュすると、工場出荷時の設定に戻ります。

有益でない構成

HWのメイン構成ファイルは「iplir.conf」ですが、常に現在の設定を反映しているわけではありません。実際のところ、IPlirドライバーをロードする時点で、この構成は設定されたロジックに従って解釈され、すべての情報をドライバーにロードできるわけではありません（たとえば、IPアドレスの競合がある場合）。Linuxソフトウェアコーディネーターを使用したことのあるエンジニアは、ドライバーにロードされている現在のノード設定を表示する「iplirdiag」コマンドをおそらく知っているでしょう。HWでは、このコマンドは「adminescape」モードでも存在します。



最も一般的な結論は次の

とおりです。iplirdiag-sipsettings--node-info <node id> ##ノードに関する情報を表示します

iplirdiag-s ipsettings --v-tun-table ##ドライバーにロードされたすべてのトンネルを表示します



「adminescape」モードについて少し詳しく見ていきましょう。実際、これはViPNetシェルからbashへの出口です。ここで私はベンダーに同意します。ベンダーは、このモードを診断にのみ使用し、ベンダーの技術サポートの監督下でのみ変更を加えることを推奨しています。これは通常のDebianではありません。ここでは、不注意な動きによってOSが無効になる可能性があり、その保護メカニズムによって「イニシアチブ」が潜在的な脅威として認識されます。デフォルトでロックされているBIOSと組み合わせて、これは非保証（「高価な」と読む）修理を非難します。

（Un）スプリットトンネリング

誰もが知っているわけではないもう1つの事実：デフォルトでは、ViPNetクライアントはスプリットトンネルモードで動作します（トンネルにラップするトラフィックとラップしないトラフィックを指定できる場合）。 ViPNetには「オープンインターネット」テクノロジーがあります（後に「セキュアインターネットゲートウェイ」に名前が変更されました）。多くの人が、この機能をクライアントではなくコーディネーターに誤って帰属させています。この機能を使用してコーディネーターに登録されているクライアントでは、2セットのプリセットフィルターが作成されます。 1つ目は、コーディネーター自体とそのトンネルとの対話のみを許可し、2つ目は、他のオブジェクトとの対話を許可しますが、OIコーディネーターとそのトンネルへのアクセスを拒否します。さらに、ベンダーの概念によれば、最初のケースでは、コーディネーターはプロキシサーバーをトンネリングするか、プロキシサーバー自体である必要があります。サービストラフィック、およびエンベロープの受信と送信（両方のサービス、およびアプリケーション）は、どのような構成でも機能します。

TCP-

コーディネーターを介して作業したくないアプリケーションに遭遇したことがあります。このようにして、コーディネーターには、構成の可能性なしに暗号化されていないトラフィックがブロックされるサービスポートがあることを学びました。これらには、UDP / 2046,2048,2050（基本的なViPNetサービス）、TCP / 2047,5100,10092（ViPNet Statewatcherの場合）、およびTCP / 5000-5003（MFTP）が含まれます。ここでは、TCPトンネル機能を要約しました。 ISPが高いUDPポートをフィルタリングすることを好むことは周知の事実です。そのため、管理者はCNの可用性を向上させるために、TCPトンネル機能を有効にします。この場合、DMZ内のリソース（TCPトンネルポート経由）は使用できなくなります。これは、TCPトンネルポートもサービスポートになり、ファイアウォールルールとNAT（ネットワークアドレス変換）ルールがなくなったためです。その事実を診断することは困難ですこのトラフィックは、まったく存在しないかのようにIPパケットログに記録されていません。

コーディネーターの交代

遅かれ早かれ、コーディネーターをより生産的または一時的なオプションに置き換えるという疑問が生じます。たとえば、HW1000をHW2000に、ソフトウェアコーディネーターをPAKに、またはその逆に置き換えます。難しさは、各パフォーマンスがNCC（ネットワークコントロールセンター）で独自の「役割」を持っているという事実にあります。結束を失うことなく役割を適切に変更するにはどうすればよいですか？まず、NCCで役割を新しいものに変更し、ディレクトリを形成しますが、それらを送信しません（！）。次に、UCCで新しいDSTファイルをリリースし、新しいコーディネーターを初期化します。次に、交換を行い、すべてのインタラクションが機能していることを確認した後、リファレンスブックを送信します。

クラスタリングとノードのクラッシュ

大規模なサイトではホットリザーブが必須であるため、古いモデル（HW1000、HW2000、HW5000）のクラスターは常にそれらから購入されていました。ただし、ベンダーのライセンスポリシーにより、よりコンパクトな暗号ゲートウェイ（HW50およびHW100）からクラスターを作成することはできませんでした。その結果、小規模なサイトの所有者は、HW1000を大幅に過払いして購入する必要がありました（まあ、または障害耐性がありません）。今年、ベンダーはついにジュニアコーディネーターモデルの追加ライセンスを作成しました。そのため、バージョン4.2.xのリリースにより、それらをクラスターに収集することが可能になりました。



クラスターを初めてセットアップするときは、ウィザードモードでインターフェイスを構成しないか、CLIコマンドを使用することで、時間を大幅に節約できます。必要なアドレスをクラスター構成ファイルにすぐに入力できます（フェイルオーバー構成編集）。マスクを指定することを忘れないでください。フェイルオーバーデーモンがクラスターモードで開始されると、対応するインターフェイスにアドレスが自動的に割り当てられます。アドレスがパッシブアドレスまたはシングルモードアドレスに変更されていると想定して、多くの人がデーモンを停止することを恐れています。心配しないでください。インターフェースは、デーモンが停止したときのアドレスを保持します。



クラスターバージョンでは、2つの一般的な問題があります。パッシブノードの周期的な再起動と、アクティブモードへの切り替えの失敗です。これらの現象の本質を理解するために、クラスター動作のメカニズムを理解しましょう。したがって、アクティブノードはインターフェイス上のパケットをカウントし、割り当てられた時間内にパケットがない場合は、testipにpingを送信します。 pingが成功した場合はカウンターが再起動され、合格しなかった場合はインターフェース障害が登録され、アクティブノードが再起動します。同時に、パッシブノードはfailover.ini（アクティブノードとパッシブノードが受信するアドレスを含むクラスター構成ファイル）に記述されているすべてのインターフェイスで通常のARP要求を送信します。少なくとも1つのアドレスのARPレコードが消えると、パッシブノードはアクティブモードに切り替わります。



クラスターの問題に戻りましょう。まず、アクティブモードに切り替えない簡単なものから始めます。アクティブノードがないが、そのMacアドレスがARPテーブル（inet show mac-address-table）のパッシブノードにまだ存在する場合は、スイッチ管理者に移動する必要があります（ARPキャッシュがこのように構成されているか、何らかの障害です。 ）。パッシブノードの周期的なリロードはもう少し複雑です。これは、パッシブがARPレコードをアクティブと見なさず、アクティブモードになり、（注意！）HBリンクを介してネイバーをポーリングするために発生します。しかし、隣人はアクティブモードであり、稼働時間が長くなっています。この時点で、パッシブノードは、状態の競合が発生したために何かが間違っていることを認識し、再起動します。これは無期限に続きます。この問題が発生した場合は、failover.iniのIPアドレス設定とスイッチングを確認する必要があります。コーディネーターのすべての設定が正しい場合は、ネットワークエンジニアを質問に接続します。

交差する住所

私たちの実践では、異なるコーディネーターの背後にあるトンネルアドレスの交差点に遭遇することがよくあります。







ViPNet製品のアドレスの仮想化があるのはそのような場合です。仮想化は、1対1の接続または範囲間の状態を監視しない一種のNATです。デフォルトでは、この機能はコーディネーターでは無効になっていますが、隣接するコーディネーターのセクションの「to」の後の「tunnel」行のiplir.confで潜在的な仮想アドレスを見つけることができます。リスト全体でグローバルに仮想化を有効にするには、[visibility]セクションで、「tunneldefault」パラメーターを「virtual」に変更します。特定のネイバーを有効にする場合は、パラメータ「tunnelvisibility = virtual」をその[id]セクションに追加する必要があります。また、tunnel_local_networksパラメーターが「on」に設定されていることを確認することも価値があります。仮想アドレスを編集するには、tunnel_virt_assignmentパラメーターを「手動」モードに設定する必要があります。反対側では、同様のアクションを実行する必要があります。 「usetunnel」および「exclude_from_tunnels」パラメーターもトンネル設定を担当します。実行した作業の結果は、前述の「iplirdiag」ユーティリティを使用して確認できます。



もちろん、仮想アドレスには不便が伴うため、インフラストラクチャ管理者はその使用を最小限に抑えることを好みます。たとえば、組織が一部の政府機関の情報システム（IS）に接続すると、これらの組織には、ISアドレスプランからのトンネルの固定範囲を含むDSTファイルが発行されます。ご覧のとおり、接続者の希望は考慮されていません。このプールにどのように収まるか、誰もが自分で決めます。誰かがワークステーションを新しいアドレス指定に移行し、誰かがホストからコーディネーターへの途中でSNATを使用します。一部の管理者がSNATを使用して下位プラットフォームのライセンス制限を回避することは周知の事実です。このような「ライフハック」の倫理を評価することは約束しませんが、プラットフォーム自体のパフォーマンスにはまだ限界があることを忘れないでください。過負荷になると、通信チャネルの品質が低下し始めます。

GREが機能しない

もちろん、すべてのITソリューションには、サポートされるユースケースに独自の制限があり、ViPNetコーディネーターも例外ではありません。かなり厄介な問題は、SNATを介して複数のソースから同じ宛先にGRE（およびそれを使用するプロトコル）を機能させることができないことです。たとえば、銀行のパブリックアドレスへのPPTPトンネルを設定する銀行クライアントシステムを考えてみましょう。問題は、GREプロトコルがポートを使用しないため、トラフィックがNATを通過した後、そのようなトラフィックのソケットペアが同じになることです（宛先アドレスが同じで、プロトコルが同じで、送信元アドレスを1つのアドレスに変換しただけです）。コーディネーターは、エラー104のバックグラウンドでトラフィックをブロックすることでこれに対応します-接続はすでに存在します。次のようになります。







したがって、複数のGRE接続を使用している場合は、それらの接続にNATを適用しないようにする必要があります。最後の手段として、1：1のブロードキャストを実行します（ただし、これはパブリックアドレスを使用する場合はかなり非現実的な解決策です）。

時間を忘れないでください

イベント番号4-IPパケットタイムアウトでのブロッキングのトピックを続行します。ここではすべてが平凡です。このイベントは、ViPNetネットワークノード（コーディネーターとViPNetクライアント）間の絶対（タイムゾーンを除く）時間の間に不一致がある場合に発生します。HWコーディネーターでは、最大差は7200秒で、IPlir構成ファイルの「timediff」パラメーターで設定されます。この記事ではHW-KBコーディネーターについては考慮していませんが、KB2バージョンではtimediffがデフォルトで7秒、KB4では50秒であり、イベントが生成されない可能性があります4が、112であるため、混乱する可能性があります。 「通常の」ハードウェアに慣れているエンジニア。

暗号化されたトラフィックではなく、暗号化されていないトラフィック

初心者にとって、IPパケットログで22イベント（ネットワークノードからの暗号化されていないIPパケット）の性質を理解するのは難しい場合があります。これは、コーディネーターがこのIPアドレスからの暗号化されたトラフィックを期待していたが、暗号化されていないトラフィックが来たことを意味します。ほとんどの場合、次のように発生します。

1. ViPNet-, , . IPlir , , , . , : ViPNet-, – . , , , . , , , ViPNet-, . , ViPNet-, ;
2. . , , ( ). , , , ;
3. . , . , «» . , , , 22 .

(ALG)

ViPNet Coordinatorを含む多くのファイアウォールでは、SIPがNATを通過する際に問題が発生する可能性があります。仮想アドレスが内部NATである場合、明示的にNATが使用されておらず、仮想アドレスのみが使用されている場合でも問題が発生する可能性があります。コーディネーターには、これらの問題を解決する必要のあるアプリケーションプロトコル処理（ALG）モジュールがありますが、必ずしも希望どおりに機能するとは限りません。ALGのメカニズムについては詳しく説明しません（このトピックについては別の記事を書くことができます）。原則はすべてのITUで同じであり、アプリケーションレベルの見出しのみが変更されます。コーディネーターを介してSIPプロトコルを正しく操作するには、次のことを知っておく必要があります。

• NATを使用する場合は、ALGを有効にする必要があります。
• 仮想アドレス指定を使用する場合、仮想可視性が片側のみに設定されている場合でも、対話に参加する両方のノード（コーディネーター-コーディネーター、コーディネーター-クライアント）でALGを有効にする必要があります。
• 実際の可視性を使用し、NATがない場合は、SIPに干渉しないようにALGをオフにする必要があります。
• ALGの3.x行と4.x行には互換性がありません（厳密に言えば、3.x行ではそれを制御する方法がまったくありませんでした）。このようなシナリオでは、ベンダーはSIPの正しい動作を保証できません。

モジュールは、特権モード（有効）からの「algモジュール」グループのコマンドによって制御されます。

最後に

私は最も差し迫った問題を検討し、そのルーツを特定し、解決策について話そうとしました。もちろん、これらはViPNetのすべての機能からはほど遠いので、恥ずかしがらないことをお勧めします。サポートに連絡し、コミュニティ（ベンダーのフォーラム、電報チャネル、この投稿の下のコメント）でアドバイスを求めてください。また、ViPNetを使用する際のすべての困難に飛び込みたくない場合、または面倒な場合は、いつでもViPNetネットワークの管理を専門家に任せることができます。



著者：Igor Vinokhodov、第2管理ラインのエンジニア、Rostelecom-Solar