TLS는 두 끝점 사이의 채널을 보호하며 그 안에 어떤 서비스가 있는지에 대해서는 아무 말도 하지 않습니다. 래퍼는 그 채널을 구성된 포워더 하나로 바꿉니다. 리스너 하나, 목적지 하나에 대해서입니다. SSL VPN으로 판매되는 제품은 보통 같은 프리미티브 주위에 인터페이스, 라우팅 테이블, 접근 모델을 더합니다. 둘을 혼동하는 것이 작동하는 터널을 네트워크 접근으로 오해하는 이유입니다.

서비스 래퍼가 실제로 연결하는 것

래퍼는 로컬 포트에서 수신하고 도착한 것을 구성된 목적지로 전달합니다. 목적지는 호스트와 포트일 수도 있고 로컬 프로그램일 수도 있습니다. 그 목적지는 구성 파일을 쓴 사람이 고르며, 한 번에 리스너 하나입니다. 패키지를 설치해도 경로도, 가상 인터페이스도, 명시되지 않은 어떤 것에 대한 도달성도 생기지 않습니다. 패키지 설명보다 구성 파일을 먼저 읽으십시오. 설명은 사용 부류를 다루고 파일은 당신의 경우를 다루기 때문입니다.

따라서 래퍼에 관한 유용한 질문은 암호화 여부가 아니라, 래퍼가 만드는 사슬의 양 끝에 무엇이 있는가입니다.

application -> local listener -> TLS connection -> remote listener -> configured backend

그 사슬은 마케팅 이름이 아니라 구성에서 읽으십시오. 각 화살표는 자체 주소와 자체 접근 규칙을 가진 별개의 네트워크 홉입니다.

TLS 채널이 끝나는 곳을 찾으십시오

래퍼가 TLS를 종료한다면 그 뒤로 전달하는 모든 것은 새 속성을 지닌 새 연결입니다. 스트림은 사설 세그먼트의 평문일 수도 있고, 내부에 다른 보호 프로토콜을 담을 수도 있습니다. 백엔드 구성을 읽지 않고 둘 중 하나를 가정하는 것이, 바깥 계층이 다시는 보지 못하는 데이터를 보호한다고 사람들이 결론짓는 방식입니다. 전달된 홉은 자체 주소와 포트에서 자체 점검을 받을 자격이 있습니다.

리스너와 백엔드를 따로 확인하십시오. 정문에서 성공한 핸드셰이크는 그 뒤의 서비스에 대해 아무 말도 하지 않습니다.

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

첫 번째 명령은 어느 프로세스가 포트를 소유하고 어느 주소에서 수신하는지 보여 줍니다. 두 번째는 클라이언트가 실제로 받는 인증서를 출력하며, 이것이 포트 번호로 대체할 수 없는 신원 확인입니다.

라우팅 VPN이 더하고 래퍼가 하지 않는 것

라우팅 VPN은 인터페이스를 설치하고, 선택된 프리픽스의 소유권을 가져가며, 호스트의 라우팅과 접근 정책에 통합됩니다. 머신의 모든 애플리케이션은 터널의 존재를 모른 채 혜택을 받습니다. 래퍼는 그 도달 범위를 구성된 리스너 하나에 주고 거기서 멈춥니다.

허용은 다시 별개입니다. 클라이언트를 인증하는 VPN도 클라이언트가 어느 자원에 도달할 수 있는지 말하는 권한 부여가 여전히 필요하고, 피어를 인증하는 래퍼도 자체 권한을 강제하는 백엔드가 여전히 필요합니다.

정당한 조합이 있습니다. 의도적으로 지원되는 TCP 배치에서 TLS 래퍼 내부로 VPN 프로토콜을 운반하는 것입니다. 이는 두 계층을 쌓지만 래퍼와 VPN을 같은 종류의 객체로 만들지는 않습니다.

실패하는 경계를 비교하십시오

무엇이든 바꾸기 전에 프런트엔드 주소, 리스너, 피어 신원, 백엔드 대상, 애플리케이션 작업을 적으십시오. 그다음 비교 가능한 것을 비교하십시오. 다른 호스트 이름이나 포트를 통한 성공은 방화벽과 인증서 조건이 동일했음을 증명하지 않습니다.

거부된 백엔드 요청을 프런트엔드 신원 검증을 끄는 방식으로 고쳐서는 안 됩니다. 그것은 진단 가능한 권한 부여 실패를 진단 불가능한 신뢰 실패로 바꿉니다.

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

이름을 선택한 주소에 고정하는 것은 이름 해석을 도달성과 분리하며, 둘 중 어느 것이 고장 났는지 아는 가장 빠른 방법은 보통 이것입니다.

중요한 비교는 보호된 끝점 쌍, 운반되는 페이로드, 그것을 사용하는 애플리케이션, 목적지에서 강제되는 권한을 명시합니다. TLS는 그 설명에 기여하지만 완성하지는 않습니다.

관련 글