ทำไมไคลเอนต์ Access Server จึงเข้าถึงไม่ได้จาก LAN

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

อ่านที่อยู่ต้นทางที่บริการมองเห็น

ฟิลด์เดียวนี้ตัดสินทุกอย่างที่เหลือ หากบริการภายในเห็นที่อยู่ของพูล Access Server กำลังเราเตอร์แทนที่จะซ่อนทราฟฟิกของไคลเอนต์ และทุกคำตอบต้องถูกเราเตอร์กลับไปยังพูล หากเห็นที่อยู่ส่วนตัวของเซิร์ฟเวอร์เองแทน เซิร์ฟเวอร์กำลังทำ masquerade และเส้นทางกลับทำงานอยู่แล้ว แต่ต้องแลกกับการสูญเสียอัตลักษณ์รายไคลเอนต์ในบันทึกและกฎการเข้าถึงของบริการ

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

ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25

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

อย่าสันนิษฐานว่ามีพูลเดียว เซิร์ฟเวอร์อาจมีช่วงแบบไดนามิกบวกกับการแมปแบบคงที่รายผู้ใช้ และที่อยู่คงที่อาจอยู่นอกคำนำหน้าแบบไดนามิกทั้งหมด หากคุณเราเตอร์เฉพาะช่วงที่จำได้ ผู้ใช้ที่มีที่อยู่คงที่จะยังเสียอยู่ และคนอื่นๆ จะรายงานว่าปัญหาได้รับการแก้ไขแล้ว

เพิ่มเส้นทางตรงจุดที่ตัดสินคำตอบ

เส้นทางเป็นของเกตเวย์ที่บริการภายในใช้อยู่แล้ว ไม่ใช่ของบริการ เว้นแต่บริการจะเราเตอร์ทราฟฟิกของตัวเอง ชี้เส้นทางไปยังที่อยู่ส่วนตัวที่เข้าถึงได้ของ Access Server ซึ่งเป็นค่าที่ต่างจากที่อยู่ของอุโมงค์ที่ไคลเอนต์ถืออยู่

ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25

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

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

การส่งต่อและตัวกรองต้องสอดคล้องกับเส้นทาง

การเราเตอร์เป็นเพียงครึ่งเดียวของเส้นทาง เซิร์ฟเวอร์ต้องได้รับอนุญาตให้ส่งต่อระหว่างอุโมงค์และอินเทอร์เฟซส่วนตัว ซึ่งบนลินุกซ์หมายถึง net.ipv4.ip_forward บวกกับเชนการส่งต่อที่อนุญาตคู่อินเทอร์เฟซ และบนโฮสต์ที่เสริมความแข็งแรงมักมีกฎชัดเจนแยกตามทิศทาง

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forward

การกรองตามสถานะอธิบายอาการที่พาคนไปผิดทาง คำตอบภายในโฟลว์ที่สร้างแล้วไม่ต้องใช้กฎขาเข้าใหม่ การเชื่อมต่อที่ค้างหลัง SYN-ACK จึงไม่ได้ถูกบล็อกด้วยกฎ accept ที่หายไป แต่ถูกทิ้งหรือถูกเราเตอร์ผิด รักษาความแตกต่างนี้ไว้ เพราะมันแยกการเปลี่ยนแปลงเส้นทางออกจากการเปลี่ยนแปลงไฟร์วอลล์

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

โหมดเราเตอร์หรือโหมดมาส์ก: เลือกอย่างตั้งใจ

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

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

ซับเน็ตที่อยู่หลังไคลเอนต์เป็นงานแยกต่างหาก

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

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

ตรวจสอบด้วยโฟลว์เดียวและการดักจับครั้งเดียว

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

tcpdump -ni any host 10.90.0.25 and port 443

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

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