Skip to main content

 

 

 

 
Language:
 
 
 
OutSystems

VPN接続およびトラブルシューティングガイド

概要

OutSystemsのVPNは完全に自動化されたオーケストレーションサービスであり、可能な構成のセットが定義されています。

最初の構成手順を完了した後に問題が発生した場合は、いくつかのトラブルシューティング手順を実行して対処する必要があります。この記事は、そのようなプロセスを支援することを目的としています。

要件

VPNの構成自体を開始する前に、VPNデバイス/ファイアウォールがOutSystems Cloudとユーザーのプライベートネットワークの間にVPN接続を確立するための要件をすべて満たしている必要があります。OutSystemsは、OutSystemsのVPNの要件を満たしている場合に限り、ユーザーの提案を受け入れます。

名前解決ソリューション(DNS解決)

VPNの設定中に、OutSystemsは以下の目的で使用する内部DNSサーバーをプロビジョニングします。

  1. プライベートIPアドレスではなくデフォルトのパブリックドメイン名を使用して、VPN経由で環境に接続します。これにより、VPN経由の接続を維持しながら、内部ロードバランサを使用して環境に接続できるようになります。これを実現するには、以下の情報を使用して条件付きフォワーダをユーザーのネットワークに設定する必要があります。

    • DNSサーバー: 最初のVPN構成で詳述されているとおり

    • プロトコル/ポート: UDP 53

    • 解決対象のドメイン: outsystemsenterprise.com

  2. OutSystems CloudのDNSサービスを使用して、ユーザーのネットワークのローカルドメイン名(ネットワークにローカルアクセスでき、公開されていないホスト名に対応)を解決します。これが必要な場合は、条件付きフォワーダの構成をリクエストできます。このサービスを選択する場合は、以下の詳細を指定する必要があります。

    • オンサイトDNSサーバーのプライベートIPアドレス

    • オンサイトDNSサーバーのポートとプロトコル(UDP/TCP)

    • Cloud環境から解決する内部ドメイン(例: company.local)

安定した接続の確立

OutSystems Cloudへの安定したVPN接続を確立するには、以下を考慮する必要があります。

  1. ユーザーのネットワークからVPNトンネルに一定のインバウンドトラフィックがあることを確認します。OutSystems CloudのVPNは「レスポンダ」としてのみ機能できます。つまり、VPNトンネルをアクティベートして接続をアクティブな状態に保つには、ユーザーのネットワーク側が常にトラフィックの「イニシエータ」である必要があります。

  2. OutSystemsのVPNは、セキュリティアソシエーション(SA)の単一のペア(インバウンド/アウトバウンド)のみをサポートできます。つまり、OutSystems Cloudで指定する内部サブネットが複数ある場合、それらを単一のIP範囲にまとめるか、または「任意」のケース(0.0.0.0/0)を使用する必要があります。その後、制限付きのセキュリティポリシーがある場合には、ファイアウォールのACLルールを実装して、内部ネットワークに到達できるIPアドレスの数を制限できます。

    • たとえば、ポリシーベースのルーティングを使用している場合は、暗号化ドメインの送信元ネットワークと送信先ネットワークを単一のセキュリティアソシエーション(SA)に正しく定義したことを確認します。

    • 同様に、VPNトンネルがルートベースの場合は、フェーズ2のIPSEC SAで単一のルートペア(インバウンド/アウトバウンド)を正しく構成したことを確認します。

  3. フェイルオーバーの目的で両方のトンネルがアクティブになっている場合、VPNデバイスはプライマリトンネルからトラフィックを受信し、セカンダリトンネルを介してレスポンスを返すことができるため、非対称ルーティングがサポートされていることを確認します。この動作は変更できません。これを回避するには、以下のいずれかのシナリオに従います。

    • VPN静的ルート: アクティブ/パッシブ設定を使用して、VPN接続ごとに一度に1つのトンネルのみがアクティブ/稼働中になります。これにより、両側が同じトンネルを使用してネットワーク間のトラフィックをルーティングすることができるようになります。フェイルオーバーのために、VPNの監視でデッドピア検出(DPD)を使用して、アクティブなトンネルの稼働状況を追跡します。障害が検出された場合は、フェイルオーバーをトリガーして2番目のトンネルを起動し、プライマリトンネルを停止した状態でトラフィックをルーティングする必要があります。

    • 動的VPN(BGP): いずれかのトンネルでAS-PATHプリペンドまたはBGP Local Preferenceを使用して、どのトンネルでOutSystemsのVPNにトラフィックを送信するかを制御します。

