사용자 PC 에서 배스천의 리버스 프록시를 거쳐 Viya 4 에 접속하는 구성이다. 브라우저로 SAS Studio 는 잘 열리고 Enterprise Guide 도 붙는데, VS Code 의 SAS 확장만 인증 코드를 넣은 뒤 연결 대기에서 실패한다. 같은 사양의 PC 여도 되는 것과 안 되는 것이 갈린다.
SAS 확장의 Viya 연결 프로필은 직접 도달 가능한 엔드포인트 URL 을 전제로 만들어져 있다. endpoint 에 적은 주소가 PC 에서 그대로 열려야 한다.
curl -v https://<viya-fqdn>/SASLogon/oauth/authorize
PC 의 신뢰할 수 있는 루트 인증 기관에 Viya 인그레스 인증서의 루트 CA 가 들어 있어야 한다. 서버 인증서를 넣는 것이 아니다.
VS Code 는 OS 신뢰 저장소를 쓰는 경우와 Node 런타임의 저장소를 쓰는 경우가 섞여 있어, 브라우저에서는 자물쇠가 정상인데 확장만 실패할 수 있다.
VS Code 자체의 프록시 설정과 OS 프록시가 어긋나면 확장만 막힌다.
http.proxy
http.proxyStrictSSL
http.proxySupport
사내 프록시를 쓰는 PC 와 안 쓰는 PC 가 섞여 있으면 "같은 환경인데 어떤 PC 만 된다" 는 모양이 된다. 되는 PC 와 안 되는 PC 의 이 값들을 나란히 비교한다.
리버스 프록시를 쓸 때는 다음이 통과해야 한다.
HAProxy 로 TLS 를 통과시키는 경우 HTTP 모드에서 헤더를 손대지 않고, 필요한 포트를 모두 열어 둔다.
frontend viya_https
bind *:443
mode tcp
default_backend viya_ingress
backend viya_ingress
mode tcp
server ing1 <ingress-node>:443 check
TCP 패스스루로 두면 헤더 변형 문제는 사라지지만, 인증서는 인그레스가 그대로 내려보내므로 SAN 에 사용자가 입력하는 FQDN 이 들어 있어야 한다.
대화에서는 EG 가 요청·응답 단위로 통신하고 VS Code 확장은 클라이언트가 세션을 직접 유지하기 때문이라고 정리했으나, 이는 관찰에서 끌어낸 추정이며 공식 문서로 뒷받침되지 않았다 (확인 필요).
공식 문서에서 확인되는 것은 다음 정도다.
고객이나 보안팀에 설명할 때는 "프록시 경유는 지원하지 않는다" 가 아니라 "지원 대상으로 문서화된 구성은 직접 도달 가능한 엔드포인트다" 로 적는 편이 사실에 맞는다.
이 사례는 대화 안에서 해결되지 않았다. HAProxy 로 바꾸고 포트를 추가로 열어도 같은 오류가 재현됐고, 되는 PC 와 안 되는 PC 의 차이를 끝까지 특정하지 못했다.
같은 상황을 만나면 다음을 우선 확보한다.