คำตอบของ VPN จากไซต์ถึงไซต์ไม่ผ่านอุโมงค์
คำตอบที่ข้ามอุโมงค์ไปคือการตัดสินใจเส้นทางบนฝั่งไกล ตรวจสอบตารางโฮสต์ ตัวเลือก และ rp_filter แล้วเลือกเส้นทางหรือ NAT
ผมใช้เวลาเช้าทั้งเช้ากับอุโมงค์ที่ขึ้นมาอย่างเรียบร้อยและส่งทราฟฟิกได้เพียงทิศทางเดียว สาขาเข้าถึงไฟล์เซิร์ฟเวอร์ที่สำนักงานใหญ่ได้ แต่ทุกการเชื่อมต่อที่เปิดจากสำนักงานใหญ่เข้าสู่สาขาตายที่ SYN แรก SA ขึ้นแล้ว ตัวนับอุโมงค์เพิ่มขึ้น และการจับมือไม่เคยเป็นปัญหา คำตอบถูกกำหนดเส้นทางไปที่ที่อุโมงค์ไม่ครอบคลุม และการเลือกนั้นเป็นของฝั่งไกล VPN จากไซต์ถึงไซต์ส่งต่อเฉพาะแพ็กเก็ตที่โฮสต์ส่งให้เกตเวย์ และโฮสต์แต่ละเครื่องเลือกเองแยกกัน ในแต่ละทิศทาง จากตารางเส้นทางของตัวเอง
ทั้งสองทิศทางถูกกำหนดเส้นทางแยกกัน
IP ไม่จดจำทิศทางของบทสนทนา โฮสต์ที่ส่งแพ็กเก็ตแต่ละเครื่องทำการค้นหาคำนำหน้าที่ยาวที่สุดของตัวเอง เลือกฮอปถัดไปหนึ่งฮอป และลืมการตัดสินใจนั้น คำขอและคำตอบเป็นแพ็กเก็ตสองชิ้นที่ไม่เกี่ยวข้องกันซึ่งบังเอิญอยู่ในการเชื่อมต่อเดียวกัน และอุโมงค์เป็นฮอปหนึ่งที่ทั้งสองชิ้นอาจใช้หรือไม่ใช้ก็ได้ ไม่มีอะไรในการแลกเปลี่ยน IKE ที่สอนเซิร์ฟเวอร์ปลายทางว่าต้องไปถึงซับเน็ตของคุณอย่างไร การเจรจาเพียงตกลงว่าคำนำหน้าใดเข้ารหัสได้
ข้อตกลงนั้นคือประตูที่สอง บน strongSwan ตัวเลือกทราฟฟิกคือ leftsubnet และ rightsubnet และแพ็กเก็ตที่มีต้นทางหรือปลายทางอยู่นอกคู่ที่เจรจาไว้จะไม่ถูกเข้ารหัส ไม่ว่าตารางเส้นทางจะว่าอย่างไร คำนำหน้าที่ถูกกำหนดเส้นทางเข้าอุโมงค์แต่หายไปจากตัวเลือกคือความล้มเหลวทางเดียวแบบเงียบ เส้นทางดูถูกต้อง แพ็กเก็ตยังออกไปแบบไม่เข้ารหัสหรือถูกทิ้ง และมีเพียงบันทึกของ charon ที่บ่น
โฮสต์ปลายทางไม่รู้เรื่องอุโมงค์ของคุณเลย
ภายใน LAN ปลายทาง คำตอบคือแพ็กเก็ตธรรมดาที่จ่าหน้าถึงไคลเอนต์ของคุณ โฮสต์ปลายทางไม่เห็นส่วนหัว IPsec และไม่มีเหตุผลที่จะเลือกเกตเวย์ VPN ก่อน มันค้นหาคำนำหน้าของคุณ ไม่พบอะไรที่เฉพาะเจาะจงกว่าเส้นทางเริ่มต้นของตัวเอง จึงทำตามเส้นทางนั้น หากเส้นทางเริ่มต้นชี้ไปที่ไฟร์วอลล์หลัก ไฟร์วอลล์นั้นมีเส้นทางกลับเข้าอุโมงค์หรือไม่มี เมื่อไม่มี คุณจะได้รับการทิ้งแบบเงียบ, ICMP unreachable หรือคำตอบที่ออกทางอินเทอร์เฟซฝั่งอินเทอร์เน็ตแล้วตายไป
อินเทอร์เฟซที่สองก็พอจะทำให้สิ่งนี้พังได้ แม้มีเส้นทางอยู่ NAS ที่มีลิงก์จัดการบน VLAN อื่น เซิร์ฟเวอร์ที่มี uplink สำรอง กฎนโยบายที่ส่งช่วงต้นทางหนึ่งไปยังตารางที่สอง สิ่งใดสิ่งหนึ่งเหล่านี้สามารถดักจับคำตอบได้ บน Linux ip rule show และ ip route show table all แสดงกฎและตารางที่รายการเริ่มต้นซ่อนไว้
อ่านการตัดสินใจบนเครื่องที่ส่งคำตอบ
ถามเคอร์เนลก่อนจะเปลี่ยนอะไร และให้ที่อยู่ต้นทางแก่มัน เพราะกฎที่ขึ้นกับต้นทางเปลี่ยนคำตอบ
ip route get 10.10.5.10 from 10.20.30.15
ip rule show
ip route show table all
ss -tn state established "( sport = :445 )"ผลลัพธ์ระบุอินเทอร์เฟซขาออกและฮอปถัดไป หากอินเทอร์เฟซไม่ใช่ตัวที่หันไปทางเกตเวย์ VPN คุณพบข้อบกพร่องแล้ว และงานที่เหลือคือเลือกว่าเส้นทางควรอยู่ที่ใด ping จากเกตเวย์พิสูจน์ได้น้อยที่นี่ เพราะมันตอบด้วยที่อยู่ที่โฮสต์ปลายทางวางได้ ไม่ใช่ที่อยู่แล็ปท็อปของคุณ
บน Windows ตัวเทียบเคียงคือ Find-NetRoute -RemoteIPAddress 10.10.5.10 สำหรับการตัดสินใจ และ Get-NetRoute สำหรับตาราง เส้นทางที่เพิ่มด้วย New-NetRoute และมีเมตริกสูงกว่าเส้นทางเริ่มต้นจะแพ้อย่างเงียบ ดังนั้นอ่านคอลัมน์เมตริก ไม่ใช่รายการ จากนั้นยืนยันด้วยแพ็กเก็ต tcpdump -ni any "host 10.10.5.10 and tcp port 445" บนอินเทอร์เฟซ LAN ปลายทางแสดงคำขอ และตัวกรองเดียวกันทางฝั่งอุโมงค์แสดงว่ามีคำตอบกลับมาหรือไม่ เห็นคำขอแต่ไม่มีคำตอบหมายความว่าคำตอบถูกกำหนดเส้นทางไปที่อื่นหรือถูกทิ้ง คำตอบที่มาทางอินเทอร์เฟซผิดช่วยชี้ตัวการก่อนที่คุณจะแตะเส้นทาง
เมื่อเกตเวย์ของเซิร์ฟเวอร์ไม่ใช่จุดสิ้นสุดของ VPN
หลายไซต์วางไฟร์วอลล์ไว้ระหว่างเซิร์ฟเวอร์กับตัวรวมศูนย์ ไฟร์วอลล์นั้นส่งต่อคำตอบ จึงต้องมีเส้นทางสำหรับคำนำหน้าของไคลเอนต์คุณที่ชี้ไปยังเกตเวย์ VPN และนโยบายการส่งต่อทั้งสองทิศทาง อุปกรณ์ที่มีสถานะทำให้แย่ลง คำขอผ่านไฟร์วอลล์มาจากโฮสต์ LAN ที่มันอนุญาต คำตอบตอนนี้มาจากอีกทิศทาง และรายการติดตามการเชื่อมต่อไม่ตรงกันแล้ว แพ็กเก็ตจึงถูกทิ้งว่าไม่ถูกต้องแทนที่จะถูกปฏิเสธ นี่คือเหตุผลที่บันทึกนโยบายดูว่างเปล่าขณะทราฟฟิกหายไป
เกตเวย์มีตัวกรองที่สองของตัวเอง การกรองเส้นทางย้อนกลับของ Linux ทิ้งแพ็กเก็ตที่ต้นทางเข้าถึงไม่ได้ผ่านอินเทอร์เฟซที่มันเข้ามา และนั่นคือรูปร่างที่แน่นอนของเส้นทางกลับแบบอสมมาตรที่ชอบด้วยกฎหมาย คู่มือการส่งต่อของ strongSwan เรียก net.ipv4.ip_forward และ net.ipv4.conf.all.rp_filter ที่ผ่อนลงด้วยเหตุผลนั้นพอดี ค่าที่เข้มงวดเป็น 1 บนเกตเวย์ใดเกตเวย์หนึ่งจะทำลายเส้นทางที่ถูกต้องอย่างเงียบ และ nstat -az แสดงการทิ้งหากคุณรู้ว่าจะดูที่ไหน
| Symptom | Where the reply is most likely lost |
|---|---|
| Gateway ping works, LAN host silent | Source address the far host cannot place in its table |
| SYN arrives, no SYN-ACK, tunnel counters flat | No route to the client prefix on the far host or its gateway |
| Reply counted on the internet-facing interface | Default route or policy rule on the far host |
| Firewall reports invalid state | Asymmetric path through a stateful device |
| Worked until a link failed over | New path is asymmetric, or rp_filter now rejects it |
กำหนดเส้นทางหรือแปลงแล้วตรวจสอบทั้งสองทิศทาง
การแก้ไขทั้งสองไม่เท่ากัน การเพิ่มเส้นทางรักษาที่อยู่ของไคลเอนต์ไว้เหมือนเดิม กฎที่อิงต้นทาง บันทึกการตรวจสอบ และแอปที่บันทึกผู้เรียกจึงยังทำงานได้ ราคาที่ต้องจ่ายคือทุกฮอปที่ตัดสินใจต้องมีเส้นทาง นั่นคือที่ที่ผิดพลาดได้มากขึ้น การมาสเคอเรดบนเกตเวย์ปลายทาง บีบเส้นทางกลับให้เหลือฮอปเดียว เพราะคำตอบถูกจ่าหน้าถึงเกตเวย์เองแล้ว และซ่อนว่าไคลเอนต์ใดทำอะไร
iptables -t nat -A POSTROUTING -o eth1 -s 10.20.30.0/24 -j MASQUERADEเลือกอย่างตั้งใจ เมื่อไคลเอนต์ปรากฏเป็นที่อยู่ของเกตเวย์ ACL ที่อิงต้นทางก็แยกพวกเขาไม่ออกอีกต่อไป และ conntrack ต้องถือการแมปไว้เพื่อให้คำตอบถูกเขียนกลับเข้าอุโมงค์ หากตัวเลือกยังกันคำนำหน้าของไคลเอนต์ออก NAT ก็ไม่เปลี่ยนอะไร เพราะคำขอไม่เคยเข้าอุโมงค์
ก่อนจะบอกว่าแก้ไขแล้ว ให้ยืนยันสี่อย่างตามลำดับ เส้นทางบนโฮสต์ที่ส่งคำตอบ เส้นทางบนทุกฮอปที่ส่งต่อคำตอบ ตัวเลือกที่ครอบคลุมทั้งสองคำนำหน้า และการดักจับที่แสดงคำตอบเข้าสู่อุโมงค์ด้วยต้นทางที่คุณคาดไว้ จากนั้นทำการทดสอบซ้ำจากอีกไซต์ การที่ทิศทางหนึ่งผ่านคือการออกแบบที่เปิดครึ่งเดียว และทิศทางที่สองมักล้มเหลวด้วยเหตุผลที่ต่างจากสิ่งที่คุณเพิ่งแก้ไข