VPN接続のトラブルシューティング

必要な構成と推奨事項をすべて実行してもVPNの不安定性または接続性の問題が解決しない場合は、一般的な状況と解決策を示す以下のリストを見直してください。

VPNトンネルの非アクティブ状態または不安定性に関する問題の一般的な原因

  • インターネットプロトコルセキュリティ(IPSec)のデッドピア検出(DPD)の監視の問題。

  • VPNトンネルのトラフィックが少ないため、またはベンダー固有のファイアウォールデバイスの構成に問題があるために発生するアイドルタイムアウト。

OutSystemsのVPNには、定期的にトンネルのアクティブ状態を検証するDPDと呼ばれるメカニズムがあります。これにより、ネットワークが連続して3つのDPDリクエストに応答しない場合は、ピアが停止しているとみなされて、トンネルが自動的に閉じられます。

解決策

デッドピア検出(DPD)の設定を調べ、以下のようになっていることを確認します。

  • DPDメッセージを受信して応答するように構成されている。
  • OutSystemsのVPNのピアからのDPDメッセージに応答できないほどビジー状態ではない。
  • ファイアウォールでIPS機能が有効になっているため、DPDメッセージのレートが制限されていない。

IKEv2の使用中に60分間隔でトンネルがドロップする

解決策

フェーズ2のライフタイムの設定を60分ではなく51分に変更します。これは確認されている既知のパターンであり、この回避策により問題が軽減されます。

フロントエンドサーバーまたはデータベースにpingを実行する

セキュリティ上の理由から、OutSystems Cloud環境のフロントエンドとデータベースサーバーへのICMPリクエストは許可されていません。

OutSystemsのセキュリティルールでは、OutSystems CloudのDNSサーバーへのICMPリクエスト(ping)のみが許可されています。OutSystems Cloudの他のすべてのサーバーは、ICMPリクエストに応答しません。

解決策

OutSystems CloudのDNSサーバーにpingを実行すると、VPN接続でキープアライブを行ったり、両方のサイト間の接続をテストしたりすることができます。

$ ping -t <DNSサーバーのプライベートIPアドレス>

詳細については、以下の「VPN接続のテストに関する一般的な問題」セクションをご覧ください。

VPN接続のテストに関する一般的な問題

設計上、またセキュリティ上の理由からも、環境のフロントエンドサーバーへの直接アクセスは許可されていません。

OutSystemsは、非静的IPアドレスに解決する内部ロードバランサ経由のトラフィックを強制した後、トラフィックを環境のフロントエンドマシンにリダイレクトします。

解決策1

  1. *VPNにアクセスできるプライベートネットワークからOutSystems CloudのDNSのプライベートIPアドレスに直接*pingを実行します。この情報は、最初のVPN構成の設定で指定されます。

    $ ping <DNSサーバーのプライベートIPアドレス>

1.内部ネットワークからDNSのプライベートIPアドレスまたはドメインにtracerouteユーティリティを実行します。

* 内部ネットワークに関連付けられたIPアドレスで出力が停止する場合は、VPNエッジデバイスへのルーティングパスが正しいことを確認します。

* 出力がファイアウォールデバイスに到達してもDNSサーバーのプライベートIPアドレスに到達しない場合は、VPNデバイスの設定を確認します。ここで、構成自体やポリシーのNAT設定が正しいかどうかを確認します。

```$ traceroute  <DNSサーバーのプライベートIPアドレス>```

解決策2

このオプションの場合、要件セクションで説明したDNSの条件付きフォワーダが事前に構成されていることを確認してください。

