안녕하세요,
최근에 제가 배우는 중에 Zscaler 설정을 인수하게 되었고, 전반적으로 ZCC에 관한 혼란을 해소할 수 있는 경험이 더 많은 사람이 있기를 희망합니다.
상황 설명을 위해 내부 모든 사이트에 GRE 터널이 설정되어 있고, 엔드포인트에 설치된 ZCC가 있는 두 개의 시험 사이트가 있습니다. 우리는 터널 2.0(터널 전용)과 웹 트래픽을 ACC 리스닝 프록시로 리디렉션하는 방식을 사용하고 있습니다. 포럼과 문서를 통해 읽은 바로는, 이것이 모든 http/https 트래픽을 ZCC 터널 1.0 리스닝 프록시로 리디렉션하는 것인가요? 즉, 컴퓨터와 클라이언트 간의 모든 트래픽이 터널 1로 처리됩니다.
앱 프로필과 연결된 포워딩 프로필에는 Zscaler 업데이트용 우회, 지역 락킹하며 적절한 프록시로 지역을 제한하는 PAC 파일이 있습니다. 또한 VPN 우회도 사용하고 있습니다.
사용자들이 ZCC 설치 후 401 권한 없음 요청 문제를 겪고 있는데, 이게 프록시와 패킷 형성 방법과 관련이 있다고 생각합니다(?).
어쨌든 질문입니다. 웹 트래픽 리디렉션 옵션이 있을 때, 모든 우회가 .PAC 파일을 통해 이루어지나요? 제 이해는 틀릴 수 있지만, VPN 우회는 호스트 전용이고 오로지 터널 2.0 트래픽에만 적용되며, 따라서 80/443 트래픽은 거기에 구성된 우회에 적용되지 않나요?
우회 우선순위에 대한 일반 모범 사례는 모든 80/443 대상에 PAC 기반 우회를 사용하고, 터널 2.0 제외를 위해 IP 기반 또는 맞춤형 애플리케이션 우회를 병행하는 것이 좋습니다. 여러 IP로 해석되는 FQDN들의 우회 관리는 VPN 게이트웨이 우회로 최선은 아닙니다.
또한 WFP 드라이버를 활성화하고 ZCC에 대해 플로우 로그를 요청하는 것도 추천합니다. 우회된 거래를 추적할 수 있기 때문입니다.
터널링 관련해서는, 높은 수준의 아키텍처 설계 차원에서 고려해야 할 사항이 있을 것 같습니다. 일반적으로, 터널 2.0의 모범 사례는 해당 트래픽이 Zscaler로 바로 가도록 하는 것이며, 다른 모든 트래픽은 정책 기반 경로를 통해 GRE 터널로 포워딩하고, ZCC 트래픽은 제외하는 방식을 추천합니다.
터널 1.0은 본질적으로 구 프록시 스타일로, 각 세션이 별도의 HTTPCONNECT 터널을 생성합니다. 이론상으로는 GRE 터널 위에 이들을 배치할 수도 있지만, 권장하지 않습니다.
터널 2.0은 보다 VPN에 가깝고, 지속적인 패킷 기반 터널로서 모든 트래픽(인터넷 대상)이 보내집니다. 이 트래픽은 GRE 터널을 통해 가서는 안 되며, 문제가 생길 수 있습니다.
모든 포트와 프로토콜을 ZIA를 통해 보내려고 하시나요?
그것이 제게는 이해가 가는 것 같네요. 신뢰할 수 있는 네트워크일 때 터널 2.0과 1.0을 아예 비활성화하는 건 어떨까요? 모든 트래픽이 GRE를 통해 ZIA로 전달됩니다.
그 후, 네트워크 밖에서 터널 2.0이 활성화되면, 보통 집에서이며 이 경우 모든 트래픽이 인터넷을 통해 직접 Zscaler로 가게 되어 이중 터널링이 일어나지 않습니다.
이것이 더 올바른 구성이라고 생각하는데, 정책 기반 라우팅으로 특정 트래픽만 GRE를 우회하는 것 외에 다른 부작용이 있을까요? 제 이해로는, 터널 2.0/1.0이 단순히 ZIA를 통과하는 또 다른 방법인 것 같습니다.
안녕하세요! 답변 주셔서 감사합니다. 네, 우리는 터널 2.0을 통해 모든 포트와 프로토콜을 ZIA로 보내고 있으며, 이것은 우리 의도적인 설계입니다.
터널이 항상 켜져 있는 것에 대해 의구심이 있었는데, 신뢰된 네트워크에서도 그렇다고 하네요. 이를 끄도록 변경할 것을 추진하겠습니다.
가장 궁금한 점은 우회 작업이 어떻게 이루어지는가입니다. 모든 80/443 트래픽을 1.0 리스너를 통해 우회하고 있는데, 도메인 전체를 우회하려면 앱 프로필 .PAC 파일을 사용해야 하는 것으로 알고 있습니다. 만약 내장 VPN 게이트웨이 우회를 통해 우회하면, 80/443도 여전히 그 규칙을 따르나요?
신뢰 네트워크일 경우 그렇게 하실 수 있지만, 그 GRE에서의 트래픽을 분리하는 것이 더 많은 여유와 유연성을 제공하며, ZCC가 동일하게 처리하게 하세요. 고객 측의 문제 해결도 훨씬 간단해집니다.
배포 규모와 영향이 크지 않다고 하더라도, 규모가 큰 고객(예: 1만 이상 사용자)이 하나의 사이트에서 GRE를 통해 발생하는 전체 트래픽 양을 줄이는데 엄청난 이점을 얻을 수 있습니다.
무슨 일을 하려는 것인지 헷갈립니다. 만약 전부를 Tunnel2.0으로 보내고 있는데, 왜 80/443 트래픽을 리디렉션하거나 우회하나요?
대부분의 고객은 터널 2.0을 항상 켜두고, 로컬 네트워크에서의 인터넷 접속은 Zscaler와 우회된 앱으로 제한하며, 이로 인해 사용자는 항상 ZIA를 통합니다.
다른 포트들은 PAC를 통해 영향을 받지 않습니다. 그것은 웹 트래픽 전달만을 위한 것이기 때문입니다. 터널 2.0 배포에서는 PAC 파일로 크게 할 필요가 없습니다.
네, 감사합니다! 많이 배웠고, 이 환경에 대한 소유권을 갖기 위해 앞으로 해야 할 일이 많습니다.
크기와 관련하여 답변하자면, 저희는 약 70개 이상의 사이트에 걸쳐 있는 학교 이사회입니다. 가장 큰 사이트는 약 2000명의 사용자가 GRE를 통해, 평균은 약 500명이며, 아직 ZCC는 2개 사이트에만 배포되고 나머지는 GRE만을 사용하고 있습니다. 트래픽 처리량은 큰 걱정이 아니지만, 유연성과 문제 해결의 관점에서 좋은 포인트를 해주셔서 감사합니다.
ZScaler의 우회 웹 트래픽 관련 베스트 프랙티스 페이지가 있습니다.
https://help.zscaler.com/client-connector/best-practices-adding-bypasses-z-tunnel-2.0
버전 3.8 이상에서는, 언급된 설정을 켜면 모든 http/https 트래픽이 우회되고, 터널 2.0 대신 터널 1.0으로 보내집니다.
왜인지는, 일부 클라이언트들이 ZCC를 거치는 웹 서버로부터 401 권한 없음 응답을 받기 시작했기 때문입니다. GRE는 문제없이 작동하는데, 오로지 ZCC를 통해 보낼 때만 일어납니다.
이것의 아이디어는, 이러한 웹사이트들이 ZCC를 통해 프록시되지 않도록 우회하는 것이며, 왜 일부 웹 서버가 401 응답을 보내는지 원인을 파악하는 동안입니다.
아, 아마도 당신의 계정 SE를 알고 있거나 온보딩했을지도 모르겠군요. 계정 팀에 연락하시면 관련 자료를 안내받을 수 있습니다.
그 방식도 가능합니다, 만약 앱 PAC를 통해 웹 트래픽을 우회하고 싶다면. 대부분의 고객은 터널 2.0과 매우 적은 사이트만 우회하여 사용하는 방식이 대부분입니다.
트래픽에 대한 ZIA 로그를 확인하여 더 많은 정보를 얻을 수 있습니다. GRE(일반적으로 서버와 IOT 용)와 사용자 기반 트래픽(일반적으로 ZCC용)에 대해 각각 정책이 다를 가능성이 높으며, 이 방식으로 문제 원인을 파악할 수도 있습니다. 그렇지 않으면, ZCC에서 캡처를 실시하여 더 심도있는 정보를 얻는 것도 가능합니다.
PAC를 통한 우회는 절대 최후의 수단이어야 하며, 그 후회는 매우 어렵기 때문입니다.