VPN이 켜진 상태에서 두 번째 사설 경로로 SSH 사용하기

한 머신이 VPN을 통해 다른 머신에 접속하고, 이제 누군가가 공급자의 사설 네트워크에서 같은 셸을 원합니다. 경로는 있고 ping도 성공하지만 SSH는 여전히 거부합니다. 흔한 원인은 데몬이 새 주소에서 한 번도 수신 대기하지 않았기 때문에 연결할 대상이 없다는 것입니다. 이것은 방화벽 문제가 되기 전에 주소 바인딩 문제입니다.

새 경로가 새 리스너를 만들지 않는 이유

수신 소켓은 연결을 받아들일 주소를 지정하는 프로세스가 만듭니다. 경로는 패킷이 어디로 갈지 알려줄 뿐이며, 목적지에 리스너를 만들지는 않습니다. sshd가 단일 ListenAddress로 구성되면 인터페이스가 작동 중이어도 다른 로컬 주소로의 연결은 거부됩니다. 포트를 소유한 소켓 유닛도 마찬가지이므로 첫 번째 확인은 항상 실제로 무엇이 수신 대기 중인지입니다.

두 경로는 인터페이스 이름이 아니라 목적지 주소로 비교하세요. 클라이언트는 주소에 연결하며, 어떤 방화벽 규칙이든 의미를 가지려면 그 주소가 먼저 바인딩되어 있어야 합니다.

주소와 리스너 나열하기

무엇이든 편집하기 전에 호스트의 주소와 현재 존재하는 소켓을 기록하세요.

ip -br addr
ss -ltnp | grep ':22'

주소 목록은 어떤 사설 주소가 실제이며 어느 인터페이스에 있는지 보여 주고, 소켓 목록은 그것에 무엇이 바인딩되어 있는지 보여 줍니다. 0.0.0.0:22 에서 수신 대기하는 리스너는 이미 모든 주소를 받아들이므로 새 바인딩은 아무것도 추가하지 않습니다. 특정 주소 하나에서 수신 대기하는 리스너는 거부 이유를 즉시 설명합니다. 포트가 데몬이 아니라 소켓 유닛에 속한다면 데몬 구성만으로는 전체 이야기가 아닙니다.

바인딩을 추가하고 기존 바인딩 유지하기

OpenSSH는 여러 ListenAddress 항목을 받아들이므로 사설 경로를 추가하는 동안 VPN 경로를 유지할 수 있습니다. 다시 로드하기 전에 파일을 테스트하세요.

sshd -t
systemctl reload sshd

구성 테스트가 실패하면 실행 중인 데몬은 그대로 유지되며, 편집 중인 경로를 통해 연결된 상태에서는 바로 그것이 원하는 동작입니다. 기존 항목을 유지하고 새 로컬 주소를 추가한 뒤 현재 세션을 끊지 않고 서비스가 다시 로드되는지 확인하세요. 소켓 활성화 설치에서는 대신 소켓 유닛에 주소를 추가하고 해당 유닛을 다시 로드하세요. 그런 다음 바인딩이 전혀 나타나지 않았다면 잘못된 구성 요소를 편집한 것이므로 리스너 목록을 다시 읽으세요.

기존 세션을 닫기 전에 새 세션 검증하기

원래 세션이 열려 있는 동안 새 주소에 연결하고, 자세한 출력으로 어떤 주소와 키가 사용되었는지 확인하세요. 검사가 두 번 성공할 때까지 원래 세션을 열어 두세요.

ssh -v [email protected]

목적지 주소와 제시된 호스트 키에 대한 디버그 줄을 읽으세요. 네트워크가 사설이라고 설명된다는 이유로 알 수 없는 키를 받아들이지 말고, 이미 신뢰하는 값과 호스트 키 지문을 대조해 확인하세요. 새 목적지에는 자체 known_hosts 항목이 필요하며 이는 예상된 일입니다. 사설 경로가 작동한 뒤에야 기존 관리 세션을 닫아야 합니다.

SSH는 전송을 보호하지만 그것만으로 두 네트워크가 동등해지지는 않습니다. 사설 전송의 신뢰가 데이터에 맞는지 의존하기 전에 판단하세요.