1.ポート80と443のTCP/IPネットワークプロトコルでOutSystems Cloud環境(outsystemsenterprise.com)の完全修飾ドメイン名(FQDN)のいずれかに対してtelnetセッションを実行します。Sentryエディションの場合は、ポート443のみが許可されています。

```$ telnet  example-dev.outsystemsenterprise.com 443```

1.OutSystems Cloud環境のFQDNのいずれかに対してnslookupコマンドを実行して、名前解決が機能しているかどうかを確認し、ドメイン名をプライベートIPアドレスに解決します。

```$ nslookup  example-dev.outsystemsenterprise.com```

OutSystems CloudのDNSサーバーにpingを実行する

DNSサーバーは、VPNが作成されるとすぐに、DNSのクエリおよびICMPリクエストへの応答に利用できるようになります。

設計上、OutSystems CloudのDNSサーバーは、ネットワークの送信元IPアドレスがVPNで構成されたルートに属している場合に限り、ICMPリクエストに応答します。

解決策

ユーザーのネットワークのサーバーが内部ネットワークから到達可能であることを確認し、ICMPリクエストを許可する必要があります。そのためには、ファイアウォールの設定やルーティングの要件を確認します(VPNの設定時に受信した最初の通知メールに従います)。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

外部データベースへの接続に関する問題

OutSystems Cloudのアーキテクチャは、設計上すべてのアウトバウンドトラフィックを許可し、フロントエンドマシンに対するインバウンドルールのフィルタリングのみを行います。そのため、ユーザーのネットワーク内のデータベース、サーバー、Webサービスには問題なく接続できるはずです。

解決策

VPNの内部から接続できない場合は、ご自身のネットワークチームとともに内部ファイアウォールの設定を確認し、インバウンドルールがOutSystems Cloudの内部IP範囲全体を許可しているかどうかを検証する必要があります。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

内部ネットワークからOutSystems Cloud環境に接続する方法

OutSystems Cloudはパブリッククラウドです。そのため、デフォルトでは、環境のホスト名はVPN接続の外部でパブリックアドレスに解決されます。パブリックホスト名を使用できるようにするには、そのホスト名を解決できるように内部ネットワークを構成する必要があります。

解決策

1.VPNの設定時に受信した通知メールに詳述されているように、内部DNSサーバーで条件付きフォワーダを設定する必要があります。つまり、メインドメイン名(*.outsystemsenterprise.com)の条件付きフォワーダとしてOutSystems CloudのDNSサーバーを使用する必要があります。

1.DNSサーバーの条件付きフォワーダの設定を見直して、適切に構成されているかどうかを確認します。

1.ユーザー側でプロトコルUDPとポート53を許可していることを確認します。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

ファイアウォールでOutSystems Cloudの内部IP範囲全体を許可する必要がある理由

内部ロードバランサのプライベートIPアドレスは静的ではなく、セキュリティ上の理由により頻繁に変更される可能性があります。この動作は変更できません。フロントエンドサーバーへの直接アクセスは許可されていないため、すべてのトラフィックはロードバランサからフロントエンドマシンに送信されます。

また、データベースサーバーのプライベートIPアドレスはメンテナンス時に変更されます。

解決策

OutSystems Cloudの内部IP範囲全体を許可して、プライベートIPが変更された場合でもサーバーにアクセスできることを保証します。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

フロントエンドのプライベートIPアドレスを取得する

OutSystemsでは、フロントエンドサーバーのプライベートIPアドレスを直接確認できません。

解決策

代わりに、[IP範囲の取得方法に関するオンラインヘルプ]をご覧ください。

VPNトンネルのフェーズ1のIKEネゴシエーションが失敗する一般的な原因

OutSystemsのVPNを設定すると、構成のインターネットキー交換(IKE)フェーズが失敗します。

解決策

1.VPNの設定を調べ、以下を確認します。

* フェーズ1のOutSystemsのVPNの要件をすべて満たしている。

* IKE(フェーズ1)のライフタイムを28800秒(480分または8時間)に設定している。

