URL에 45000이 아니라 포트 80이나 443 진입점이 필요한 이유

브라우저에 호스트 이름을 입력하면 스킴이 목적지 포트를 결정합니다: http는 80, https는 443입니다. DNS 응답의 어떤 것도 이를 무시하지 못하며, 로컬 머신의 어떤 포워딩 규칙도 공급자 경계에서 리스너를 만들어낼 수 없습니다. VPN 공급자가 45000 같은 높은 공개 포트를 준다면 명시적 URL은 작동하지만 깔끔한 URL은 작동하지 않습니다. 격차는 진입 지점에 있고 애플리케이션 내부에 있지 않습니다.

브라우저에서 프로세스까지의 경로를 한 번 따라가면 세 가지 게시 옵션이 더 이상 불가사의해 보이지 않습니다.

요청이 실제로 어디로 가는지 보세요

브라우저는 이름을 주소로 확인한 뒤 URL이 다른 포트를 지정하지 않으면 스킴의 기본 포트로 그 주소에 연결합니다. 도착한 연결에 무슨 일이 일어나는지는 공급자의 경계가 결정합니다. 포워딩 표가 45000만 내부 주소로 매핑한다면 80으로의 연결은 갈 곳이 없고, 로컬 머신이 관여하기 전에 거부되거나 버려집니다.

그 거부는 경계에서 일어나므로 애플리케이션 로그에는 아무것도 남지 않습니다. 로그가 없다는 것은 패킷이 어디서 멈췄는지에 대한 증거이며, 애플리케이션이 고장 났다는 증거가 아닙니다.

로컬 규칙으로 경계를 고칠 수 없는 이유

애플리케이션 호스트의 리디렉션이나 DNAT 규칙은 이미 도착한 패킷에 작용합니다. 공급자 쪽에서 80으로 보낸 패킷은 결코 도착하지 않으므로 그 규칙은 평가되지 않습니다. 이것이 이 문제 전체에서 가장 흔히 낭비되는 한 시간입니다.

DNS도 포트를 실을 수 없습니다. HTTP 명세는 스킴의 기본값을 정의하고, A 또는 AAAA 레코드는 주소를 반환하며 CNAME은 다른 이름을 반환합니다. 브라우저는 여전히 스킴의 포트를 붙이므로 URL의 명시적 포트만 목적지를 바꿉니다.

첫 번째 옵션: 명시적 포트를 유지하기

흔히 정답은 화려하지 않은 쪽입니다. 포트가 포함된 전체 URL을 게시하고, 이를 지원하는 진입점에서 TLS를 종료하며, 생성되는 모든 링크가 같은 오리진을 유지하도록 하세요. 작고 통제된 대상에게는 이것으로 충분하고, 눈에 보이는 포트 번호 외에는 비용이 들지 않습니다.

자신의 호스트 이름을 Location 헤더에 쓰는 백엔드는 이 구성을 무너뜨리므로, 거기 있는 동안 리디렉션과 쿠키 범위를 확인하세요.

두 번째 옵션: 기본 포트의 진짜 진입점 확보하기

일부 공급자와 호스팅 구성은 공유 또는 전용 주소에서 80과 443을 문서화된 서비스로 전달합니다. 공개 출구 주소가 임의의 인바운드 포트를 뜻한다고 가정하지 말고 실제로 무엇이 포함되는지 물어보세요. 전용 출구 주소는 인바운드 포워딩에 대해 아무것도 말해 주지 않습니다.

소유권과 가용성을 서면으로 확인하고, 터널이 다른 주소로 다시 연결될 때 진입점이 어떻게 되는지도 포함하세요. 터널과 함께 움직이는 진입점은 DNS 장애처럼 보이는 중단을 만듭니다.

세 번째 옵션: 앞단에 프런트엔드 두기

도달 가능한 주소의 리버스 프록시는 443에서 수신하고 TLS를 종료하기하고 VPN을 통해 백엔드로 별도 연결을 열 수 있습니다. 방문자는 프런트엔드의 이름과 기본 포트를 보지만, 프런트엔드는 사용자를 대신해 백엔드의 높은 포트와 대화합니다. 이것이 작동하는 이유는 진입점과 싸우는 대신 아키텍처를 바꾸기 때문입니다. 그러면 백엔드는 공용 인터넷에서 인바운드 포트가 전혀 필요 없습니다.

운영하는 대상도 바뀝니다. 프런트엔드가 공개 TLS, 접근 정책, 로그, 가용성을 소유하며 백엔드 선택을 의도한 서비스로 제한해야 합니다. 프런트엔드에서 백엔드로의 홉이 HTTPS를 쓴다면 그 홉에서 인증서 검증을 유지하세요.

오리진 하나 유지하기

프런트엔드의 공개 호스트 이름, 스킴, 포트가 방문자가 사용하는 오리진을 이루므로 애플리케이션의 외부 URL, 리디렉션, 쿠키를 그 오리진에 맞게 구성하세요. 애플리케이션이 절대 링크를 만든다면 원래 호스트와 전달된 스킴을 보내세요. 사용자를 사설 이름이나 높은 포트로 되돌리는 응답은 방금 만든 깔끔한 진입점을 무너뜨립니다.

그다음 대상 독자를 생각하며 결정하세요. 짧은 URL은 관리형 프런트엔드를 정당화할 수 있지만, VPN 전용 사설 서비스를 실수로 공개 서비스로 바꾸는 것은 가치가 없습니다.