Mikrotik RouterOSとKerio Controlの間にフェールセーフIPSec VPNトンネルを作成する





Kerio Controlのバージョン8.1以降では、独自のKerio VPNプロトコルを使用してVPNトンネルを作成できるだけでなく、完全に正しいIPSecも使用できます。 そしてもちろん、私はすぐにMikrotikとKerio Controlを横断したかったのです。



この記事では、いくつかの接続スキームについて説明します。 だから、最初のスキーム。



2つのサブネットを結合します。 簡単です。



そしてすぐに接続の方向のトピックに関する小さな余談。 つまり トンネルのどちらの端が受け入れ、VPN接続を開始します。 Kerio ControlとMikrotikに複数のWANインターフェイスがある場合、Kerio Controlが接続を開始するスキームは、VPNトンネルの耐障害性の提供を簡素化するために選択されます。 これについては、この記事の第4部で詳しく説明します。 いずれの場合も、事前定義されたキー(パスワード)を使用した認証を使用します。



RouterOS 6.1上のKerio ControlとMikrotik RouterBoardの間でIPsecについて接続するには、次の設定でControl側に新しいIPsecトンネルを作成する必要があります。









Mikrotik側でトンネルを設定するには、Winbox経由でルーターに接続し、IKE、IPSec-esp、IPSec-ah、または一時的にすべてのUDPトラフィックのデバッグを許可するファイアウォールルールを追加する必要があります(すべてのUDPを許可することはお勧めしません-怒っている人はDNSフォワーダーとして使用され、少なくとも)入力チェーン内。 これを行うには、ターミナルウィンドウで次のコマンドを実行する必要があります。



/ip firewall filter add chain=input comment="Allow IKE" dst-port=500 protocol=udp





/ip firewall filter add chain=input comment="Allow IPSec-esp" protocol=ipsec-esp





/ip firewall filter add chain=input comment="Allow IPSec-ah" protocol=ipsec-ah





/ip firewall filter add chain=input comment="Allow UDP" protocol=udp







コマンドの結果は、ファイアウォールフィルタールールが追加されます。 これは誰にとっても明らかだと思いますが、初心者にとっては、これらのルールは入力チェーンの禁止ルールよりも上にあるべきだと思います。 私の例では、上記のルールは13です。







次に、IPsec構成の暗号化ポリシー(提案)を編集(または作成)する必要があります。 図に従って設定を行うか、ターミナルウィンドウで以下に示すコマンドを実行します。







これは、既存のポリシー値を編集するチームです。 プロポーザルにデフォルト値がない場合(空の場合、なし)、図に従って作成する必要があります。 この場合、コマンドを実行する必要はありません



/ip ipsec proposal set [find default=yes] enc-algorithms=3des,aes-128 pfs-group=none







ピアを設定する必要があり、特にこれについて詳しく説明します。 ルーターOSバージョン6.0以降では、IPsecピアおよびIPSecポリシーに関する一部の設定が変更されていることに注意してください。 特に、ピア設定に新しいオプションが追加されました。 ピアの場合、Mikrotikが接続を開始するか受け入れるかを指定できます(Kerio Controlのアナログ/パッシブ)。 注意点は、GUIから「パッシブ」パラメーターを設定できないことです。 Winboxにも、ルーターを管理するためのWebベースのインターフェイスにもありません。 デフォルトでは、Winboxを介してピアを作成すると、ピアがアクティブになり、設定で指定されたアドレスへの接続の確立を継続的に試行し始めます。 したがって、トンネルのパッシブエンドを作成するには、CLIを使用し、ターミナルウィンドウでコマンドを実行する必要があります。「パスワード」の代わりに、設定時にKerio Control側で指定した事前定義キーを指定する必要があります。



/ip ipsec peer add address=109.172.42.XXX/32 dh-group=modp1536 exchange-mode=main-l2tp generate-policy=port-override hash-algorithm=sha1 passive=yes secret=password







コマンドの結果は、接続を待機している作成済みのピアになります。 WANインターフェイスがNATプロバイダーの背後にある場合、NAT-Travesalチェックボックスを設定します







ピアを構成するときに、IPsecポリシーを自動的に生成するオプションを指定しました。 したがって、/ ip ipsecポリシーに何も作成する必要はありません。 接続が確立されると、必要なポリシーが自動的に作成されます。 Kerio Controlのトンネル設定で有効にすることを忘れていない場合、これはピアを追加した直後に発生します。