* 構成ファイルに指定された正しい事前共有鍵(PSK)でVPNデバイスを構成している。

* ファイアウォールデバイスからOutSystemsのVPNのエンドポイントにpingを実行できる。

1.VPNデバイスのエンドポイントがネットワークアドレス変換(NAT)の内側にある場合は、以下を確認します。

* ユーザーのネットワークから出ていくIKEトラフィックは、構成されたピアIPアドレスからUDPポート500で送信されている。この設定をテストするには、カスタマーゲートウェイデバイスでNATトラバーサルを無効にします。

* ポート500(およびNATトラバーサルを使用している場合はポート4500)のUDPパケットは、ユーザーのネットワークとOutSystemsのVPNのエンドポイントの間を通過できる。

* インターネットサービスプロバイダ(ISP)がUDPポート500と4500をブロックしていない。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

VPNトンネルのフェーズ2のインターネットプロトコルセキュリティ(IPsec)がネゴシエーションに失敗する

解決策

VPNの設定を調べ、以下を確認します。

1.フェーズ1のOutSystemsのVPNの要件をすべて満たしている。

1.カプセル化セキュリティペイロード(ESP)プロトコル50がブロックされていない(インバウンド/アウトバウンド)。

1.セキュリティアソシエーションのライフタイムが3600秒(60分)に設定されている。

1.IPsecトラフィックを妨げるファイアウォールのACLがない。

1.完全前方秘匿性(PFS)が有効になっている。

1.ポリシーベースのルーティングを使用している場合は、暗号化ドメインの送信元ネットワークと送信先ネットワークを正しく定義したことを確認する。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

OutSystemsによるトンネルのリセットとVPNの再起動の可否

この操作では根本的な問題は解決しません。OutSystemsのVPNは「レスポンダ」として機能し、トラフィックを開始したり、トンネルをリセットして接続を起動したりすることはできません。

トンネルをアクティベートして接続をアライブ状態に保つには、対象のトラフィックを生成することによって、またはキープアライブメカニズムをアクティベートすることによって、ユーザーのネットワークがVPNトンネルを開始する必要があります。

解決策1

VPNデバイスでキープアライブ機能を構成します。一部のファイアウォールにはキープアライブ機能がないため、代わりに連続的にpingを使用する必要があります(解決策2)。

解決策2

複数の内部サーバーから、最初の構成の設定通知で指定されたDNSサーバーのプライベートIPアドレスのいずれかに対して、5秒間隔で連続的にpingを実行します。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

VPN構成ファイルの使用に関する問題

OutSystemsは、構成を実行してVPNトンネルをアクティベートするのに十分な構成ファイルを提供します。

ただし、この情報がわかりにくい場合や、デバイスのソフトウェアバージョンの変更や更新によって設定や接続のトラブルシューティングが困難になる場合があります。

解決策1

最も一般的なVPNデバイスの構成例が多数記載された以下のリストをご覧ください。

解決策2

最も一般的なVPNデバイスに関する個別のトラブルシューティングガイドをご覧ください。

このトピックについては、ご自身のネットワークチームにお問い合わせください。

オンプレミスネットワークの内部IP範囲が変更され、OutSystems Cloud環境にアクセスできなくなった

VPNにアクセスするオンプレミスネットワークの内部IP範囲が(たとえば、動的VPNを使用しているために)変更された場合、新しいIP範囲からOutSystemsクラウド環境にアクセスできません。これは、OutSystemsセキュリティグループが以前のIP範囲で構成されているためです。

解決策

サポートケースを開いて、ユーザーのオンプレミスネットワークの新しいIP範囲を含めるようにしてください。

その後、OutSystemsが新しいIP範囲に従ってセキュリティグループを変更します。

その他のサポート

まだ動作していませんか?問題が解決しない場合は、OutSystems Supportにお問い合わせください

サポートケースを開いて、現在のVPN構成、VPNログの一部、または関連するエラーメッセージを含めるようにしてください。その後、サポートエンジニアが構成のトラブルシューティングを支援し、必要に応じて、すべての関係者との電話会議のスケジュールを設定して迅速に対処します。