ทำไม VPN ที่ใช้งานได้ยังหมดเวลารอที่การตอบกลับ
การที่คำขอไปถึงเซิร์ฟเวอร์ส่วนตัวเป็นเพียงครึ่งเดียวของการแลกเปลี่ยน คำตอบของคำขอนั้นต้องหาไคลเอนต์อุโมงค์ผ่านเกตเวย์ เส้นทาง หรือการแปลงที่กำหนดไว้
คำขอมาถึง เซิร์ฟเวอร์บันทึกไว้ และไคลเอนต์ยังรายงานว่าหมดเวลา การรวมกันนี้หมายความว่า คำตอบไม่พบทางกลับและนี่เป็นหนึ่งในความล้มเหลวไม่กี่อย่างที่ยืนยันได้จากทั้งสองฝั่งพร้อมกัน ให้ตรวจตามลำดับและหยุดเมื่อข้อใดข้อหนึ่งล้มเหลว
เริ่มจากจุดที่คำขอมาถึง
ยืนยันว่าแพ็กเก็ตไปถึงบริการก่อนที่จะตรวจอย่างอื่น บันทึกฝั่งเซิร์ฟเวอร์ ตัวนับการเชื่อมต่อ หรือการดักจับที่ได้รับอนุญาตที่ปลายทางไกล ล้วนตอบคำถามเดียวกัน และการไม่มีสิ่งเหล่านี้จะส่งคุณกลับไปที่อุโมงค์แทนที่จะไปต่อที่คำตอบ นี่คือการตรวจที่แยกปัญหาการส่งต่อออกจากปัญหาทางกลับ
ถ้าคำขอไม่เคยมาถึง ให้หยุดตรงนี้ อุโมงค์ การกำหนดเส้นทางไปยังคำนำหน้าส่วนตัว หรือกฎการเข้าถึงคือหัวข้อ และทางของคำตอบยังไม่เกี่ยวข้อง บันทึกที่อยู่ต้นทางที่เซิร์ฟเวอร์เห็นด้วย ที่อยู่นั้นเป็นที่อยู่จากพูลที่ไคลเอนต์ได้รับหรือที่อยู่ที่แปลงแล้ว และความต่างนี้กำหนดว่าการตรวจใดต่อไปนี้ใช้
คำตอบต้องมีเส้นทางไปยังพูล
ไคลเอนต์เข้าถึงระยะไกลมักได้รับที่อยู่จากพูล และเครือข่ายส่วนตัวต้องมีเส้นทางกลับไปยังพูลนั้น เซิร์ฟเวอร์ที่เส้นทางเริ่มต้นชี้ไปยังเกตเวย์ของตัวเองจะส่งแพ็กเก็ตให้เกตเวย์นั้น ซึ่งไม่รู้ว่าพูลอยู่ที่ใด คำตอบจึงตายตรงนั้น ไคลเอนต์เห็นว่าหมดเวลาเพราะไม่มีอะไรกลับมา และแยกไม่ออกจากคำขอที่ไม่เคยออกไป
ตรวจเส้นทางที่เซิร์ฟเวอร์เลือกสำหรับที่อยู่ของไคลเอนต์ ไม่ใช่เส้นทางที่ใช้สำหรับซับเน็ตของตัวเอง การค้นหาสองครั้งนั้นอาจให้คำตอบต่างกัน และครั้งที่สองคือสิ่งที่สำคัญตรงนี้ การแปลงเป็นอีกแนวทางหนึ่งและเปลี่ยนสิ่งที่เซิร์ฟเวอร์เห็น มันทำให้ทางกลับง่ายขึ้นได้ และยังลบที่อยู่เดิมของไคลเอนต์ออกจากบันทึกของเซิร์ฟเวอร์ ซึ่งส่งผลต่อกฎหรือรายงานใด ๆ ที่สร้างบนฟิลด์นั้น
เปรียบเทียบการดักจับที่เซิร์ฟเวอร์กับการดักจับที่เกตเวย์
เปรียบเทียบสิ่งที่ออกจากเซิร์ฟเวอร์กับสิ่งที่มาถึงเกตเวย์ การดักจับบนอินเทอร์เฟซขาออกของเซิร์ฟเวอร์และการดักจับที่เกตเวย์ของอุโมงค์ตอบคำถามคนละครึ่ง และช่องว่างระหว่างทั้งสองบ่งชี้ตำแหน่งที่สูญหาย
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
คำขอที่เกตเวย์สร้างเองเป็นตัวแทนที่ไม่ดีสำหรับการทดสอบจากไคลเอนต์ เพราะมาจากที่อยู่อื่นและพบกฎอื่น ดังนั้น ping ที่สำเร็จจากเกตเวย์และคำขอที่ล้มเหลวจากไคลเอนต์จึงเป็นจริงพร้อมกันได้
เมื่อมีเราเตอร์หลายตัวบนเส้นทาง ให้ตรวจแต่ละตัวที่ต้องมีเส้นทางไปยังพูล การออกแบบไซต์ถึงไซต์มักต้องให้คำนำหน้าปลายทางไกลเป็นที่รู้จักบนอุปกรณ์มากกว่าหนึ่งเครื่อง และเกตเวย์เองต้องส่งต่อระหว่างอุโมงค์กับ LAN; บันทึกของ strongSwan เกี่ยวกับการส่งต่อ ครอบคลุมด้าน sysctl และไฟร์วอลล์ของเรื่องนั้น
บันทึกพูล คำนำหน้า และผู้รับผิดชอบ
ข้อเท็จจริงสี่อย่างควรอยู่ในบันทึก: พูลที่ไคลเอนต์ได้รับ คำนำหน้าส่วนตัวที่ต้องใช้ เราเตอร์ที่รับผิดชอบคำตอบ และกฎการแปลงถ้ามี เมื่อมีสิ่งเหล่านี้ การเปลี่ยนเกตเวย์ในภายหลังจึงเป็นการเปรียบเทียบ ไม่ใช่การสอบสวน
จากนั้นทดสอบซ้ำด้วยไคลเอนต์ปกติและบัญชีแอปพลิเคชันจริง การขยายสิทธิ์ของแอปพลิเคชันไม่สามารถซ่อมทางกลับของแพ็กเก็ตได้ และการเปลี่ยนบัญชีระหว่างการวินิจฉัยนี้จะทำให้การเปรียบเทียบครั้งถัดไปสับสน หากการออกแบบพึ่งพาการแปลง ให้บันทึกไว้ตรงที่ที่มีการอ่านบันทึกของเซิร์ฟเวอร์ ผู้ที่เห็นที่อยู่ต้นทางที่ไม่คุ้นเคยในร่องรอยการตรวจสอบไม่ควรต้องค้นหาการจับคู่ใหม่จากตั๋ว