ทำไม route-nopull อย่างเดียวจึงทำให้เซิร์ฟเวอร์ไฟล์เข้าถึงไม่ได้
การเพิกเฉยต่อเส้นทางที่ถูกดันมาเป็นเพียงครึ่งเดียวของอุโมงค์แบบแยกส่วน เลือกเจ้าของตารางเส้นทาง เพิ่มคำนำหน้าเครือข่ายของออฟฟิศด้วยมือ และทดสอบสามเส้นทางก่อนจะบอกว่าแก้แล้ว
เซิร์ฟเวอร์ไฟล์เปิดได้ปกติ แล้ววิดีโอคอลในหน้าต่างถัดไปก็เริ่มกระตุก ไม่มีอะไรช้าและไม่มี MTU ใดผิด เพราะไคลเอนต์ของคุณรับรายการเส้นทางที่เซิร์ฟเวอร์ส่งมา ทุกแพ็กเก็ตจึงออกผ่านไฟร์วอลล์ของออฟฟิศตอนนี้ วิธีแก้ไม่ใช่แฟล็กปรับแต่งอีกตัว แต่เป็นการตัดสินใจว่าใครเป็นเจ้าของตารางเส้นทางของไคลเอนต์ การตัดสินใจนั้นควรอยู่ที่เดียว และโหมดความล้มเหลวด้านล่างจะบอกคุณว่าคุณเลือกที่ไหนจริง ๆ
ตัดสินใจว่าใครเป็นเจ้าของตารางเส้นทาง
เจ้าของเป็นไปได้สามแบบ เซิร์ฟเวอร์อาจดันเส้นทางและเกตเวย์เริ่มต้น ซึ่งในกรณีนั้นไคลเอนต์จะติดตั้งตามที่สั่งและกลายเป็นอุโมงค์เต็มรูปแบบ โปรไฟล์ไคลเอนต์อาจรับความเป็นเจ้าของด้วยการทิ้งการดันและถือบรรทัดเส้นทางของตัวเอง ตัวจัดการการเชื่อมต่อบนเดสก์ท็อปก็เป็นเจ้าของการตัดสินใจได้ผ่านพร็อพเพอร์ตีเส้นทางและเส้นทางเริ่มต้นของตัวเอง
แต่ละทางเลือกล้มเหลวต่างกัน จึงคุ้มที่จะอ่านตารางก่อนแก้ไขโปรไฟล์ แถวที่ตรงกับอาการของคุณคือเจ้าของที่คุณมีอยู่จริง
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
เลือกหนึ่งอย่างแล้วจดไว้ การผสมสองอย่างจะทิ้งโฮสต์ที่เส้นทางเริ่มต้นขัดกับเอกสารของตัวเอง และวิศวกรคนต่อไปบอกไม่ได้ว่าชั้นไหนชนะ ลบผู้แพ้อย่างชัดเจน
route-nopull กรองการดัน ไม่ได้เพิ่มเส้นทาง
route-nopull อยู่ในโปรไฟล์ไคลเอนต์ และลำดับของมันในไฟล์นั้นไม่สำคัญเพราะมันทิ้งเฉพาะค่าที่มาจากเซิร์ฟเวอร์ มันทิ้งเส้นทางที่ถูกดัน รวมถึงเส้นทางเริ่มต้นที่ถูกดัน ขณะที่อุโมงค์ยังขึ้นได้ตามปกติ
ผลที่คนมักมองข้ามคือตัวเลือก DHCP ที่ถูกดันหายไปด้วย การตั้งค่า DNS ที่เซิร์ฟเวอร์ส่งมาก็ถูกทิ้งเช่นกัน ชื่อภายในจึงหยุดแปลง แม้อุโมงค์จะแข็งแรงและเซิร์ฟเวอร์เข้าถึงได้ด้วยที่อยู่
นั่นทำให้เหลืออุโมงค์ที่ไม่มีเส้นทางไปยังคำนำหน้าของออฟฟิศ เว้นแต่คุณจะเพิ่มเอง: route-nopull ตามด้วย route 10.30.0.0 255.255.0.0 ในโปรไฟล์เดียวกัน บรรทัดนั้นพกที่อยู่และมาสก์ มันไม่ได้ระบุฮอปถัดไป
รูปแบบทางเลือกเพิ่มโทเค็นเกตเวย์ route 10.30.0.0 255.255.0.0 vpn_gateway ซึ่งชี้รายการไปยังอุโมงค์ตามชื่อ ตัวนำเข้ามีความแตกต่างกันว่าจะแปลรูปแบบนั้นหรือไม่ ดังนั้นตรวจสอบการเชื่อมต่อที่บันทึกไว้หากรายการหายไปจากตารางเคอร์เนล
ตรวจสอบด้วยการค้นหาเส้นทาง ไม่ใช่ ping
ping บอกคุณว่ามีอะไรตอบกลับ การค้นหาเส้นทางบอกว่าเคอร์เนลจะเลือกอินเทอร์เฟซใด และนั่นคือคำถามที่คุณถามจริง ๆ คำสั่งสั้นสี่คำแยกเส้นทางที่หายไปออกจากเส้นทางที่ชี้ไปยังอุปกรณ์ผิด
อ่านว่าอุโมงค์ติดตั้งอะไรด้วย ip route show dev tun0 ไม่มีเอาต์พุตเลยหมายถึงศูนย์เส้นทาง ซึ่งไม่ใช่อุโมงค์แยกส่วนที่ใช้งานได้ และเป็นผลลัพธ์ปกติของการเพิ่มตัวกรองโดยไม่มีบรรทัดที่ชัดเจน
จากนั้นตรวจสอบที่อยู่ออฟฟิศหนึ่งแห่งด้วย ip route get 10.30.5.7 และที่อยู่อินเทอร์เน็ตธรรมดาหนึ่งแห่งด้วย ip route get 1.1.1.1 ตัวที่สองควรระบุอินเทอร์เฟซทางกายภาพ ถ้ามันระบุอุโมงค์ แสดงว่าการดันไม่ได้ถูกกรองเลย
สุดท้ายอ่าน ip rule เพราะกฎนโยบายที่การพยายามครั้งก่อนทิ้งไว้อาจเอาชนะตารางที่คุณเพิ่งแก้ไข โปรไฟล์ที่ถูกต้องซึ่งมีกฎเก่าอยู่ด้านบนดูเหมือนโปรไฟล์ที่พังทุกประการ ลบกฎที่คุณเพิ่มครั้งก่อนก่อนจะเพิ่มอีกกฎ
ซับเน็ตที่ทับซ้อนดูเหมือนอุโมงค์ที่พัง
ช่วงส่วนตัวสองช่วงอาจเหมือนกันจากมุมมองของไคลเอนต์ และนั่นคือที่ที่อุโมงค์แยกส่วนถูกตำหนิในสิ่งที่มันไม่ได้ก่อ ถ้าออฟฟิศแจกคำนำหน้าเดียวกับที่เราเตอร์ที่บ้านของคุณใช้ เส้นทางอุโมงค์จะครอบเราเตอร์และเครือข่ายบ้านดูเหมือนหายไป
เปรียบเทียบที่อยู่บนอินเทอร์เฟซของคุณกับเส้นทางที่โปรไฟล์ติดตั้ง โดยใช้รายการที่อยู่ธรรมดาก่อนเปลี่ยนอะไร การทับซ้อนเป็นเรื่องจริง และไม่มีตัวเลือกโปรไฟล์ใดแก้ได้ สิ่งที่คุณแก้ได้คือการตั้งชื่อ เพื่อให้คนถัดไปเห็นสองช่วงแทนที่จะเป็นหนึ่ง
วิธีแก้ที่ซื่อตรงคือเปลี่ยนเลขฝั่งหนึ่งหรือแปลที่อยู่ในออฟฟิศ การปักหมุดเส้นทางโฮสต์เดียวไว้ที่เราเตอร์ใช้ได้จนกว่าที่อยู่เราเตอร์จะเปลี่ยน แล้วมันก็กลายเป็นปริศนาที่สองบนปริศนาแรก
ทำให้การตัดสินใจอยู่รอดหลังเชื่อมต่อใหม่
รายการที่พิมพ์ด้วยมือไม่อยู่รอดหลังเชื่อมต่อใหม่ และตัวจัดการการเชื่อมต่อจะสร้างตารางใหม่ทุกครั้งที่โปรไฟล์เริ่มทำงาน วางการตัดสินใจไว้ที่ที่การเชื่อมต่อถูกสร้าง ไม่ว่าจะเป็นโปรไฟล์หรือการตั้งค่าที่บันทึกไว้ของตัวจัดการ จากนั้นรีสตาร์ตการเชื่อมต่อหนึ่งครั้งโดยตั้งใจ แทนที่จะไปค้นพบพฤติกรรมระหว่างการโทร โปรไฟล์ที่ใช้ได้เพียงถึงการเชื่อมต่อใหม่ครั้งถัดไปยังไม่เสร็จ
ฝึกสามเส้นทางพร้อมกัน โฮสต์ออฟฟิศด้วยที่อยู่ตามตัวอักษร โฮสต์เดียวกันด้วยชื่อ และเว็บไซต์สาธารณะธรรมดา เส้นกลางขึ้นอยู่กับบริการชื่อที่คุณกำหนดค่าหลังจากทิ้งตัวเลือก DNS ที่ถูกดัน และมันคือเส้นที่ล้มเหลวอย่างเงียบ ๆ