その後、Kerio Control側のトンネルは「接続済み」ステータスになります。 Mikrotikの[ポリシー]タブで、リモートネットワークおよびローカルネットワークでKerio Controlを構成するときに指定されたサブネットに対して自動的に作成されたポリシーが表示されます。 「Installed SAs」では、トンネルの終端が「友人」であることがわかり、最後に「Remote Peers」で接続ステータスが表示されます。











トンネルがインストールされます。 ただし、Kerio ControlとMikrotikの背後のサブネット間をトラフィックが通過するには、トンネルに送信するトラフィックのマスクを許可しないルールをファイアウォールのNATルールに追加する必要があります。 このルールを作成しないと、トンネルがインストールされていても、ネットワークは友達になりません。 これを行うには、ターミナルウィンドウで次のコマンドを実行する必要があります。



/ip firewall nat add chain=srcnat dst-address=192.168.10.0/24 src-address=192.168.88.0/24







重要! ルールは、マスカレードのルールよりも上でなければなりません。 つまり、NATルールのリストの最上位になります。



その後、サブネット192.168.88.0/24と192.168.10.0/24の間の内部アドレスでの接続が機能するはずです。 これで、2つのサブネット間のトンネルの構成が完了しました。 しかし、それは簡単でした。 もっと面白い...



Mikrotikのネットワーク統合とKerio Controlの複数のVPNネットワーク



Kerio VPNプロトコルを使用する他のVPNトンネルを使用してセントラルオフィスに接続されているKerio ControlのローカルネットワークにMikrotikのローカルネットワークアクセスを提供する必要がある場合、より複雑なオプションを考えてみましょう(たとえば)。 サンプルの図を下の図に示します。







それは簡単に思えますか? Kerio ControlでVPNトンネルを設定するには、Mikrotikのローカルネットワークからアクセスする必要があるすべてのサブネットのリストと、本社がすでに知っている「ローカルエリアネットワーク」リストを追加するだけです。 そして、それに応じて、たとえば「アドレス一覧」でそのようなアドレスのグループを作成し、ルールの宛先でこのグループを指定することにより、MikrotikのNATルールのアドレス範囲を拡大します。



トンネルを追加、再インストールします。 トンネルが確立されたことがわかり、IPsecポリシーにより、Kerio Control側のトンネル設定で指定したすべてのサブネットに楽しい自動ポリシーが追加されました。 インストール済みSAには、すべてのサブネット用に作成されたSAが表示されます。 ビンゴ しかし、ここにはありませんでした...



MikrotikでのIPsecのトピックに関するインターネットの思慮深い喫煙と、さまざまなタイプのルーターの背後のローカルネットワークの組み合わせにより、このスキームでは誰もが同じ問題を抱えていることが明らかになりました。 ほとんどすべてのタイプのIPSecルーターでは、トンネルは独立したネットワークインターフェイスであり、論理的です。 しかし、Mikrotikではなく、したがって、リモートサブネットへのパケットのルートを決定することは不可能です。 実際には、Kerio Controlと組み合わせて-Mikrotikは最後に追加されたSAを通じてパケットを永続的に送信しました。 パッケージは正直に中央オフィスに到着し、Kerio Controlはそこで廃棄されました。 この場合のMikrotikの動作のロジックの説明を見つけた記事はありませんでした。 私は、同じ結果が得られる可能性のあるオプションをすべて試しました。 ゼロで。 接続は1つのサブネットのみで行われ、トンネルのインストール中に最後のサブネットが自動的に追加されました。



ブレインストーム、失われた夢、 2日間の過酷な 5日間-背後。 以下に説明するソリューションの考えは、ソリューションの検索の2日目に私を訪問しましたが、最初は非常に曲がったソリューションとしてマークされました。 曲がった目に見える欠陥を少し後で説明する理由。 しかし、ご存知のように、魚のない状態で-そしてガンは魚です。



