สมมติว่า AWS ของคุณสามารถเข้าถึงได้ผ่าน SSH ที่ IP "your.ec2.ip.address" สมมติว่าเครือข่ายสำนักงานของคุณมีการเข้าถึงอินเทอร์เน็ตผ่านเราเตอร์ที่ใช้การแปล NAT และเช่นนั้นพีซีสำนักงานของคุณจะเห็นบนอินเทอร์เน็ตด้วย IP "your.office.external.ip"
นอกจากนี้สมมติว่าคุณอยู่นอกสำนักงานโดยมีแล็ปท็อปเชื่อมต่ออยู่ทั่วโลกด้วย:
- ที่อยู่ IP หลักที่กำหนดโดยผู้ให้บริการอินเทอร์เน็ตในพื้นที่ของคุณ (สมมติว่า 192.168.0.33 กับ netmask 255.255.255.0 และ def-gw 192.168.0.1);
- ที่อยู่ PPP0 ซึ่งกำหนดให้กับแล็ปท็อปของคุณโดยเซิร์ฟเวอร์ PPTP ระยะไกลของคุณ (เมื่อทันเนล VPN ของคุณสำเร็จแล้ว) สมมุติว่า PPP0 คือ the.local.ppp0.ip กับ P2P ระยะไกล the.remote.pptp.address กล่าวอีกนัยหนึ่งแล็ปท็อปของคุณรู้ว่าเป็น the.local.ppp0.ip และรู้ว่าที่อีกฝั่งของอุโมงค์ VPN มีเซิร์ฟเวอร์ PPTP ของคุณที่สามารถเข้าถึงได้ผ่าน VPN ที่ the.remote.pptp.address
ในสถานการณ์เช่นนี้หากคุณไม่สามารถ - จากสมุดบันทึกของคุณ - เพื่อเข้าถึง AWS ของคุณได้ที่ "your.ec2.ip.address" ฉันเดิมพันได้ว่าปัญหาคือ - คุณคาดเดา - การกำหนดเส้นทาง: ปริมาณข้อมูล SSH ของคุณไปที่ " your.ec2.ip.address "จะไม่ปล่อยให้เน็ตบุ๊กของคุณอยู่ใน VPN แต่จะออกไปตามเส้นทางภายนอก VPN ทั่วไป แต่เส้นทาง (aka: ถูกส่งไปยังเกตเวย์ท้องถิ่นของคุณ: 192.168.0.1)
ในการวินิจฉัยปัญหานี้สามารถตรวจสอบได้ง่ายด้วย:
- Linux: คำสั่งtracepath (es .: "tracepath -n your.ec2.ip.address")
- windows: คำสั่ง "tracert" (es .: "tracert -d your.ec2.ip.address")
จากผลลัพธ์ที่คุณสามารถตรวจสอบว่าขั้นตอนที่สองรายงานที่อยู่ PPTP หรือไม่
หากการรับส่งข้อมูลของคุณเดินทางไปในเส้นทางที่ไม่ถูกต้องการแก้ไขเส้นทางที่ง่ายดายภายใน VPN คือ:
- Linux: "เส้นทางเพิ่ม -host your.ec2.ip.address gw the.remote.pptp.address"
- Windows: "เส้นทางเพิ่ม your.ec2.ip.address mask 255.255.255.255 the.remote.pptp.address"
หลังจากกำหนดค่าเส้นทางข้างต้นคุณสามารถตรวจสอบเส้นทางอีกครั้งด้วย tracert / tracepath
เมื่อการกำหนดเส้นทางถูกกำหนดค่าอย่างเหมาะสมมีความเป็นไปได้น้อยที่ปัญหาอาจเกิดขึ้นภายในสำนักงานของคุณ: หากเซิร์ฟเวอร์ PPTP ของคุณไม่ทำการส่งต่อ IP และการแปล NAT มีความน่าจะเป็นสูงที่คุณจะพบ "การกรอง" ในกรณีของ ip-forwarding หรือ "asymetric routing" ขาดหายไป (ในกรณีที่ NAT ขาดหายไป) ระหว่างโน้ตบุ๊กและ your.ec2.ip.address:
- ทราฟฟิกจากคุณไปที่อเมซอนเดินทางไปตาม VPN ไปยังสำนักงานของคุณและจากนั้นไปที่อเมซอน
- คืนการจราจรจากอเมซอนให้กับคุณ, ถูกส่งไปตามเส้นทางอินเทอร์เน็ตทั่วไปและ ... โอกาสสูงที่มันลดลงที่ไหนซักแห่ง
อีกครั้ง: tracepath / tracert สามารถช่วยคุณตรวจสอบปัญหาได้
บนกล่อง linux เพื่อนที่มีประโยชน์มากคนหนึ่งคือ "tcpdump" คำสั่ง tcpdump ที่มีประโยชน์คือ:
- "tcpdump -n -i อินเตอร์เฟส icmp" เพื่อตรวจสอบคำขอ / ตอบกลับ PING ขาเข้า / ขาออก;
- "tcpdump -n -i host an.ip.add.ress " เพื่อตรวจสอบปริมาณข้อมูลที่มา / ส่งไปยัง an.ip.add.ress