VPN over SSH 연결 수 있습니다 (wlan0에서 하나와 ppp0에서

사무실 네트워크 내에서만 SSH를 통해 액세스 할 수 있도록 구성된 AWS EC2 서버가 있습니다. 분명히 이것은 누군가가 EC2 인스턴스에 연결해야하고 출장 중과 같이 사무실 밖에서 원격으로 작업하는 원격 배치에는 적합하지 않습니다.

PPTP를 통해 VPN을 설정하고 사무실 네트워크에 연결할 수 있습니다 (wlan0에서 하나와 ppp0에서 하나의 로컬 IP 두 개가 있음). 그러나 EC2 인스턴스에 SSH를 연결할 때 여전히 네트워크 외부에서 ssh를 시도하고 있기 때문에 여전히 나를 거부하고 있습니다.

문제는 ssh 트래픽을 라우팅하여 VPN을 통과 할 수 없다는 것입니다. 내가 어떻게 이것을 달성 할 수 있습니까?

내 다른 옵션은 사무실 네트워크 내 컴퓨터로 ssh 한 다음 해당 컴퓨터를 사용하여 EC2 인스턴스로 ssh하는 것이지만 과도한 것처럼 보이기 위해 주저했습니다.

답변

IP “your.ec2.ip.address”의 SSH를 통해 AWS에 연결할 수 있다고 가정합니다. 사무실 네트워크에 라우터를 통해 인터넷에 액세스하여 NAT 변환을 적용한다고 가정하면 인터넷에서 IP “your.office.external.ip”를 사용하여 사무실 PC를 볼 수 있습니다.

다음 과 같이 전 세계에 연결된 랩톱을 사용하여 사무실 외부 에 있다고 가정 해 봅시다 .

  • 로컬 인터넷 제공 업체가 할당 한 기본 IP 주소 (netmask 255.255.255.0 및 def-gw 192.168.0.1이있는 192.168.0.33이라고 가정);
  • 원격 PPTP 서버에 의해 랩톱에 할당 된 PPP0 주소 (VPN 터널이 성공적으로 설정되면) PPP0이 .remote.pptp.address 인 원격 P2P를 가진 .local.ppp0.ip라고 가정 해 봅시다. 다시 말해, 랩탑은 the.local.ppp0.ip라는 것을 알고 있으며 VPN 터널의 다른쪽에는 VPN을 통해 .remote.pptp.address에 도달 할 수있는 PPTP 서버가 있음을 알고 있습니다.

이러한 시나리오에서, 노트북에서 “your.ec2.ip.address”로 AWS에 연결할 수 없는 경우 문제는 라우팅이라고 생각합니다. SSH 트래픽이 ” your.ec2.ip.address가 ” NOT 대신, 일반, 외부 VPN, 경로를 따라 떠나는되면, VPN 내에서 넷북을 떠나 있지만 (일명 : 192.168.0.1 : 해당 지역의 게이트웨이로 전송됩니다).

이 문제를 진단하기 위해 다음을 사용하여 매우 쉽게 확인할 수 있습니다.

  • Linux : tracepath 명령 (예 : “tracepath -n your.ec2.ip.address”)
  • windows : “tracert”명령 (예 : “tracert -d your.ec2.ip.address”)

출력에서 두 번째 단계에서 PPTP 주소를보고하는지 여부를 확인할 수 있습니다.

트래픽이 잘못된 경로를 따라 이동하는 경우 VPN 내에서 쉽게 라우팅 할 수있는 방법은 다음과 같습니다.

  • 리눅스 : “경로 add -host your.ec2.ip.address gw the.remote.pptp.address”
  • Windows : “경로를 추가하십시오. ec2.ip.address 마스크 255.255.255.255 the.remote.pptp.address”

위의 경로를 구성한 후 tracert / tracepath를 사용하여 라우팅을 다시 확인할 수 있습니다

라우팅이 올바르게 구성되면 사무실 내에서 문제가 발생할 가능성이 약간 있습니다. PPTP 서버가 IP 전달 및 NAT 변환을 수행 하지 않는 경우 “필터링”이 발생할 가능성이 높습니다. 노트북과 your.ec2.ip.address 사이에 ip 전달 또는 “비대칭 라우팅”(NAT가 누락 된 경우) 누락 :

  • 귀하와 아마존으로의 트래픽, VPN을 따라 귀하의 사무실, 그리고 그때부터 아마존까지의 교통;
  • 아마존에서 당신에게 트래픽을 반환, 일반적인 인터넷 경로를 따라 라우팅되고 … 어딘가에 떨어질 가능성이 높습니다.

다시 한 번 : tracepath / tracert를 사용하면 문제를 확인할 수 있습니다.

리눅스 박스에서 또 다른 유용한 친구는 “tcpdump”입니다. 유용한 tcpdump 명령은 다음과 같습니다.

  • “tcpdump -n -i interface icmp”는 들어오고 나가는 PING 요청 / 응답을 확인합니다.
  • “tcpdump -n -i 호스트 an.ip.add.ress “는 ” .add.ress에 도착 / 전송 된 트래픽을 확인합니다.

답변