SharePoint 링크가 게시된 URL 때문에 VPN에서 끊깁니다
VPN으로 로드한 SharePoint 페이지가 클라이언트가 확인할 수 없는 이름으로 문서 링크를 반환할 수 있습니다. DNS, 경로, TLS, 게시된 URL을 확인하세요.
SharePoint 페이지가 VPN을 통해 열리는데, 첫 문서 링크가 주소 표시줄에 없던 이름으로 실패합니다. 그 간극이 문제의 전부입니다: 페이지는 한 URL에서 왔고, 서비스는 다음 요청을 다른 URL에서 만들었습니다. 게시된 URL은 서버 측 결정이므로 클라이언트에서 고치는 것은 잘못된 쪽입니다. DNS나 경로를 건드리기 전에 서비스가 어떤 이름을 반환하는지 확인하세요.
첫 페이지와 다음 요청이 서로 다른 이름을 사용합니다
주소로 서버에 도달한 사용자는 작동하는 홈페이지를 봅니다. 그 페이지의 문서 링크는 서비스가 게시한다고 믿는 URL에서 생성되며, 브라우저가 입력한 URL에서 생성되지 않습니다. 둘이 다르면 다음 클릭은 클라이언트가 한 번도 확인하지 않은 이름으로 갑니다.
주소를 한 번 입력해도 생성된 모든 링크가 고쳐지지 않으며, 주소에 대한 북마크는 문서를 열기 전까지 문제를 숨깁니다.
이 실패는 터널을 사용한 뒤에만 나타나기 때문에 VPN 문제로 잘못 읽기 쉽습니다. 실제로 터널은 제 몫을 합니다: 작동하는 경로나 일치하는 인증서가 없는 이름으로 요청을 나를 뿐입니다. 둘 중 하나를 바꾸기 전에 두 질문을 분리하세요. 하나는 패킷이 어디로 가는지이고, 다른 하나는 서비스가 어떤 이름을 게시하기로 했는지입니다.
네 가지 제어, 하나의 이름
게시된 모든 이름은 네 가지 독립적인 제어를 통과해야 합니다. DNS가 실제 클라이언트에 대해 확인해야 하고, 라우팅과 액세스 정책이 경로를 허용해야 하며, TLS가 그 이름을 검증해야 하고, 서비스가 이를 게시하도록 구성되어야 합니다.
한 제어의 변경이 나머지를 수행하지 않습니다. 인증서 경고를 수용하는 것은 이름 확인의 수리가 아닙니다.
아래 표는 점검 목록의 순서입니다. 나중의 수정이 앞선 결손을 보상할 수 없으므로 실패하는 첫 행에서 멈추세요.
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
변경하기 전에 게시 모델을 읽으세요
SharePoint Server 배포는 서로 다릅니다. 클래식 웹 애플리케이션은 대체 액세스 매핑을 사용할 수 있으며, 여기서 내부 URL은 서버가 받는 것이고 공용 URL은 링크를 구성하는 데 사용하는 것입니다. 호스트 이름 사이트 모음은 다른 접근 방식을 따르며 Microsoft 지침에 따르면 AAM을 사용할 수 없습니다.
Microsoft의 계획 지침도 AAM 기능을 사용하지 않는 것으로 표시하고 새 계획에는 호스트 이름 사이트 모음을 권장합니다. 그래서 배포 모델은 소유자에게 물을 문제이며, 당신이 덧대는 기본값이 아닙니다.
매핑 변경을 제안하기 전에 어떤 모델이 쓰이는지 확정하세요. 호스트 이름 배포에 AAM 항목을 추가하면 아무 일도 없고, 클래식 배포에 하나를 추가하면 반환되는 모든 링크가 한꺼번에 바뀝니다. 둘 다 영향 범위가 넓은 구성 변경이므로 단계적으로 준비하고 롤백을 유지하세요. 이것은 레거시 매핑을 현대 환경에 들여오라는 권고가 아닙니다.
홈페이지가 아니라 실패한 작업을 따라가세요
실패한 요청이 실제로 사용한 대상, 클라이언트 애플리케이션, 시간, 오류를 기록하세요. 브라우저와 데스크톱 애플리케이션은 같은 문서로 다른 프록시, VPN 또는 인증 경로를 택할 수 있습니다.
브라우저는 성공하고 Office 클라이언트는 실패할 수 있으며, 그 차이는 어느 컨텍스트가 이름을 확인하는지의 단서입니다.
URL과 네트워크 핸드오프가 둘 다 작동하는데도 서비스가 작업을 거부하면 남은 문제는 애플리케이션 수준입니다. 문서 권한과 체크아웃 상태는 서비스 소유자의 것이며, VPN 경로는 연결성을 제공할 뿐 권한을 주지 않습니다.
핸드오프를 처음부터 끝까지 확인하세요
실패하는 클라이언트에서 점검을 순서대로 실행하세요: 게시된 이름을 확인하고, 그 이름으로 페이지를 요청하고, 페이지 소스에서 문서 URL을 요청하세요. 각 단계가 하나의 제어를 분리합니다.
세 명령이 확인, TLS, 문서 경로를 다룹니다:
nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspx확인이 터널을 통해서만 실패하면 split-DNS 정책이 용의자입니다. TLS가 실패하면 경고를 넘겨 클릭하지 말고 인증서 이름을 게시된 이름과 비교하세요. 둘 다 성공하는데 문서가 여전히 실패하면 오류는 더 이상 URL에 관한 것이 아닙니다.