전체 터널이 SSH 세션을 죽였습니다: 귀환 경로를 고정하세요

SSH 로 작업 중인 머신에서 OpenVPN 클라이언트를 실행하면 명령 도중에 세션이 멈춥니다. 터널은 연결되었다고 보고하고, 호스트는 터널을 통해 인터넷에 닿으며, 키 입력은 계속 도착하는데 아무것도 돌아오지 않습니다. 달라진 것은 터널이 아닙니다: 자신에게 보내지는 패킷의 귀환 경로가 새 기본 경로와 일치하면서, 원격 게이트웨이가 당신의 책상까지 오는 데 쓰지 않을 터널로 들어가는 것입니다.

redirect-gateway 가 실제로 설치하는 것

그 def1 형식에서는 redirect-gateway 기본 경로를 덮어쓰는 대신 0.0.0.0/1 과 128.0.0.0/1 를 추가합니다. 이 두 반쪽은 주소 공간 전체를 덮으면서 둘 다 0.0.0.0/0 보다 긴 프리픽스로 남기 때문에, 더 구체적인 일치가 없는 목적지는 이제 모두 터널로 들어갑니다. 아래의 모든 수정이 더 구체적인 일치를 설치하는 방식으로 동작하므로, 이것이 기억해야 할 메커니즘입니다.

관리 주소도 그런 목적지 가운데 하나입니다.

VPN 서버는 클라이언트의 트래픽을 인터넷으로 전달합니다. 당신이 접속해 오는 공인 주소에 대한 경로가 없고, 그 패킷을 클라이언트에서 오는 트래픽과 다르게 취급할 이유도 없으므로 그냥 버립니다. 한편 당신이 보낸 요청은 호스트에 도달했기 때문에, 세션은 한쪽에서만 살아 있는 것처럼 보입니다.

ip route show table main | head -n 20
ip route get 198.51.100.23

출발지 주소와 터널 이전의 경로를 찾으세요

서버에서 설정된 SSH 연결을 나열하고 그것이 어디서 왔는지 피어 주소를 기록합니다. 귀환 경로가 덮어야 하는 것이 바로 그 주소이며, 늘 당신이 생각하는 주소는 아닙니다: 점프 호스트, NAT 게이트웨이, 통신사 트랜슬레이터가 다른 출발지를 넣을 수 있습니다.

다음으로 터널이 시작되기 전에 트래픽을 실어 나르던 물리 게이트웨이와 인터페이스를 찾습니다. def1 구성에서는 기본 경로가 반쪽 기본 경로 아래에 그대로 남아 있으므로 정보는 얻을 수 있지만, 긴 라우팅 테이블을 눈으로 읽는 것은 실수를 부릅니다.

두 값과 인터페이스 이름은 곧 추가할 경로에 세 가지가 모두 필요하므로 함께 기록하세요. 호스트가 상위 링크를 고르는 데 정책 라우팅 규칙을 썼다면 단순한 경로는 아예 참조되지 않을 수 있고, 그 가능성이 수정 방식을 바꿉니다.

반쪽 기본 경로를 앞서는 호스트 경로를 고정하세요

하나의 /32 경로는 두 반쪽 기본 경로 어느 쪽보다 길기 때문에, 당신 주소로 가는 응답은 터널 대신 이 경로를 택합니다. 다음 홉은 터널 이전의 게이트웨이이고 장치는 물리 인터페이스이며, 이는 패킷을 터널이 생기기 전에 쓰던 길에 붙잡아 둡니다.

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

테이블을 들여다보는 대신 조회로 확인하세요: 답은 반드시 eth0 과 게이트웨이를 지목해야 하며, 결코 tun0 을 지목해서는 안 됩니다.

OpenVPN 은 같은 이유로 이미 VPN 서버 자체 주소로 가는 호스트 경로 를 추가하므로 이 패턴은 익숙하고, 관리 주소는 그저 또 하나의 예외일 뿐입니다. 이것을 고치려고 route-nopull 에 손을 뻗지 마세요, 터널이 필요로 하는 푸시된 경로를 버리게 되고 원격 네트워크와 DNS 옵션도 함께 사라집니다.

재접속에도 살아남게 만드세요

손으로 추가한 경로는 클라이언트가 다시 접속해 자기 경로를 설치할 때 사라지므로, 수정이 반복되는 장애가 됩니다. 경로가 설치된 뒤에 실행되는 무언가에 명령을 붙이세요.

예를 들어 route-up 스크립트든 네트워크 관리자의 pre-up 훅이든 동작하며, 신뢰할 만한 확인은 재접속 뒤 같은 조회를 하는 것입니다.

Windows 에서 같은 역할은 -p 로 추가하는 영구 경로이며, 재부팅을 견디지만 네트워크가 바뀐 뒤에도 올바른 게이트웨이를 가리켜야 합니다. 플랫폼이 무엇이든 경로 옆에 이유를 적으세요: 다음 관리자는 그것이 네트워크 설계의 요구가 아니라 관리 세션을 지키기 위해 존재한다는 것을 알아야 합니다.

고정한 경로로도 충분하지 않을 때

역경로 필터링은 한 인터페이스로 들어와 다른 인터페이스로 나가는 패킷을 버릴 수 있고, 고정 경로가 바로 그런 상황을 만듭니다. 무엇이든 전역으로 끄기 전에 유효한 rp_filter 값을 확인하고, 검사를 끄기보다 비대칭을 고치는 쪽을 택하세요. 적용되는 것은 인터페이스별 설정이며, loose 모드는 패킷을 버리는 대신 비대칭을 기록만 하는 경우가 많습니다. 필터 탓이라고 결론 내리기 전에 둘 다 읽어 보세요.

정책 라우팅을 쓰는 호스트에는 규칙 기반이 그 안의 경로를 참조하기 전에 테이블을 고르므로 경로와 함께 규칙도 필요합니다. main 테이블의 경로는 다른 테이블을 가리키는 규칙에 맞는 흐름에게는 보이지 않습니다. main 에 무엇이든 추가하기 전에 규칙을 읽으세요. 규칙이 이미 관리 트래픽을 덮고 있다면 예외는 그 규칙의 테이블에 들어가야 합니다.

시험하는 동안 대역 밖 콘솔을 열어 두고, 쓰고 있는 로그인을 끊기 전에 두 번째 로그인에서 다시 확인하세요. 자신의 관리 트래픽을 터널로 보내는 경로는 그것을 고치고 있는 연결 자체를 끊습니다. 그러면 다시 들어오려면 시리얼 콘솔이나 복구 부팅이 필요하고, 확인 단계를 하나 건너뛰기에는 나쁜 거래입니다.