MikrotikがIPSecポリシーの1つのサブネットで完全に機能する場合、Kerio Controlサブネットマスクの背後にあるサブネットを論理的に結合する必要があります。 つまり Kerio Controlの背後にあるサブネットを1つに集約します。 サブネット192.168.10.0/24、192.168.20.0/24、192.168.30.0/24、および192.168.40.0/24のアドレスは同じサブネット192.168.0.0/18内にあり、トンネルを構成するときにこのサブネットを「ローカルネットワーク」リストに追加しますKerio Controlでトンネル接続を確立します。 Mikrotikは、単一のIPsecポリシーを作成し、単一のSAを作成します。 現在、彼はパケットの送信先を間違えることはありません。 pingテストは、Mikrotikを超えたネットワークの制御を超えたすべてのサブネットの可用性を示す必要があります。 MikrotikでICMPアクセシビリティをチェックする場合、WANインターフェイスからではなく、ブリッジなどからpingを開始する必要があります 。 これは非常によくある間違いであり、CTNTのスタイルでうめき声が聞こえますが、何も機能せず、私たち全員が死に、足が壊れ、尾が落ちます。



リモートVPNネットワークからMikrotikの背後のネットワークにパケットを返すには、トンネルに送信されるマスカレードパケットを許可しないMikrotikのルールに類似したものを追加する必要があります。 なぜなら VPNネットワークからMikrotikのネットワークへのすべてのトラフィックは中央ブランチのVPNインターフェイスから送られます。ソースをVPNアドレスからMikrotikが認識しているサブネットのアドレスに変更することにより、Mikrotikを欺くトラフィックルールが必要です。 図のルール。 アドレス192.168.10.2は、セントラルオフィスの内部ゲートウェイアドレスです。







その後、サブネット間のトラフィック交換はすべての方向に進みます。



次に、この方法の欠点について説明します。 このスキームでは、本社に接続されている特定のリモートサブネットに対してのみ、ローカルネットワークに「ルート」を提供することは不可能です(実際には、Mikrotikルーティングテーブルでリモートサブネットへの理解に通常のルーチンはないため、単語を引用符で囲むつもりです)。 理論的には、リモートサブネット上のアドレスをマスクを使用して1つに論理的に結合できない可能性があります。 なぜなら 通常、それらは異なるクラスのネットワークに属します。 膨大な数のアドレスが範囲に含まれるという事実により、理論的には、IPSecトンネル内ではないこの範囲の他のアドレスを使用する必要がある可能性がありますが、これは不可能です。 注意 、Mikrotikのアドレスがこの範囲内にある場合(!!!)、トンネルを設置すると、Mikrotikとの接続が失われます。 この場合、MACアドレスでWinboxを介してアクセスし、トンネルを無効にするか、Kerio Control側で無効にします。 その後、VPNトンネルのインストール時にContolから受信する範囲外にローカルMikrotikアドレスを移動するか、これ(つまり、Kerio Controlのローカルネットワーク集約のオプション)はまったく当てはまりません。



一般的に、解決策は不可能になるまで曲がっていると言えます。 曲がっていますが、動作しています。 既存のインフラストラクチャでは、ローカルサブネットアドレスを書き換える必要がある場合があります。 しかし、RouterOSの開発者には選択肢がありませんでした。 私の知る限り、長い間、WishlistでIPSecのインターフェイスを追加しています。 英語のフォーラムでは、涙と絶望に満ちた開発者への請願を繰り返し見てきました。



MikrotikルーターをVPNクライアントとして使用します



Mikrotikをクライアントとして使用すると、IPSecでのダンスやルーティングできないルーティングを忘れることができます。 ただし、Kerio ControlのローカルネットワークからMikrotikのネットワークにアクセスできないことに注意してください。 そしてこれは論理的です。 ことに注意してください Kerio Controlは、VPNクライアントを含む接続に対してライセンスされています-このタイプの接続は、ライセンスされた接続のカウンタを1つ減らします。 まあ、または単純な方法であれば-単一の接続ライセンスを使用します。



ここではすべてが非常に簡単です。 Kerio Controlでユーザーを作成するか、既存のユーザーを編集します。 [権限]タブで、[ユーザーはVPN経由で接続できます]チェックボックスをオンにします。







インターネットからL2TPプロトコルを使用してKerio Controlに接続できるようにするトラフィックルールにルールを追加するか、ソースを信頼できるアドレスのリストに制限できます。 この図では、リモート管理者の信頼できるアドレスのリストにのみ接続できます。







