전달된 VPN 포트: 방문자와 제공자가 볼 수 있는 것

포트를 전달하면 낯선 사람이 제공자의 공개 주소를 통해 서비스로 가는 경로를 얻습니다. 그 한 번의 변경이 노출과 인식 가능성에 동시에 영향을 주지만, 어느 쪽도 서비스를 운영하는 사람의 이름을 공개하지 않습니다. 둘을 분리해 두면 '전달'을 익명성으로 보는 오류와 전달을 신원 확인으로 보는 반대 오류를 피할 수 있습니다. 세 가지 질문이 둘을 깔끔하게 갈라 주고, 답은 서로 다른 증거에서 나옵니다.

세 가지 대상, 세 가지 다른 질문

공개 주소는 그 뒤에서 응답하는 애플리케이션과 분리하고, 둘 다 이 일을 운영하는 사람이나 조직과 분리하십시오. 각각은 자기만의 청중과 자기만의 증거를 가집니다. 이것을 섞으면 정돈되어 들리지만 틀린 결론이 나옵니다.

그 순서대로 살펴보십시오. 첫째는 도달 가능성에 대한 질문이고, 둘째는 애플리케이션 정체성에 대한 질문이며, 셋째는 귀속에 대한 질문인데 앞의 둘은 그것을 부분적으로만 비춥니다. 누군가 포트 전달이 사적이냐고 묻는다면, 세 가지 중 어느 것을 말하는지 되물으십시오. 답은 실제로 다르고, 정책 페이지는 보통 그중 하나만 다룹니다.

방문자가 엔드포인트 사이에서 연결할 수 있는 것

방문자는 엔드포인트에 접속해 '호스트 이름', 인증서 이름, 로그인 페이지, 게시된 콘텐츠처럼 애플리케이션이 정당하게 제시하는 것을 봅니다. 이런 세부 정보는 평소 접속 주소가 터널 뒤에 숨어 있어도 서비스를 식별하게 합니다. 같은 이름의 사이트를 제시하는 두 엔드포인트는 관찰자에게 둘을 연결할 근거를 줍니다. 애플리케이션이 보이도록 설계되었으므로 이 행동에는 유출이 없습니다.

두 엔드포인트에서 인증서, 리디렉션, 페이지 내용이 일치하는 것은 그것들이 한 서비스에 속한다는 강한 신호입니다. 다른 기록이 둘을 연결하기 전까지, 그것은 서비스에 대한 진술이지 사람에 대한 진술이 아닙니다.

IETF의 개인정보 보호 지침은 지속적 식별자가 상호작용을 시간에 걸쳐 상관시킬 수 있게 하는 방식을 설명합니다. 상관은 귀속이 아닙니다, 한 서비스를 여러 사람이 관리할 수 있고 주소는 무관한 가입자 사이를 옮길 수 있기 때문입니다. 이 구분이 상관 결과를 고발로 바뀌지 않게 합니다.

전달 제공자가 알아야 할 것

들어오는 연결을 전달하려면 제공자의 시스템이 공개 진입점과 내부 목적지 사이의 활성 관계를 유지해야 합니다. 이 운영상의 사실은 방문자가 보는 것과 다르고, 제공자가 보존하기로 선택한 것과도 다시 다릅니다. 정책 페이지를 읽을 때는, 하나는 피할 수 없고 다른 하나는 결정이므로 두 질문을 분리하십시오. 탐색 기록을 보관하지 않는다는 진술은 매핑 기록에 대해 아무것도 말하지 않습니다.

과거 매핑, 계정 연결, 연결 기록이 남는지는 제공자의 실제 정책과 구현에 관한 질문입니다. 전달은 모든 범주가 기록된다는 것을 증명하지 않습니다. 매핑이 철회된 뒤 어떤 필드가 남는지, 얼마나 오래 남는지 구체적으로 물으십시오.

들어오는 도달 가능성은 클라이언트의 나가는 라우팅, DNS, 실패 시 동작과도 별개입니다. 매핑을 추가해도 클라이언트의 나머지 트래픽이 어떻게 나가는지는 설명되지 않습니다.

매핑이 얼마나 지속되는지가 노출을 바꿉니다

매핑은 세션 동안, 예약을 위해, 또는 그것을 바꾸는 제공자 정책에 따라 지속될 수 있지만, 영구 할당도 끊임없는 회전도 가정해서는 안 됩니다. 제품의 문서화된 동작을 읽고 관찰한 것을 기록하십시오. 일주일 간격의 두 관찰은 제품 페이지의 어떤 마케팅 문구보다 '회전'에 대해 더 많이 말해 줍니다. 관찰한 간격은 노출의 일부이므로 메모에서 엔드포인트 옆에 적어 두십시오.

수명은 어떤 상관이 가능한지를 바꿉니다. 안정적인 엔드포인트는 한 서비스의 장기 추적을 부르고, 회전하는 엔드포인트는 각 관찰을 이전 관찰과 잇기 어렵게 만듭니다. 어느 속성도 제공자의 기록에 대한 보증이 아니며, 어느 것도 서비스 자체가 무엇을 공개하는지에 대한 결정을 대신하지 않습니다.

의도적으로 공개하고, 그다음 두 문을 닫으십시오

제공자가 필요한 프로토콜을 허용하는지, 대상 리스너가 의도한 것인지, 호스트와 애플리케이션 제어가 여전히 접근을 제한하는지 확인하십시오. 공개하기 전에 서비스가 낯선 사람에게 무엇을 보여 줄지 살펴보십시오. 다음 두 명령은 방문자가 받는 인증서와 헤더를 보여 줍니다.

openssl s_client -connect pub.example.net:443 -brief < /dev/null
curl -sSI https://pub.example.net/

무언가를 공개한다고 해서 그 관리 페이지를 노출하거나 애플리케이션 로그인을 없앨 이유가 되지는 않으며, 번역이 TLS를 제공하지도 않습니다. 트래픽이 어떻게 도착하든 암호화된 프로토콜과 그 서버 신원 확인을 유지하십시오. 그다음, '배너'나 디버그 페이지가 서비스가 의도한 것보다 많은 것을 낯선 사람에게 알려 줄 수 있으므로 응답 헤더를 확인하십시오. 두 명령이 돌려주는 것은 관찰자가 얻는 것과 같은 화면입니다.

서비스를 중단하는 것은 두 번의 폐쇄이지 한 번이 아닙니다: 소유자를 통해 매핑을 철회하고, 그다음 리스너와 권한을 별개 항목으로 다루십시오. 북마크한 엔드포인트가 응답을 멈춰도 자격 증명이 취소되지 않고, 이미 전달된 정보를 되찾지도 못합니다.