Загрузка...

ZPA Architecture in 2 Minutes | Quick & Easy Overview

In today video lets discuss Zscaler private access architecture in detail, before going to the flow lets understand few nodes in Zscaler private access.
Zscaler client connector (ZCC): It is software installed in PC, this software is responsible for sending configured application traffic towards Zscaler cloud.
Broker: This is Second ZPA node, ZCC sends traffic to this broker where it will check if the user is allowed to access this application or not.
App connector: This is basically linux server, which is deployed by customer. It should have access to end applications defined in ZPA portal
Dispatcher: Broker has to forward the connection to app connector, but it is not sure which app connector can reach application, so it will contact dispatcher. Dispatcher has idea on which app connector can reach the application. So dispatcher will forward request to respective app connector and this app connector will initiate tunnel to the broker user connected to .
Basically how zscaler private access work means
1. User has to install Zscaler client connector
2. In Zscaler client connector private access has to be turned on.
3. FQDNs defined in application segment download in user machine.
4. When user access respective FQDN, then PC initiates DNS request.
5. ZCC intercept that DNS request and assign synthetic IP to that FQDN.
6. Here synthetic IP means dummy IP address which we will define in Zscaler client connector portal. For every ZPA FQDN ZCC will assign dummy IP from same pool.
7. Then client initiates get request to fetch the web page, this request destination would be synthetic IP.
8. This request reach broker, broker will evaluate access policy and verify if the user is allowed to access the application or not.
9. If user is allowed to access this application, it will initiate request to dispatcher which forward request to app connector, then app connector will initiate tunnel to the user broker.
10. So in ZPA there will be two SSL tunnels, one from user to broker and another from app connector to user broker.
11. Within these tunnels, user traffic will be flowed.
12. I mean, get request sent from user machine to end server, would reach broker first. Broker forwards same request to app connector through the tunnel which is initiated by app connector and app connector relays same request to the server.
13. Now server respond back to the client through the same path.
14. Ideally client will access multiple ZPA applications, each FQDN would be assigned with different synthetic IP by ZCC and every FQDN request will be assigned with unique tag ID.
Tag ID is nothing but small number, for every FQDN request it will assign unique number.
We can trace this connection using that number in broker console logs.

#VPNReplacement #NoVPN #ZeroTrustNetworkAccess #AppAccess #SecureApps #PrivateApps #WorkFromAnywhere #HybridWork #digitaltransformation
#ZscalerTutorial #ZPATutorial #CyberSecurityTraining #ITTutorial #learncybersecurity
#TechExplained #BeginnerToAdvanced #HandsOnLabs
#Tech #Technology #Cloud #Networking #Security #IT #Innovation #FutureOfWork #enterpriseit

Видео ZPA Architecture in 2 Minutes | Quick & Easy Overview канала Netsechub Animated Videos
Яндекс.Метрика
Все заметки Новая заметка Страницу в заметки
Страницу в закладки Мои закладки
На информационно-развлекательном портале SALDA.WS применяются cookie-файлы. Нажимая кнопку Принять, вы подтверждаете свое согласие на их использование.
О CookiesНапомнить позжеПринять