SSH로 VPN 클라이언트를 시작하시나요? 먼저 자신의 경로를 고정하세요

빌드 호스트에 SSH로 접속해 VPN 클라이언트를 시작하면 세션이 응답을 멈춥니다. 아무것도 충돌하지 않았고, 명백한 의미에서 잘못 구성된 것처럼 보이지도 않습니다. 클라이언트가 기본 경로를 설치했기 때문에 워크스테이션으로 가는 응답이 이제 터널을 통해 나가며, 그곳에서는 워크스테이션 주소로 라우팅할 수 없습니다. 흥미로운 점은 이 결과가 예측 가능했다는 것이고, 해결책은 클라이언트가 시작되기 전에 기록하는 경로 하나입니다. 서버에 네트워크 카드가 하나 있고 게이트웨이가 192.0.2.254이며 관리자가 203.0.113.9에서 접속한다고 가정하겠습니다.

시작하기 전에 경로를 기록하세요

ip route show default는 현재 게이트웨이와 인터페이스를 알려 주고, ip route get 203.0.113.9는 커널이 이 세션에 어떤 인터페이스와 소스 주소를 쓸지 보여 줍니다. 두 출력을 모두 보관하세요. 터널이 올라온 뒤에도 이 두 명령은 물리적 경로를 설명해야 하며, 만약 대신 터널을 설명한다면 세션은 이미 빌려온 시간 위에서 살고 있습니다.

중요한 것은 이미 수립된 연결이므로 새로운 로그인만으로 검증하지 마세요. 새 세션은 예전 세션이 더는 가지지 못한 상태 덕분에 잠시 성공할 수 있습니다.

주소는 클라이언트 자체 구성에서 고정하세요

손으로 추가한 경로는 재부팅 시 사라지고 클라이언트 자체의 테이블 갱신과 경쟁하므로, 예외는 테이블이 관리되는 곳에 두세요. OpenVPN에서는 net_gateway 키워드가 터널 이전에 있던 게이트웨이로 해석되므로 route 203.0.113.9 255.255.255.255 net_gateway는 정확히 한 주소를 그 바깥에 유지합니다. WireGuard는 wg-quick이 경로를 직접 관리하므로 다른 접근이 필요합니다: Table = off를 설정하고 PostUp에 예외를 추가하며, 그것을 제거하는 대응 PostDown를 함께 두세요. 두 형식은 같은 의도를 표현하고, 둘 다 모든 것에 대해 터널을 약화하는 대신 예외를 한 주소로 한정합니다.

IPv6에서는 같은 아이디어로 단일 호스트 접두사를 쓰며, 캡슐화된 전송 사례도 기억할 만한데, 터널 자체의 외부 연결이 고정 주소에 있다면 그 주소는 자신이 나르는 터널 바깥에 남아야 하며, 그렇지 않으면 클라이언트가 자기 전송을 자기 안으로 라우팅합니다.

아니면 메인 테이블을 논외로 두세요

호스트의 여러 서비스가 평소 경로를 유지해야 한다면 메인 테이블 편집을 멈추고 클라이언트에 자체 테이블을 주세요. veth 쌍이 있는 네트워크 네임스페이스가 이것을 깔끔하게 합니다: 클라이언트의 기본 경로는 다른 스택에 살고 그 안에서 시작한 프로세스만 터널을 사용합니다. 정책 라우팅은 목적지 하나에 대해 비슷한 지점에 도달합니다: 일치하는 트래픽을 전용 테이블로 보내고 그 기본값은 여전히 물리 게이트웨이를 가리키게 합니다. 두 접근 모두 호스트의 메인 테이블에 새 기본 경로를 남기지 않으며, 그 성질이 SSH가 응답하도록 유지합니다.

둘 다 호스트 경로 하나보다 많은 장치이며, 머신에서 하나 이상이 터널을 견뎌야 한다면 둘 다 값어치가 있습니다.

고정이 실패할 수 있다고 가정하세요

현재 공용 주소에 묶인 경로는 공급자가 그 주소를 다시 할당하는 순간 끊어집니다. 그때 원격 서버에는 그 주소에 의존하지 않는 경로 — 콘솔, 두 번째 관리 인터페이스, 또는 터널 밖에 남는 점프 호스트 — 가 필요합니다.

두 가지 안전장치는 십 분이면 됩니다. 몇 분 안에 확인 로그인이 나타나지 않으면 클라이언트를 멈추는 감시자는 잠김을 지연으로 바꾸고, 변경 중에 열어 둔 두 번째 SSH 세션은 터널이 올라간 상태에서 예외가 작동함을 증명합니다. 키프얼라이브만으로는 경로가 유휴 상태가 아니라 사라졌기 때문에 여기서 도움이 되지 않으며, 죽음을 알아차리기 쉽게 만들 뿐입니다.

중요한 순서로 검증하세요

터널을 연결하고, 내 주소로 가는 경로가 여전히 물리 게이트웨이로 나가는지 확인한 다음 새 세션을 여세요. 새 세션이 되고 예전 세션이 그래도 죽는다면 원인은 라우팅이 아니라 연결 추적이나 상태 저장 방화벽이며, 그것은 다른 해결책입니다.

고정한 주소와 그것을 증명한 명령을 변경 기록에 적으세요. 그 호스트에서 다음에 클라이언트를 시작할 사람에게는 둘 다 필요하고, 그때는 주소가 이미 바뀌었을 수 있습니다.