호스트가 아웃바운드 VPN을 실행할 때 로컬 SSH 유지

작은 Linux 서버가 호스팅하는 애플리케이션을 위해 아웃바운드 VPN을 실행하고 있으며, 관리자는 여전히 옆자리 책상에서 SSH로 접속하고 싶어 합니다. 이는 합리적인 요구이며 보통 포트 포워딩도, 공급자 주소도, 터널의 구멍도 필요로 하지 않습니다. 필요한 것은 VPN 클라이언트가 라우팅 테이블에 한 일을 물려받는 대신 의도적으로 설계된 관리 경로입니다.

아래 단계는 관리자가 같은 LAN에 있다고 가정합니다.원격 관리는 다른 답을 가진 다른 문제입니다.

SSH를 관리자가 사용하는 주소에 바인딩하세요

리스너부터 시작하세요.ss -ltnp | grep :22sshd가 무엇에 바인딩되었는지 보여주며, 0.0.0.0의 리스너는 터널을 포함한 모든 인터페이스에서 연결을 받습니다. LAN 주소에 바인딩하는 것은 더 좁고 의도를 드러냅니다:ListenAddress 192.168.10.20안의sshd_config에 두고 이어서 구성 테스트와 다시 로드를 합니다. 그 주소의 오타는 주소가 없으면 sshd가 시작을 거부하기 때문에 와일드카드보다 잘 보입니다.

호스트 키 확인과 사용자별 인증은 그대로 두세요. „로컬 네트워크일 뿐이다“는 인증 방법이 아니며, 경로가 짧다고 키 검증을 건너뛰는 관리 채널은 남용을 기다리는 채널입니다. DHCP 예약이나 고정 주소는 대상을 예측 가능하게 만들되 서버의 공개 정체성으로 만들지는 않습니다.

LAN 경로를 터널 밖에 유지하세요

192.168.10.0/24 주소를 가진 호스트는 그 접두사에 대한 연결 경로가 있고, 더 구체적인 경로는 같은 테이블에서 VPN의 기본 경로를 이깁니다. 그래서 터널이 올라와도 로컬 SSH가 흔히 저절로 계속 동작합니다. 가정하지 말고 확인하세요:ip route get 192.168.10.50커널이 사용할 인터페이스와 소스 주소를 알려주며, 답은 터널이 아니라 LAN 장치여야 합니다. 패킷이 애초에 도착하는지는 그쪽 테이블이 결정하기 때문에 관리자의 머신에서도 확인을 반복하세요. 같은 케이블의 두 호스트가 어느 방향이 도달 가능한지에 대해 의견이 다를 수 있습니다.

가정은 두 곳에서 깨집니다. 정책 기반 라우팅 규칙은 기본 테이블을 보기 전에 기본 경로가 터널을 가리키는 테이블로 트래픽을 보낼 수 있습니다. 잠금 또는 kill switch 기능이 있는 VPN 클라이언트도 라우팅 테이블이 무엇을 말하든 터널로 들어가지 않는 트래픽을 차단할 수 있습니다.

라우팅된 관리 VLAN이 다른 경우입니다. 관리자가 로컬 라우터 뒤의 192.168.50.0/24에 있다면 서버는 그 접두사에 대해 192.168.10.1을 거치는 명시적 경로가 필요하고, 그 경로는 재연결에서 살아남아야 합니다. 예외는 관리 접두사에만 국한해야 하며, 사설 범위에 대한 넓은 예외는 터널의 목적을 무력화합니다.

방화벽 예외를 규칙만큼 좁게 만드세요

호스트가 방화벽을 실행한다면 SSH를 관리 소스에서만, LAN 인터페이스에서만 허용하세요. 22번 포트를 어디서나 허용하는 규칙은 요구보다 넓고 검토에서 정당화하기 어렵습니다. nftables 호스트에서는 규칙이 인터페이스와 소스를 일치시킨 입력 체인에 들어가고, iptables 호스트에서는 동등한 것이-i와-s 에 대한 두 일치의 쌍입니다. 규칙에 그것이 지원하는 관리자 그룹을 주석으로 달아 두면 다음 감사에서 22번 포트가 왜 열려 있는지 추측할 필요가 없습니다.

VPN 클라이언트 자체의 필터도 확인하세요. 일부 클라이언트는 설계상 로컬 트래픽을 버리는 규칙을 설치하며, 클라이언트 수준 드롭 위에 올바른 방화벽 규칙을 두어도 아무것도 바뀌지 않습니다. 직렬의 두 필터가 어느 쪽과도 닮지 않은 장애를 만들기 때문에 호스트 방화벽을 편집하기 전에 클라이언트 구성을 읽으세요.

두 상태를 모두 테스트하세요

테스트를 두 번 실행하세요: 한 번은 터널이 연결된 상태에서, 한 번은 연결이 끊긴 상태에서. 각 상태에서 리스너, 경로, 그리고 관리자의 머신에서 실제 SSH 로그인을 확인하세요. 터널이 올라와 있는 동안에만 동작하는 경로는 로컬 관리 경로가 아니라 우연입니다.

그다음 SSH 세션이 열려 있는 동안 터널을 다시 시작하세요. 살아남은 세션은 라우팅이 안정적임을 증명하고, 끊긴 세션은 클라이언트가 재연결 시 경로나 필터를 다시 쓴다는 것을 알려주므로, 이는 사고가 발생한 뒤보다 전에 알아 둘 가치가 있습니다.

192.168.10.50에 대해 작성한 규칙은 관리자의 노트북이 다른 서브넷으로 옮겨가면 조용히 실패하므로 테스트한 소스 주소를 기록하세요.

복구 경로를 runbook에 쓰세요

아웃바운드 VPN이 로컬 경로를 깨뜨리면 어떻게 되는지 지금 결정하세요. 콘솔 접속, 두 번째 관리 주소, 또는 클라이언트를 중지하는 문서화된 절차는 모두 정당한 답이며, 그중 어느 것이든 로그인해야 하는 순간에 문제를 발견하는 것보다 낫습니다. 서버가 원격이라면 로컬 경로는 존재하지 않으며, 올바른 설계는 노출된 공용 포트가 아니라 별도로 승인된 원격 접속 경로나 배스천입니다.

문서에서 두 역할을 분리하세요: 가까이 있는 관리자를 위한 로컬 SSH와 애플리케이션 트래픽을 위한 아웃바운드 터널입니다. 그 역할이 적혀 있으면 둘 중 하나에 대한 향후 변경을 확인할 명확한 위치가 생기고, 다음 사람이 VPN이 있는 서버가 왜 여전히 LAN 주소에서 응답하는지 다시 알아낼 필요가 없습니다.