[AWS] Remote PowerShell Session 연결 오류 "WinRM cannot process the request..." 및 해결

원격 PowerShell 세션에 연결해야 하는 일이 있었는데 이 부분에 막혔던 오류가 있어 오늘은 이것을 기록해보려 한다.

Remote PowerShell Session 연결하기

연결은 PowerShell을 실행하고 아래 명령어 중 원하는 것을 선택하여 입력하면 된다. 명령어 먹히는 건 둘 다 동일하다.

enter-pssession -ComputerName FSxFileSystem-Remote-PowerShell-Endpoint -ConfigurationName FsxRemoteAdmin

$cred = Get-Credential '<ad user>'
$params = @{
	ComputerName = '<fsx powershell endpoint>'
	Credential = $cred
	ConfigurationName = 'FSxRemoteAdmin'
	SessionOption = (New-PSSessionOption -UICulture 'en-US')
}
Enter-PSSessionOption

https://docs.aws.amazon.com/fsx/latest/WindowsGuide/remote-pwrshell.html

Getting started with the Amazon FSx CLI for remote management on PowerShell - Amazon FSx for Windows File Server

 

문제 발생 및 환경

위 명령어가 정상적으로 먹히면 좋을란만 나의 경우, 아래와 같이 오류 메시지를 반환했다. 대충 봐도 뭔가 단단히 잘못되었다. 미리 언급하지만 필자는 AD를 잘 모른다. 참고로 환경은 FSx(Single AZ2)는 당연하게 AWS에 있으며, 지금 하단에 보이는 PowerShell 창은 윈도우 EC2이며, AD서버는 On-Prem에 위치하고 있다. AWS와 On-Prem 사이는 site-to-site VPN을 연결한 구성이며 Pirvate 한 통신 환경을 구성했다. 애당초 FSx 생성부터 뭔가 원활하지 않았는데 이게 문제가 이렇게 발현되었다. 그렇다 보니 의심 가는 곳이 한둘이 아니었다.

1. 작업 윈도우 EC2와 FSx 간의 통신 문제 점검
PS endpoint를 사용하여 FSx와 연결을 시도하려는 즉, Source가 되는 윈도우 EC2와의 통신 문제가 의심되었다. FSx 서버 자체의 Security Group, NACL, 및 Route Table 상호 확인이 되었으며, 두 리소스 간의 트래픽이 올바르게 허용하도록 구성되었음을 확인했다.

2. 윈도우 내부 방화벽 확인
작업 윈도우 EC2의 모든 방화벽이 내려가 있음을 확인했다. Instance Level이 아닌 OS Level에서 통신이 막히는 게 아닌가 의심했지만 그것도 아니었다.

3. AD 서버 내 자체적으로 Computer Object의 비활성화 유무
여기서 말한 Computer Object는 FSx의 PowerShell Endpoint 이름 앞부분의 'amznfsx********. domain.com'의 'amznfsx********' 이름을 의미한다. 비활성화된 것은 아닌 것을 확인했다.

3. FSx의 PowerShell Endpoint와 5985 포트 통신 테스트
"Test-NetConnection -ComputerName <FSx PowerShell Endpoint> -Port 5985" 명령어를 사용하여 트러블 슛 해보라는 AWS 공식 도큐먼트를 찾아 수행해보았다. (참고: https://docs.aws.amazon.com/fsx/latest/WindowsGuide/remote-pwr-shell.html) 결과는 통신 오류. 방화벽 및 네트워크 통신에는 이상이 없지만, 명령어가 수행이 안 되는 것을 보면 FSx PowerShell Endpoint 자체적으로 무언가 잘못됐음을 짐작할 수 있었다. 

명령어 실행 전, AD에 조인되어 있는지, 그리고 PowerShell을 AD user로 열어 확인해주자.

정상적인 출력 화면

4. nslookup 명령어로 FSx DNS name과 FSx PowerShell Enpoint 확인하기
여기서 FSx DNS name과 FSx poweshell endpoint가 반환하는 주소가 같음을 확인했으며 이 둘의 IP주소는 동일하면 안 된다. 이것이 문제였다. (왜 안되는지는 밑에서 다루겠다.)

보통 AD 정보를 기입하여 FSx를 구성하면 자동으로 AD에 필요한 정보가 업데이트되는데, 어떤 이유로 이 정보가 잘못 올라갔거나 누군가 수정했을 가능성이 크다. 비슷한 이유로 AD서버에 있는 FSx의 도메인 레코드 값을 관리자가 모르고 지우면 똑같은 일이 발생하게 된다. 범인이 누가 되었건 간에 해결 방법이 있을까? 각 case 별 해결 방법을 정리해 보았다.

---

어떻게 해결할까...

CASE 1: AD 관리자가 실수로 FSx 정보 값을 지웠고, recycle bin에 아직 정보가 남아있을 경우
만약 관리자가 모르고 실수로 지웠다면, 간단하게 recycle bin에 들어간 해당 정보를 다시 가져오면 된다. 이 경우, 문제는 쉽게 해결된다.

CASE 2: AD 관리자가 실수로 FSx 정보 값 정보를 완전히 지워버린 경우
선택 1:FSx 콘솔 환경에서 우리가 없을 수 있는 정보는 FSx의 IP주소 하나뿐이며, 이 IP주소는 FSx DNS name이다. FSx PowerShell Endpoint의 IP주소가 무엇인지는 우리가 알 수 없다. AWS 내부 인력의 도움이 없다면 우리가 알 턱이 없으며, 이럴 경우, 기존의 FSx를 카피하여 새로운 FSx 생성해 AD 서버에 자동으로 레코드 값이 올라가도록 유도하는 수밖에 없다.

선택 2: 위에도 언급했듯이 우리는 FSx PowerShell Endpoint의 IP 값을 알지 못한다. 그렇다면 Global Support의 Case Open 하여 상황을 설명하고 내부 직원의 협조를 요청해야 한다. 나의 경우, 이 방법으로 우리가 알 수 없는 PowerShell Enpoint의 IP주소 값을 알아냈고 직접 AD 서버에 정보를 수정하여 문제를 해결했다.

dns name과 powershell endopint는 절대 같은 값일 수 없다.

---

 

FSx의 DNS name과 PowerShell Endpoint가 바라보는 IP주소는 다르다

내가 사용한 FSx는 Single AZ2 타입이었으며, 이 기준으로 FSx를 생성하면 내부적으로 아래와 같이 3개의 Computer Object가 생성되게 된다.

• Cluster
  Cluster 개체는 아무런 IP주소를 갖지 않는다.
  
  
• Primary Private IP
  FSx 콘솔 화면에서 우리가 볼 수 있는 File Serve IP주소는 'Primary Private IP' 컴퓨터 개체에 대한 IP주소이다.
  
  
• PowerShell Endpoint
  'PowerShell Endpoint' 개체의 IP주소는 다른 이와 다른 IP이며, FSx 콘솔에 표시되지 않는다. 적어도 내가 아는 한, 해당 IP 주소를 알아내려면, FSx 생성 시, AD에 자동 등록된 정보를 확인하거나, AWS에 문의해야 알 수 있다.
  

나의 경우, 'PowerShell Endpoint'와 'Primary Private IP' 개체가  'Primary Private IP' 개체에 속한 동일한 IP주소를 바라보고 있는 잘못된 설정 구성으로 FSx PowerShell Enpoint에 연결할 수 없었던 것이었다. 별 것 아닌 설정 하나에 애를 먹었다.