PQDN を使用してプライベート アプリ セグメントにアクセスする

ZTNAベースのソリューションに移行する際、ユーザーにとってこれまでと同じユーザーエクスペリエンスを維持したいと考えるかもしれません。よくある要件の一つに、PQDN（短い名前）によるアプリケーションアクセスをサポートする機能があります。例えば、 app1.example.comの代わりに、ユーザーはブラウザに「app1」と入力することができる。

マルチ検索ドメインサポート機能が有効になっている場合、 Netskope Clientアクセスをサポートします PQDN。 Netskope Client 、複数の検索ドメインを（上から下へ）順に反復処理し、検索ドメインを追加した後にドメインを検証することができます。

複数ドメイン検索機能はどのように動作しますか？

• この機能を利用するために、ウェブUIで追加の設定は必要ありません。
• Netskope Client個々の検索ドメインに対してDNSリクエストを（リストを順に処理しながら）パブリッシャーにトンネル接続することで、ドメイン解決を傍受および検証します。
• SRP内のドメイン一致がパブリッシャー上で解決可能な場合にのみ、スタブIP（ 100.64.0.0/16 ）を割り当てます。
• パブリッシャーがNXDOMAINを返した場合、DNSリクエストはローカルネットワークに送り返されます。
• 有効な（スタブIP – 100.64.0.0/16 ）応答はクライアントによってキャッシュされます。
• パブリッシャーのDNS検証は引き続き有効であり、パブリッシャー上でドメインが解決可能な場合は、実際のIPアドレスが割り当てられます。

重要な考慮事項

• この機能を使用するには、ワイルドカードアプリ検証機能が有効になっている必要があります。この機能は、マルチ検索ドメインサポート機能と同時に自動的に有効になります。ただし、ワイルドカードアプリ検証機能が明示的に無効になっている場合、マルチ検索ドメインサポートは動作しなくなります。
• アプリに割り当てられたパブリッシャー間では、DNSサーバーの設定と名前解決が同一であることが想定されます。
• 有効な検索ドメインが複数一致する場合、トップダウンで最初に見つかった有効なドメインのみが有効になります。
• 検索ドメインの管理と制御は、 Netskope Clientではなく、管理者が行うべきです。
• ユーザーが入力したドメイン（PQDNまたはFQDN）がSRP内のワイルドカードアプリ定義と一致する場合、 Netskope Client DNSリクエストをパブリッシャーに送信し、ドメインが解決可能かどうかを判断します。 この機能におけるFQDNの動作については、以下のシナリオ2および3で説明します。基本的に、複数検索ドメインのサポートが有効になっている場合でも、FQDNによるアクセスは引き続き機能します。

ユースケース

Scenario 1

• プライベートアプリセグメントの定義: *.acme.com (ワイルドカードアプリの定義)。
• ネットワークアダプタに設定されているDNS検索ドメイン（順不同）： *.acme.com 、 *.acme.local 、 *.eu.acme.com
• エンドユーザーはブラウザにjira （PQDN）を入力してアプリにアクセスします。エンドユーザーが接続しようとしているドメインはjira.eu.acme.comです。

期待される動作は以下のとおりです。

Step	デスクリプション
1	Netskope Clientネットワークアダプタに設定されているすべての検索ドメインを学習します。
2	Netskope Client 、サフィックスドメインを上から下へ追加し、DNSリクエストを検証のためにパブリッシャーへトンネル送信します。
3	SRPに一致する最初のDNSリクエストはjira.acme.comです。パブリッシャーはクライアントにNXDOMAINを返します。
4	次の接尾辞ドメイン*.acme.local SRP と一致しないため、次のドメインに進みます。
5	クライアントは次のサフィックスドメイン*.eu.acme.com （SRP一致）を試行し、DNSリクエストをパブリッシャーにトンネルします。
6	パブリッシャーでjira.eu.acme.comの解決が成功すると、クライアントに通知が届き、有効な検索ドメインの位置が判明し、スタブIPが割り当てられてキャッシュされます。アプリへのアクセスに成功しました。

Scenario 2

• プライベートアプリセグメントの定義: *.acme.com (ワイルドカードアプリの定義)。
• ネットワークアダプタに設定されているDNS検索ドメイン（順不同）： *.acme.com 、 *.acme.local 、 *.eu.acme.com
• エンドユーザーはブラウザにjira.eu.acme.com （FQDN）を入力してアプリにアクセスします。

期待される動作は以下のとおりです。

Step	デスクリプション
1	Netskope Clientネットワークアダプタに設定されているすべての検索ドメインを学習します。
2	Netskope Client 、サフィックスドメインを上から下へ追加し、DNSリクエストを検証のためにパブリッシャーへトンネル送信します。
3	アプリ定義マッチングリクエストがワイルドカード(このケースでは *.acme.com)であり、この機能が有効になっている場合、パブリッシャーに最初に送られるDNSリクエストは jira.acme.com 用であり、 jira.eu.acme.com用ではありません。 パブリッシャーは、 jira.acme.comに対してNXDOMAINクライアントに返します。
4	次の接尾辞ドメイン*.acme.local SRP と一致しないため、次のドメインに進みます。
5	クライアントは次のサフィックスドメイン*.eu.acme.com (SRP 一致) を試行し、 jira.eu.acme.comの DNS リクエストをパブリッシャーにトンネルします。
6	パブリッシャーでjira.eu.acme.comの解決が成功すると、クライアントに通知され、リスト内の有効な検索ドメインの位置が判明し、スタブIPが割り当てられてキャッシュされます。アプリへのアクセスに成功しました。

Scenario 3

• プライベートアプリセグメントの定義: jire.eu.acme.com (FQDNアプリ定義)。
• ネットワークアダプタに設定されているDNS検索ドメイン（順不同）： *.acme.com 、 *.acme.local 、 *.eu.acme.com
• エンドユーザーはブラウザにjira.eu.acme.com （FQDN）を入力してアプリにアクセスします。

期待される動作は以下のとおりです。

Step	デスクリプション
1	ユーザーが入力したFQDNはアプリの定義と完全に一致するため、それ以上の検証は不要です。これは、DNSリクエストがパブリッシャーに転送されないことも意味します。
2	Netskope Client jira.eu.acme.comにスタブIPを割り当て、キャッシュします。 アプリへのアクセスに成功しました。