Mikrotik側では、ターミナルウィンドウでコマンドを実行して、新しいL2TPクライアントインターフェイスを追加する必要があります。



add comment="L2TP VPN Client" connect-to=109.172.42.XXX disabled=no max-mru=1460 max-mtu=1460 name=INTERFACE-NAME password=password user=username







アドレス、インターフェイス名、接続名、およびパスワードの値を、Kerio Controlアドレス、任意のインターフェイス名、およびユーザー設定で作成または編集したユーザー名/パスワードに置き換える必要があります。 コマンドの結果は、サーバーへの接続をすぐに確立する新しく作成されたインターフェイスになります。







新しいアドレスがMikrotikアドレスリストに表示され、Kerio Control VPNサーバーによって動的に割り当てられます。







MikrotikのローカルネットワークがKerio Controlのネットワークにアクセスできるようにするには、ルーティングテーブルに静的ルートを追加する必要があります。 これを行うには、ターミナルウィンドウでコマンドを実行し、インターフェイス名を既存のものに置き換えます。



/ip route add comment="Route to 192.168.20.0/24" distance=1 dst-address=192.168.20.0/24 gateway=INTERFACE-NAME





/ip route add comment="Route to 192.168.30.0/24" distance=1 dst-address=192.168.30.0/24 gateway=INTERFACE-NAME





/ip route add comment="Route to 192.168.40.0/24" distance=1 dst-address=192.168.40.0/24 gateway=INTERFACE-NAME







その結果、VPNインターフェイスを介してKerio Controlの背後にあるリモートサブネットに静的ルートが追加されます。



ここで、Mikrotikにマスカレードルールを追加します。 これを行うには、ターミナルウィンドウでコマンドを実行します。



/ip firewall nat add action=masquerade chain=srcnat out-interface=INTERFACE-NAME src-address=192.168.88.0/24







それだけです。Mikrotikの背後にあるローカルネットワークからKerio Controlの背後にあるネットワークと、他のVPNトンネルを介して接続されているすべてのネットワークへのアクセスが必要です。 自分のチームで私の値を修正することを忘れないでください。



VPNトンネルフェールオーバーの提供



まあ、甘いスナック。 トンネル復元力の組織についての約束された物語。 Kerio Control 8.1より前のアクティブな接続の構成では、トンネルの受信側の複数のアドレスを指定することはできませんでした。したがって、VPNトンネルのフォールトトレランスを確保するために、中央オフィスのKerio Controlが接続を受け入れるときにスキームに投票します。 この場合、セントラルオフィスの着信チャネルを監視し、ブランチが接続を確立する唯一のDNS名を自動的に変更することにより、フォールトトレランスを提供できます。 これには、DynDNSサービスとPRTGネットワ​​ークモニター監視システムを使用します。 この方法の概要は次のとおりです。 PRTGを使用して、セントラルオフィスのチャネルのアクセス可能性が確認され、ブランチが接続するチャネルが検出された場合、DynDNS APIを介して、PRTGはインターネット上のリンクをプルすることによりブランチが接続を確立するDynDNSサービスに登録されたDNS名を自動的に変更します。 作業方法は146%です。 セントラルオフィスにクラシックスターで接続された50以上のトンネルをチェックしました。 復旧する場合は、IPアドレスを元に戻すか、そのままにしておくことができます。 ここであなたが望むように。



Mikrotikの場合、同じことをすることも妨げているように思われますか? しかし、これはRouterOSの時流です。 ピア設定では、トンネルの受信側のDNS名を指定できますが、保存すると、IPアドレスとして解決および記録されます。 この場合、Kerio Controlで(PRTGではなく)チャネルを監視し、接続が確立されている現在のチャネルが使用できなくなった場合にピア設定を変更するスクリプトを作成する必要があります。 さらに、IPSecポリシーで多くのダンスをします。 そして、私はこれをひどいヘッドウォッシュだと思っています。



これで、Kerio Control自体は、接続を開始した場合に耐障害性を著しく提供できます。トンネル構成では、トンネルの受信側の複数のIPアドレス(またはDNS名)を指定できます。 したがって、Mikrotik側で接続を受け入れる2つのピアを作成することにより、目的のフォールトトレランスを実現できます。 まあ、私たちは街を運転しました...おおよその図が図に示されています。 WANインターフェイスがKerioまたはMikrotikのISPでドロップした場合、トンネルの存続可能性を確保する必要があります(混乱を避けるために異なる名前が付けられています)。







