게이트웨이가 자체 관리 페이지를 호스팅합니다: 내부 주소인가 공인 주소인가

관리 페이지는 모바일 데이터의 휴대폰에서는 응답하고 VPN에 연결된 노트북에서는 시간 초과됩니다. 요청이 터널로 들어가지 않으므로 터널은 고장 난 것이 없습니다. 호스트 이름은 게이트웨이의 공인 주소로 확인되며, 그 주소는 자신이 종료하는 터널 바깥에서만 도달할 수 있습니다. 이를 고치는 일은 바깥 끝점을 옮기는 것이 아니라 서비스에 내부 진입점을 주는 것입니다.

페이지는 터널이 아니라 바깥에서 로드됩니다

서로 다른 두 요청을 비교하고 있습니다. 모바일 데이터에서는 브라우저가 공인 주소로 곧장 도달합니다. 터널 안에서는 같은 이름이 같은 공인 주소로 확인되고, 패킷은 이제 터널 자체의 먼 쪽 주소에 닿기 위해 터널 밖으로 나가야 합니다. 같은 이름, 같은 주소, 아주 다른 두 위치.

목적지 경로는 포트가 아니라 주소를 고릅니다. 라우팅 테이블은 443 포트가 관리용이고 1194 포트가 전송용이라는 것을 알지 못하므로 둘 다 같은 목적지로 취급됩니다.

그래서 페이지가 될 때도 있고 안 될 때도 있는데, 클라이언트가 어떤 이름과 어떤 네트워크를 썼는지에 달려 있습니다.이것은 인증 문제가 아니라 경로 문제입니다. 두 클라이언트 모두 인증은 잘 통과합니다.

바깥 끝점을 도달 가능하게 유지하십시오

전체 터널 프로필에는 VPN 끝점을 위한 예외 경로가 필요하며, OpenVPN의 redirect-gateway 옵션은, 원격 끝점이 기존 게이트웨이를 지나는 경로를 유지하여 터널이 자기 자신으로 라우팅하지 않는다는 것을 바로 문서화합니다. 그 예외를 없애면 암호화된 전송이 터널을 따라가고 세션은 루프에서 끝납니다. 끝점 주소가 터널 안에서 도달 가능하게 남는 이유가 바로 그 예외입니다.

그 결과 공인 주소는 클라이언트에서 도달 가능하게 남고, 그래서 그 주소로 가는 브라우저 요청도 같은 예외를 따라 터널에 들어가지 않고 나갈 수 있습니다. 예외는 제 일을 하고 있고, 피해를 만드는 것은 이름입니다.

무엇이든 바꾸기 전에 인터페이스 목록이 아니라 경로 결정을 읽으십시오. 아래 명령은 목록이 아니라 결정을 출력합니다. 실패한 클라이언트에서 실행하십시오.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

조회 결과가 실제 게이트웨이를 지나는 끝점 경로를 보여 준다면 동작은 올바르고, 관리 페이지가 그저 잘못된 경로로 보내지고 있을 뿐입니다. 바로 그 지점에서 이름 확인이 해결책이 됩니다.

서비스에 비공개 이름을 주십시오

서비스에는 터널 안에서 게이트웨이 주소로 확인되는 이름이 필요하며, 동시에 애플리케이션이 기대하는 인증서와 호스트 이름의 의미를 유지해야 합니다.관리 이름에는 비공개 영역 레코드가 일반적인 답입니다, 그리고 전송 이름은 그대로 둡니다.

다음 터널 수립이 터널 안에만 존재하는 주소에 닿으려 하므로 전송 이름을 내부 주소로 다시 지정하지 마십시오. 그 실수는 딱 한 번 동작하는 VPN을 만듭니다.

남겨진 AAAA 레코드가 브라우저를 비공개 계획이 결코 덮지 못한 곳으로 보낼 수 있으므로 두 주소 체계도 확인하십시오.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

정책을 프로세스가 실행되는 위치에 맞추십시오

게이트웨이에서 수신하는 네이티브 프로세스에는 로컬 입력 경로로 도달하므로, 입력 체인과 소켓 바인딩이 요청 수락 여부를 결정합니다. 포워딩 규칙과 IP 포워딩은 로컬 리스너가 응답하게 만들지 않습니다. 입력 정책에서 터널 출발지를 허용하고 프로세스가 터널이 도달할 수 있는 주소에 바인딩되었는지 확인하십시오.

패킷이 목적지 변환을 거쳐 포워딩되므로 호스트 포트에 게시된 컨테이너는 다른 경로를 따릅니다. 그 요청은 호스트의 포워딩 정책과 Docker 자체 규칙을 만나며, 그래서 동작하는 네이티브 리스너가 같은 포트를 거부하는 컨테이너와 공존할 수 있습니다.

터널이 올라온 뒤에야 나타나는 주소로의 바인딩은 부팅할 때 조용히 실패하므로 두 경우 모두 시작 순서가 중요합니다.

비공개 접근과 거부되는 공인 경로를 확인하십시오

애플리케이션 자체의 신원 확인을 그대로 둔 채 권한 있는 클라이언트에서 새 이름 요청을 하십시오. 그다음 터널 바깥에서 같은 서비스를 시도해 응답하지 않는지 확인하십시오. 비공개 이름은 제한이 아니라 편의이며, 공인 주소에 여전히 바인딩된 리스너는 여전히 노출되어 있습니다. 마지막 확인을 대부분의 검토가 건너뜁니다.

사용자에게 준 호스트 이름이 아니라 바인딩과 필터 상태를 읽으십시오. 노출은 이름이 아니라 소켓의 속성입니다. 그 구분은 어떤 DNS 변경에서도 살아남습니다.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

내부 요청이 페이지를 돌려주고 바깥 요청이 시간 초과되면 서비스에는 의도된 비공개 경로가 하나 있고 전송은 도달 가능하게 남습니다. 바깥 요청이 여전히 응답한다면 누군가 서비스를 내부 전용이라고 부르기 전에 리스너나 게시된 컨테이너 항목을 좁혀야 합니다.