VPN แบบไซต์ทูไซต์ทำงานได้ทางเดียว: ข้อบกพร่องสองแบบที่ต่างกัน

ไซต์ A ไปถึง B ได้ แต่ B ไปไม่ถึง A และอุโมงค์ดูปกติทั้งสองทาง ก่อนจะแตะอุโมงค์ ให้ตัดสินว่าคุณมีข้อบกพร่องแบบไหนจริง ๆ การเชื่อมต่อใหม่ที่เริ่มที่ B แล้วถูกปฏิเสธ กับคำตอบสำหรับการเชื่อมต่อที่เริ่มที่ A ที่ไม่เคยมาถึง ทำให้เกิดข้อร้องเรียนคล้ายกันและการวินิจฉัยที่ต่างกันโดยสิ้นเชิง อย่างหนึ่งเป็นปัญหานโยบายหรือเส้นทางบนเส้นทาง อีกอย่างเป็นปัญหาทางกลับหรือสถานะของทราฟฟิกที่ได้รับอนุญาตอยู่แล้ว

ความต่างนี้เองเป็นตัวกำหนดว่าควรเรียกใช้คำสั่งใด

ข้อบกพร่องสองแบบที่ดูเหมือนกัน

ในกรณีแรกโฮสต์ของ B ส่ง SYN ไปยัง A และไม่มีอะไรกลับมา ในกรณีที่สองโฮสต์ของ A เปิดเซสชันได้สำเร็จและคำตอบหายไปในทางกลับ ผู้ใช้ทั้งสองบอกว่าลิงก์เป็นทางเดียว และทั้งคู่อธิบายแพ็กเก็ตที่หายไป ดังนั้นคำอธิบายเพียงอย่างเดียวแยกสองกรณีนี้ไม่ได้

ถามว่าฝั่งใดเริ่มความพยายามที่ล้มเหลว ข้อเท็จจริงข้อเดียวนี้ตัดสาเหตุที่เป็นไปได้ไปครึ่งหนึ่ง

จากนั้นตรวจสอบว่าการทดสอบใช้โฮสต์เดียวกันและบริการเดียวกันตลอดหรือไม่ ping จากฝั่งหนึ่งกับการเชื่อมต่อแชร์ไฟล์จากอีกฝั่งทดสอบสองสิ่งที่ต่างกัน และการวินิจฉัยจากเกตเวย์อาจเลือกที่อยู่ของอุโมงค์ที่ไม่มีทราฟฟิกผู้ใช้รายใดใช้เลย

กรณีแรก: ไม่มีเส้นทางกลับ

เซิร์ฟเวอร์ระยะไกลที่ตอบผ่านเกตเวย์เริ่มต้นอีกตัวอาจรับคำขอและกำหนดเส้นทางคำตอบไปที่อื่น แล้วไฟร์วอลล์ที่ติดตามสถานะจะทิ้งคำตอบที่ไม่สมดุลนั้น เพราะไม่ตรงกับโฟลว์ที่สร้างไว้ ซึ่งดูเหมือนทิศทางที่ไม่เคยทำงานเลย การแปลเพิ่มอีกรูปแบบหนึ่ง: ปลายทางเห็นต้นทางที่ถูกแปลแล้วและตอบกลับไปที่ต้นทางนั้น กฎที่เขียนไว้สำหรับที่อยู่เดิมจึงไม่ตรงเลย

ตรวจสอบที่อยู่ที่ปลายทางเห็นจริงหลังการแปล และเส้นทางกลับสำหรับที่อยู่นั้นแทนที่จะเป็นซับเน็ตเดิม

กรณีที่สอง: นโยบายไม่เคยอนุญาต

กรณีตรงกันข้ามง่ายกว่าและพบบ่อยกว่าที่คิด: สำนักงานหนึ่งควรใช้บริการส่วนกลางและไม่ควรเริ่มการเชื่อมต่อเข้าศูนย์กลางเลย ความไม่สมดุลนั้นเป็นการตัดสินใจเรื่องการเข้าถึงโดยเจตนา และอุโมงค์ทำงานตามที่ออกแบบไว้ อ่านนโยบายการเข้าถึงก่อนเปลี่ยนการตั้งค่าอุโมงค์ใด ๆ เอกสารระบุว่าตั้งใจให้ทิศทางใด ไม่ใช่การดักจับแพ็กเก็ต การดักจับแสดงได้เพียงว่าเกิดอะไรขึ้น ไม่ได้แสดงว่าอะไรได้รับอนุญาต

หากจำเป็นต้องเริ่มจากทั้งสองทิศทางจริง ๆ ให้เพิ่มสิทธิ์สำหรับบริการนั้นโดยเฉพาะผ่านชุดกฎที่แพลตฟอร์มรองรับ การทำให้ทุกซับเน็ตเชื่อถือกันเพื่อแก้แอปพลิเคชันเดียวเปลี่ยนข้อกำหนดแคบ ๆ ให้เป็นสิทธิ์กว้าง และการแลกเปลี่ยนนั้นแทบไม่มีการทบทวนภายหลัง

เปรียบเทียบก่อนและหลังบนโฮสต์เดียวกัน

ดูปลายทั้งสองของความพยายามเดียวกัน ไม่ใช่สองความพยายามแยกกัน ดักจับที่เกตเวย์ของโฮสต์ที่เริ่มและที่ปลายทาง แล้วเปรียบเทียบว่าอะไรเข้า อะไรออก และฝั่งไกลเห็นที่อยู่ใด

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

หากการดักจับที่ปลายทางแสดงคำขอพร้อมที่อยู่ต้นทางที่ไม่คาดคิด คำตอบอยู่ที่การแปลหรือการกำหนดเส้นทาง ไม่ใช่นโยบายความปลอดภัยของอุโมงค์ หากปลายทางไม่แสดงคำขอเลย แพ็กเก็ตไม่เคยผ่านเส้นทางที่ได้รับการป้องกัน

หลังการแก้ไข ให้ทำการทดสอบเดิมซ้ำจากโฮสต์เดิมและยืนยันว่าการเข้าถึงที่ไม่เกี่ยวข้องยังถูกปฏิเสธ สถานะอุโมงค์ “established” ไม่สนับสนุนข้อสรุปใดในสองข้อด้วยตัวเอง