VPN을 통한 원격 SSH: 터널이 하지 않는 일

VPN은 SSH 서버에 사설 경로를 제공하고 22번 포트의 공용 리스너 필요성을 없앤다. VPN은 호스트를 인증하지 않고, 사용자를 승인하지 않으며, 어떤 계정이 로그인할 수 있는지도 결정하지 않는다. 그것은 여전히 SSH의 일이다. VPN이 서버에 도달하는 올바른 방법인지는 세 가지 조건에 달려 있고, 터널은 가능한 답 중 하나일 뿐이다.

터널이 바꾸는 것과 SSH가 여전히 결정하는 것

터널은 도달 가능성, 즉 어떤 주소에 어디서 도달할 수 있는지를 바꾼다. TCP 연결이 도착한 뒤에 서버가 호스트 키를 제시하고 사용자 신원을 요구하는 단계에서 일어나는 일은 바꾸지 않는다.

두 계층을 머릿속에서도 문서에서도 분리해 두라. VPN 로그인은 누가 네트워크를 사용할 수 있는지 증명한다. 대상에 어떤 계정이 있는지는 말해 주지 않으며, 도달 가능한 모든 머신에 로그인할 권한도 아니다.

실패 방식도 분리되어 있고, 바로 그것이 사고 중에 이 분리를 유용하게 만든다.

접근 모델을 결정하는 세 가지 조건

첫째, 서버가 네트워크 밖의 사람들에게 도달 가능해야 하는가? 아니라면 사설 경로에 배스천이나 메시를 더하는 것이 더 작은 설계다. 둘째, 제한이 있는 관리 기기의 사용자도 포함해서 클라이언트 집단이 실제로 VPN 클라이언트를 실행할 수 있는가?

셋째, 서비스별 제어가 필요한가, 사용자별 제어가 필요한가? VPN은 네트워크 도달을 부여하고, SSH는 계정 접근을 부여한다. 계약자가 한 호스트에만 도달하면 된다는 요구라면 그것은 권한 부여 요구이며 터널만으로는 표현할 수 없다.

이 세 가지에 답하면 모델은 스스로 정해진다. 건너뛰면 클라이언트 배포를 피하려고 SSH를 공개적으로 노출하게 된다.

SSH를 탓하기 전에 사설 경로를 확인하라

승인된 VPN에 연결하고 대상의 문서화된 사설 이름이나 주소를 사용하라. 그다음 선택된 경로, 게이트웨이의 권한, 클라이언트로 돌아오는 경로를 확인하라. 올바르게 확인되는 이름은 로컬과 원격 프리픽스가 겹치면 요청이 전혀 다른 곳으로 갈 수 있기 때문에 그 주소가 의도한 터널을 탄다는 증거가 아니다. 이 차이는 런북에 적을 가치가 있다.

연결이 끝내 도착하지 않으면, 서버가 예상한 인터페이스에서 수신 중인지 그리고 호스트 방화벽이 실제로 보는 출발지를 허용하는지 확인하라. 게이트웨이 NAT가 그 출발지를 다시 쓸 수 있으므로 클라이언트의 터널 주소용으로 작성한 허용 목록이 결코 맞지 않을 수 있다.

그 불일치가 VPN에서 가장 흔한 자초한 SSH 실패다.

결합된 오류가 아니라 실패 단계를 읽어라

세 단계는 서로 다른 세 메시지를 만들고, 그중 하나만 자격 증명에 관한 것이다.

VPN과 SSH 자격 증명을 함께 재설정하는 대신 정확한 오류와 서버 자체의 로그를 사용하라. 둘 다 재설정하는 것이 오 분 진단을 이틀짜리 신원 사고로 만드는 길이다.

자세한 출력은 어느 단계에 도달했는지 보여 준다:

ssh -vv [email protected]

호스트 키와 권한 부여를 온전히 유지하라

호스트 키는 특히 서버를 교체한 뒤 의도된 신뢰 절차로 검증하라. 예기치 않은 키 변경 경고는 사설 터널이 목적지를 당신이 생각하는 머신으로 만들어 주지 않기 때문에 VPN이 연결되었다는 이유만으로 무시해서는 안 되는 유일한 메시지다. 지문은 연결과 독립적으로 신뢰하는 출처와 대조하라.

서버 쪽에서는 계정이 승인되었는지, 구성한 인증 방법이 실제로 제시되는 방법인지 확인하라. 존재하지만 무시되는 키는 보통 네트워크가 아니라 권한이나 구성 문제다.

서비스 접근을 필요한 신원으로 제한하고 네트워크 변경을 위한 승인된 복구 경로를 유지하라.