서버 시스템에서 VPN에 로그인 한 후 SSH 연결 손실 방지

처리 할 수없는 문제가 발생했습니다. SSH를 통해 VPS에 로그온하고 해당 VPS에서 VPN 연결을 설정하려고하면 VPS와 컴퓨터 간의 SSH 연결이 끊어집니다. VPN 설정에 의해 라우팅이 변경 되었기 때문이라고 생각합니다. 그것을 막는 방법?

VPS의 OpenVPN 클라이언트 구성 파일에 route-nopull옵션 을 추가 redirect-gateway하고 존재 하는 경우 제거 해야합니다.

이렇게하면 VPN 서버에 연결해도 VPS의 경로가 수정되지 않으므로 필요한 경로를 직접 설정할 수 있습니다.

다음 시나리오를 고려하십시오.

1. VPS에는 단일 이더넷 인터페이스가 있으며 IP 주소 4.3.2.1/24로 구성되어 있습니다.
2. VPS는 기본 게이트웨이 4.3.2.254를 통해 인터넷에 액세스 할 수 있습니다
3. VPS가 아직 OpenVPN 연결을 활성화 하지 않았습니다. 따라서 활성화 된 tun 인터페이스 가 없습니다

이러한 시나리오에서 머신 (def-gw 9.8.7.254를 사용하는 머신이 9.8.7.6/24라고 가정)에서 4.3.2.1에 대한 SSH 연결을 성공적으로 설정할 수 있습니다. 따라서 호스트 4.3.2.1과 9.8.7.6이 서로 성공적으로 도달 할 수 있습니다.

이제 SSH 연결이 설정되면 다음과 같이 가정하십시오.

4. VPS 4.3.2.1에서 OpenVPN 연결을 시작합니다.
5. 따라서 새로운 tun0 인터페이스는 동적으로 구성됩니다 (10.10.10.2 PTP와 함께 10.10.10.2 IP가 할당된다고 가정).

이 단계에서 :

• 경우 에는 경로가 해당 지역의 VPS에 원격 OpenVPN을 서버에서 밀어되지 않습니다, 아무 것도 라우팅의 관점에서 변경됩니다, 그리고 당신의 SSH 연결은 전혀 문제없이 살아남을 것입니다. 이 경우 VPN을 통과하는 유일한 트래픽은 원격 OpenVPN 서버 (10.10.10.1)를 향한 트래픽입니다.

• 경우 원격 OpenVPN을 서버가 어떤 경로를 다시 밀어되며, VPS 기본 게이트웨이가 10.10.10.1 (원격 OpenVPN의 엔드 포인트)로 대체됩니다 expecially에 있다면, 그때 당신은 문제가 있습니다. 이 경우 VPN 내에서 나가는 모든 IP 트래픽 (OpenVPN 자체 제외)을 터널링 합니다.

이 두 번째 경우 (VPN 연결을 설정 한 직후 def-gw 교체) 이전 비대칭 라우팅으로 인해 이전 SSH 연결이 "중지됩니다".

• 머신 (9.8.7.6)에서 VPS (4.3.2.1) 로의 트래픽은 이전의 변경되지 않은 경로를 통해 흐릅니다.
• VPS (4.3.2.1)에서 시스템 (9.8.7.6)으로의 트래픽 :
  • VPN이없는 (따라서 처음에는) 4.3.2.254 게이트웨이를 통해 라우팅되었습니다.
  • VPN 링크를 설정 한 후 관련 def-gw 교체와 함께 VPN (10.10.10.1)을 통해 라우팅됩니다.

즉, VPN 링크가 설정 되 자마자 VPS에서 시스템으로의 반송 경로가 변경 될 것입니다. 이것은 좋지 않습니다 (반환 경로를 따라 여러 네트워크 장치가 이러한 비대칭을 인식 할 수 있음) 경로와 단순히 패킷을 삭제).

또한 원격 OpenVPN 서버가 NAT 상자 역할을 할 가능성이 높습니다. VPN에서 들어오는 모든 트래픽은 원격 OpenVPN 서버의 공개 IP 주소로 NAT됩니다. 이것이 사실이라면 SSH 연결의 경우와 같이 더 이상 "좋지 않은"것이지만 확실히 "나쁜"것보다 다른 경로를 따라 돌아 오는 것 외에도 트래픽을 반환하면 시스템 으로 돌아옵니다. 다른 소스 IP (VPN 서버의 공용 인터페이스 중 하나)

이 문제를 해결하는 방법?

실제로 아주 쉽게.

VPS 서버 에 VPN을 따라 시스템으로 트래픽을 라우팅하지 말고 대신 이전 경로를 사용하도록 지시하십시오 . OpenVPN을 시작하기 전에 추가하는 것만 큼 쉬워야합니다.

     route add -host 9.8.7.6 gw 4.3.2.254

어디:

• 9.8.7.6은 시스템 공용 IP 주소입니다
• 4.3.2.254는 VPS의 원래 기본 게이트웨이입니다.

추신 : 훨씬 자세한 질문을 제공하면 훨씬 빠른 답변을 얻을 수 있습니다 :-)

도움이 될 수 있습니다.

넣어 TCPKeepAlive=yes에/etc/ssh/sshd_config

에서

man sshd_config | less +/'^ *TCPKeepAlive'

TCPKeepAlive

시스템이 다른쪽에 TCP keepalive 메시지를 보내야하는지 여부를 지정합니다. 전송 된 경우 연결이 끊어 지거나 시스템 중 하나의 충돌이 올바르게 감지됩니다. 그러나 이것은 경로가 일시적으로 다운되면 연결이 끊어지고 일부 사람들은 성가신 것을 알게됩니다. 반면, TCP 연결이 전송되지 않으면 세션이 서버에서 무기한 중단되어``고스트 ''사용자가 남고 서버 리소스를 소비 할 수 있습니다.

기본값은 yes'' (to send TCP keepalive messages), and the server will notice if the network goes down or the client host crashes. This avoids infinitely hanging sessions. To disable TCP keepalive messages, the value should be set tono ''입니다.

나는이 문제가 있었고 모든 권장 해결책을 시도했지만 여전히 내 문제는 해결되지 않았습니다!

많은 시도 시도 후, 나는 screen명령을 사용했다 . 내 VPN 클라이언트는 cisco-any-connect입니다.

$ screen -R VPN
$ openconnect -b "your server"

자격 증명을 제공 한 후에는 즉시 Ctrl + a + d를 눌러 세션으로 돌아갑니다.

개인적으로 저는 SSH를 통한 모든 연결이 VPN을 통해 라우팅되는 것을 선호합니다. VPN이 설정되기 전에 활성 ssh 연결의 경우 경로가 변경되어 다시 연결해야합니다.

autossh ssh 클라이언트 구성에서 다음을 추가 하는 것이 좋습니다..ssh/config

Host *
   ServerAliveInterval 300
   ServerAliveCountMax 2
   BatchMode yes

• BatchMode 는 자동 재 연결을 나타냅니다
• ServerAlive 는 Keep Alive의 약자

VPN 연결 후 ssh는 VPN 서버를 통해 이동하는 서버의 ssh 트래픽 때문에 연결이 끊어집니다. 이를 피하려면 VPN을 연결하기 전에 다음 명령을 실행하십시오.

경로 추가 -host your-machine-public-ip gw 서버 -gatway-ip dev eth0

your-machine-public-ip : SSH를 수행하는 컴퓨터의 IP입니다. Server-gatway-ip : 해당 서버의 Gatway / router IP

위 명령은 VPN 서버가 아닌 지정된 게이트웨이를 통해 트래픽을 리디렉션합니다.