Mikrotikをセットアップすることから始めましょう。 なぜなら IPsecピア設定アドレスの値に含まれるDNS名を理解しないため、セントラルオフィスの両方のWANインターフェイスに対して2つのピアを作成する必要があります。 これを行うには、ターミナルウィンドウに移動してコマンドを入力し、アドレス値と定義済みのキーを独自のものに置き換えます。



/ip ipsec peer add address=109.172.42.XXX/32 dh-group=modp1536 exchange-mode=main-l2tp generate-policy=port-override hash-algorithm=sha1 nat-traversal=yes passive=yes secret=PASSWORD





/ip ipsec peer add address=95.179.13.YYY/32 dh-group=modp1536 exchange-mode=main-l2tp generate-policy=port-override hash-algorithm=sha1 nat-traversal=yes passive=yes secret=PASSWORD







記事の前の部分で示された指示に従って既にピアを作成し、CLIの代わりにWinboxを使用することを決定し、以前に作成されたピアをコピーした場合、パッシブ設定(Mikrotikが接続を開始するか受け入れるかを決定する設定)はコピーされないという事実に注意してください。 したがって、この時点で、コマンドラインツールを使用することを強くお勧めします。 コマンドの結果は、Kerio Controlからの接続を待機する2つのピアの作成に成功するはずです。



しかし、これでは十分ではありません。 WAN1がKerio Controlに該当する場合、トンネルは正常に再インストールされますが、ISP1がMikrotikに該当する場合、Mikrotik ISPインターフェイスでグレーのISP IPを指定したKerio Controlのトンネル設定の「リモートID」は実際の値と一致しません。 また、正常に再接続する代わりに、Kerio Control管理コンソールで「IDミスマッチ」というすばらしいエラーが表示されます。



待ち伏せ? 待ち伏せ...そして、私は思考の噴水がなくなったので、ほとんど絶望しました、私はこのIDの変更を自動化する方法を絶対に理解しませんでした。 hostsファイルを使用しましたが、役に立ちません。 おそらく、毛むくじゃらの年に私に言った、完全に白髪のお尻を持つ賢い叔父の言葉を思い出す時が来ました-何も助けなければ、マニュアルとログを調べる時が来ました。 まあ...マニュアルは私たちのものではありません(ここで著者のホメリックの笑い声)、彼は以前にIPSecに関連するすべてのメッセージが含まれていたKerio Controlデバッグログに登りました。 私は何を言うことができます-シーカー、彼にそれを見つけさせてください。 私たちの場合、「リモートID」パラメーターがトンネルの接続先IPアドレスに応じて動的に変更できる場合、Kerio Controlトンネル設定で、リモートIDに値「%any」を指定できます。

ホスト名には、下図のように、MikrotikのすべてのアドレスISP1およびISP2をセミコロンで入力し、「リモートID」に値「%any」を入力します。







保存し、適用し、幸せな目で、「接続済み」のトンネルの変更されたステータスを見て、検証に進みます。 バックアップチャンネルとメインチャンネルの場所を変更することにより、Kerio Controlのメインチャンネルの崩壊をエミュレートします。トンネルは再接続され、生きていました。 Mikrotikのメインチャンネルの崩壊は、プロバイダーのレースを引き抜くことによってエミュレートします。 Kerio Controlがトンネルがなくなったことを習得している間-約2分かかりましたが、彼はまだVPNを予備に持っていきました。 ビンゴ!



すべての実験は、Kerio Control 8.1およびRouterOS 6.1で実行されました。 ここに示されている端末コマンドの変数名とROS設定は、このバージョン(6.1)に対応しています。 現在、バージョン6.10では設定名がいくつか変更されていますが、Kerio Control 8.2およびRouterOS 6.10の現在のバージョンでは最小限のチューニングですべてが機能します。 上記のすべては、クレイジーなIT専門家の賞賛よりもわずかに少ないかもしれません。正しい言葉遣いや定義を装うわけではなく、コメントや推奨事項を喜んで受け入れます。なぜなら、私にとって、Mikrotikは、ほとんど読んでいる本であるKerio Controlとは異なり、新しい神秘的な動物だからです。




All Articles