FortiClient ทันเนลเต็มรูปแบบ: เส้นทางเฉพาะซับเน็ตของสำนักงาน

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

ไคลเอนต์ติดตั้งอะไร และทำไม LAN ถึงหายไป

เริ่มด้วยการอ่านตารางแทนการอ่านหน้าจอไคลเอนต์ บน macOSnetstat -rnพิมพ์ตารางทั้งหมด และroute -n get defaultบอกชื่ออินเทอร์เฟซและเมตริกที่ชนะอยู่ในขณะนี้ บน Linux คู่นี้คือip route showและip route get 8.8.8.8ทั้งสองตอบคำถามเดียวว่า รายการใดจะพาแพ็กเก็ตที่ไม่ตรงกับอะไรที่เฉพาะเจาะจงกว่านี้

ชื่ออุปกรณ์ของทันเนลไม่ตายตัว โปรไฟล์ IKEv2 บน macOS มักแสดงutunพร้อมตัวเลข ไคลเอนต์SSL VPNแสดงppp0และ OpenVPN แสดงtun0เส้นทางเริ่มต้นสองเส้นอาจมีอยู่พร้อมกันด้วยเมตริกที่ต่างกัน และรายการของไคลเอนต์อาจเข้าควบคุมหลังการเชื่อมต่อใหม่เท่านั้น ไม่ใช่ในจังหวะที่มันปรากฏ นั่นคือเหตุผลที่การดัมพ์ตารางสองครั้งห่างกันห้านาทีอาจเล่าเรื่องต่างกัน

ทำไมเส้นทางเริ่มต้นของทันเนลต้องออกก่อน

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

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

ลำดับบน macOS และบน Linux

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

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

บน Linux ลำดับเดียวกันใช้เครื่องมืออีกตัว คือเกตเวย์ของ LAN สำหรับเส้นทางเริ่มต้นและอุปกรณ์ของทันเนลสำหรับคำนำหน้าของสำนักงาน คำสั่งrouteแบบเก่ายังรับไวยากรณ์เก่าได้ แต่ip routeคือรูปแบบที่ตรงกับเอกสารปัจจุบัน

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

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

คำนำหน้า ตัวแปลงชื่อ และ DMZ ที่ยังมืดอยู่

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

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

ไคลเอนต์ SSL บน Linux มีความล้มเหลวเฉพาะฟิลด์ที่ควรรู้ ทันเนลเชื่อมต่อได้ LAN ของสำนักงานตอบสนอง และช่วง DMZ หนึ่งช่วงยังมืดอยู่ ชิ้นที่ขาดคือเส้นทางสำหรับช่วงนั้นผ่านเกตเวย์ของทันเนล และเกตเวย์ต่างกันในแต่ละเครื่อง ที่อยู่ที่ฮาร์ดโค้ดไว้จึงเป็นวิธีที่แล็ปท็อปเครื่องต่อไปพัง จงหามันจากสถานะของไคลเอนต์และทำให้คำสั่งอธิบายตัวเองได้:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

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

หลังการเชื่อมต่อครั้งถัดไป และเมื่อใดควรหยุดทำสิ่งนี้ในเครื่อง

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

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

รายการตรวจสั้น ๆ อ่านตาราง ลบเส้นทางเริ่มต้นของทันเนล คืนเส้นทางเริ่มต้นของ LAN เพิ่มทุกคำนำหน้า แก้การแปลงชื่อแยกต่างหาก และคาดว่าเส้นทางจะกลับมาเมื่อเชื่อมต่อใหม่