เมื่อ openfortivpn เชื่อมต่อ ใครควรเป็นเจ้าของเส้นทางและ DNS?

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

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

สี่ขั้นตอนที่ดูเหมือนการเชื่อมต่อเดียว

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

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

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

ใครแก้ไขตารางเส้นทาง

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

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

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

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

ใครเป็นเจ้าของ DNS และไฟล์รีโซลเวอร์

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

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

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

สิทธิพิเศษ ความพร้อม และการมอบหมาย

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

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

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