들어오는 터널은 어떤 RRAS 사이트 인터페이스를 선택하는가?
RRAS는 피어 주소, 사용자 이름 또는 인증서 주체로 들어오는 사이트 인터페이스를 선택하므로, 그 키는 활성화 및 연결 상태와 분리해서 읽어야 합니다.
여러 사이트 간 인터페이스가 있는 Windows 서버에서 콘솔 레이블은 사람을 위한 메모일 뿐이 아닙니다. RRAS는 들어오는 연결의 특정 필드를 사용해 어떤 논리 인터페이스가 응답할지 결정하며, 그 필드는 인증 방법에 따라 달라집니다. 키를 잘못 잡으면 무언가가 우연히 연결될 때까지 인터페이스 이름을 바꾸게 됩니다. 선택 규칙, 관리 상태, 세션 상태는 세 가지 별개의 사실이며, 그중 이름에 관한 것은 하나뿐입니다.
오해: 이름을 바꾼 인터페이스는 무엇이든 일치한다
지사가 연결되지 않을 때 솔깃한 해결책은 호출자와 비슷해질 때까지 사이트 인터페이스를 만들거나 이름을 바꾸는 것입니다. 그것은 한 가지 인증 방법에서는 통하고 나머지에서는 조용히 실패하므로, 같은 절차가 상충하는 결과와 함께 퍼집니다. 사이트 인터페이스는 고유한 대상, 보호된 접두사, 상태를 가진 논리적 연결 개체입니다. 암호화된 패킷을 나르는 물리 어댑터가 아니므로 네트워크 어댑터를 봐도 어떤 사이트 개체가 선택되었는지 알 수 없습니다.
선택은 일반 원격 액세스 사용자와도 무관합니다. 직원 VPN 클라이언트가 전화를 걸면 그들은 다른 역할이며, 그들의 사용자 이름은 이 매핑에 절대 참여하지 않습니다. 익숙한 이름에서 무언가를 읽기 전에 호출자가 어느 역할에 속하는지 확인하십시오.
세 가지 인증 형태, 세 가지 선택 키
미리 공유한 키에서는 인터페이스의 구성된 대상 주소를 들어오는 피어의 주소와 비교합니다. 레이블은 무엇이든 될 수 있습니다. 결정을 나르는 것은 주소이기 때문입니다. 사용자 이름 기반 인증에서는 인터페이스 이름을 호출자가 제시한 사용자 이름과 비교합니다. 여기서 레이블이 곧 키이며, 이름 변경이 한 사이트는 고치고 다른 사이트는 깨는 것처럼 보이는 이유가 바로 이것입니다.
인증서에서는 인터페이스 이름을 제시된 인증서의 주체 이름과 비교합니다. 이름은 그 주체와 일치해야 하며, 운영자가 지어낸 예쁜 레이블로는 충분하지 않습니다.
두 가지 결과가 따릅니다. 미리 공유한 키 구성에서는 주어진 대상에 대해 인터페이스 하나만 활성화할 수 있으므로, 관찰된 하나의 공인 주소를 공유하는 두 지사를 중복 항목으로 모두 서비스할 수 없습니다. 그리고 콘솔이 무엇을 제안하든 실제로 구성한 방법이 우선합니다.
| Authentication in use | The field RRAS compares | Symptom when the two disagree |
|---|---|---|
| Pre-shared key | The peer address in the incoming connection against the interface destination | Renaming the interface changes nothing; a destination that does not match the caller stays unused |
| Username | The caller login against the interface name | A site with a friendly label never answers, while a differently named site may answer instead |
| Certificate | The subject name in the presented certificate against the interface name | An interface named after the office rather than the subject CN is never selected |
활성화는 연결됨이 아니다
관리 상태는 논리 인터페이스가 작동하도록 허용되었는지 말합니다. 연결 상태는 지금 세션이 있는지 말합니다. 세션이 없는 활성화된 인터페이스는 요청 시 전화 접속 링크의 정상적인 휴지 상태이며, 이를 장애로 보고하면 존재하지 않는 중단을 쫓게 만듭니다.
이름 지정 조회나 문서화된 라우팅 도메인 조회를 사용하되 두 매개 변수를 함께 쓰지 말고, 의도한 서버 컨텍스트에서 실행하십시오. 예상한 인터페이스가 첫 목록에 없으면 문제는 상태 이전에 있습니다. 아무것도 선택되지 않은 것입니다.
이 쌍은 따로가 아니라 함께 읽으십시오. 설정된 상태로 유지되어야 하는데 연결 끊김으로 표시되는 링크는 조사할 가치가 있고, 요청 시 연결되는 유휴 전화 접속 링크는 설계대로 동작합니다. 한편 관리상 비활성화된 인터페이스는 상대방이 라우터를 몇 번 재부팅하든 어두운 채로 남습니다.
두 값 중 어느 것도 인증이 성공했는지, 협상된 보호가 일치하는지, 경로가 설치되었는지, 프라이빗 응용 프로그램이 허용되는지를 증명하지 않습니다. 그것은 네 가지 다른 질문과 네 가지 다른 답입니다.
Get-VpnS2SInterface | Select-Object Name, Destination, AdminStatus, ConnectionState
Get-VpnS2SInterface -Name 'Branch-A' | Format-List Name, Destination, AdminStatus, ConnectionState무엇이든 활성화하기 전에 ID 트랜잭션을 읽으십시오
들어오는 호출자가 예상하지 못한 인터페이스에 매핑되면 유용한 증거는 제시된 ID이지 비활성화된 인터페이스 목록이 아닙니다. 최근 원격 액세스 이벤트를 가져와 호출자 주소, 인증 결과, 선택된 인터페이스 이름을 읽으십시오. 비활성화된 인터페이스는 의도적으로 폐기된 사이트이거나 금지된 파트너일 수 있습니다. 로그인 오류 하나가 사라지는지 보려고 그것을 활성화하는 것은 라우팅과 액세스에 영향을 주는 구성 변경이므로, 그 사이트 관계의 소유자를 통해 결정을 전달하십시오. 대상, 보호된 접두사, 정책도 함께 포함해서요.
매핑이 정말로 잘못되었다면 증상이 아니라 키를 고치십시오. 인증서 주체 또는 사용자 이름의 경우 인터페이스 이름을, 미리 공유한 키의 경우 대상을 수정합니다. 그런 다음 한 번 다시 연결하고 같은 호출자가 이제 의도한 개체를 선택하는지 확인하십시오.
Get-WinEvent -LogName Application -MaxEvents 50 | Where-Object { $_.ProviderName -like '*RemoteAccess*' }허용된 작업으로 루프를 닫으십시오
녹색 상태는 승인이 아닙니다. 올바른 인터페이스가 선택되면 설계가 허용하는 트래픽을 한 보호된 접두사의 호스트에서 다른 쪽 호스트로 생성하고, 응답이 같은 경로로 돌아오는지 확인하십시오. 거부되어야 할 호스트에서도 같은 시도를 하되, 다음을 사용하여 Test-NetConnection -ComputerName 10.44.2.10 -Port 445 설계가 제외하는 서비스에 대해 실행하고, 원격 액세스 이벤트를 다시 읽으십시오. 의도한 접두사보다 더 많이 나르거나 정책이 제외하는 서비스에 응답하는 사이트 링크는 어떤 상태 점검으로도 드러나지 않는 라우팅 오류입니다.
인증 방법, 선택 키, 허용된 접두사를 사이트의 운영 안내서에 함께 기록하십시오. 다음 엔지니어는 같은 세 값 표를 만나게 되며, 그 맥락이 적혀야만 명명 규칙이 의미를 갖습니다.