VPN에서 SSH가 매분 끊기나요? keepalive가 원인이 아닙니다

SSH가 연결되고 일 분 정도 작동하다가 매번 거의 같은 간격으로 멈춥니다. 흔한 설명은 유휴 시간 초과라서 사람들은 MTU를 낮추고 클라이언트 keepalive를 설정합니다. 제가 작업한 WireGuard 링크는 이미 그 모든 것을 거쳤습니다. 더 작은 터널 MTU, client-alive 설정, 구성된 터널 keepalive입니다. 끊김은 변함없이 계속되었습니다. 원인은 비대칭 LAN 경로였고, 이 패턴은 타이머 기반 수정을 모두 무력화하므로 알아둘 가치가 있습니다.

keepalive는 호스트가 여전히 보낼 의사가 있음을 증명합니다. 결코 통과하지 않는 응답을 상태 저장 장치가 보게 만들 수는 없습니다.

신화: keepalive가 조용한 끊김을 고친다

SSH keepalive는 한 가지 일만 합니다. 침묵을 세는 무언가가 유휴 세션을 정리하지 못하게 하는 것입니다. 그 일은 잘합니다. 한 방향으로 첫 패킷을 본 뒤 응답을 전혀 보지 못한 상태 저장 장치의 문제는 해결하지 못합니다. 클라이언트가 보내는 무엇도 응답이 어느 인터페이스를 쓰는지 바꾸지 않기 때문입니다.

MTU 변경도 인기 있는 수정이며 같은 실패 방식을 가집니다. MTU를 낮추면 단편화와 경로 MTU 문제에는 도움이 되지만 경로에는 아무것도 하지 않습니다. 타이머와 MTU가 이미 합리적인데도 끊김이 반복 간격으로 계속된다면, 그 간격은 어딘가의 시간 초과를 말하는 것이지 패킷 크기를 말하는 것이 아닙니다. 간격을 적어 두고 경로의 모든 장치에서 상태 시간 초과와 비교하세요.

단서는 규칙성과 그 간격 안에서 세션이 계속 쓸 수 있는 상태의 조합입니다. 유휴 시간 초과는 아무 일도 없을 때 발생합니다. 이것은 입력하는 동안 발생합니다.

추가 게이트웨이가 실제로 하는 일

노트북과 VPN 게이트웨이를 같은 LAN에 두고, 별도의 LAN 방화벽을 기본 게이트웨이로 둡니다. 노트북은 VPN으로 향하는 트래픽을 방화벽으로 보내고, 방화벽은 그것을 게이트웨이로 전달하며, 게이트웨이의 응답이 LAN을 지나 노트북으로 곧장 돌아옵니다. 그 두 번째 구간은 방화벽을 결코 통과하지 않으므로 상태 테이블은 연결의 절반만 보유합니다.

아래 주소는 그 배치를 반영합니다.

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

그런 다음 리디렉션과 상태 처리가 작동하는 핸드셰이크를 즉시가 아니라 나중에 죽는 연결로 바꿉니다. 지연은 상태 항목이 만료되거나 더 엄격한 검사가 실패하는 것이며, 그래서 간격이 그렇게 기계적으로 보입니다.

이 중 어느 것도 클라이언트 구성에 나타나지 않으므로 그 조사는 보통 잘못된 파일에서 시작됩니다.

의도한 경로 하나를 고르세요

위 배치에서는 원격 서브넷을 VPN 게이트웨이로 직접 라우팅하면 절반의 연결이 사라집니다.

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

이것은 예시 주소입니다. 다음 홉은 당신의 LAN에서 도달 가능해야 하고, 접두사는 의도한 원격 네트워크여야 하며, 두 번째 명령은 그것에 의존하기 전에 결과를 보여 줍니다. 게이트웨이가 당신의 서브넷에 없다면 이 경로는 원하는 수정이 아닙니다.

방화벽이 그 시스템들 사이의 트래픽을 감시하기 위한 것이라면, 그것을 우회하는 라우팅은 잘못된 설계입니다. 대신 양방향이 경계를 통과하게 하고 각 측의 경로를 설정해 반환 경로가 일치하게 하세요. 목표는 상태 검사를 줄이는 것이 아니라 의도한 단일 경로입니다.

Netgate의 비대칭 라우팅에 관한 노트는 같은 인터페이스 수준의 비대칭성과 그것이 만드는 상태 문제를 설명하므로, 상태 처리를 전 세계적으로 완화하기 전에 읽어 보세요. 이 사례와 비슷한 정기적 연결 끊김은 그 자체로 증거가 아닙니다. 기사를 하나의 실패 모드 설명으로 다루고, 전역 상태 정책을 바꾸기 전에 자신의 네트워크가 그것과 일치함을 증명하세요.

양쪽 끝에서 시험하세요

노트북에서 목적지로 가는 경로와 목적지에서 노트북으로 돌아오는 경로를 읽으세요. 이는 두 개의 별개 결정이며 아마도 둘 중 하나만 틀렸습니다. 게이트웨이 자체에서 성공하는 ping은 문제를 완전히 숨길 수 있습니다. 경로가 이미 올바른 기계에서 시작되기 때문입니다. 실제 세션의 양쪽 끝이 보는 양방향이 필요합니다.

수정 후 SSH를 다시 열고 예전에 실패하던 간격을 훨씬 넘겨 세션을 열어 두세요. 그런 다음 승인된 네트워크 구성에서 경로를 영구적으로 만드세요. 일회성 명령은 재부팅 계획이 아니며 다음 재부팅 때 문제가 새로운 수수께끼와 함께 돌아옵니다.

비대칭성이 괜찮을 때

비대칭 라우팅은 많은 네트워크에서 정상이며 정의상 고장이 아닙니다. 상태 추적, 변환 또는 정책이 보지 못하는 경로를 보는 데 의존할 때 문제가 되며, 각각 다른 해결책이 있습니다. 그 주위를 재설계하기 전에 중간 장치가 실제로 무엇을 요구하는지 확인하세요.

오래 가는 답은 두 경로, 둘 다 봐야 하는 장치, 그리고 그것을 가능하게 하는 경로를 지목합니다. 장치를 지목할 수 없다면 아직 원인을 찾지 못한 것입니다.