ไคลเอนต์ OpenVPN หยุดเมื่อเซิร์ฟเวอร์ทำงานบนโฮสต์เดียวกัน

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

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

อ่านอาการย้อนกลับ

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

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

หนึ่งซ็อกเก็ตและหนึ่งอุปกรณ์ต่ออินสแตนซ์

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

lport 1195
nobind
dev tun1

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

nobind เป็นของฝั่งไคลเอนต์ เซิร์ฟเวอร์ยังต้องผูกและฟังอยู่ ดังนั้นอย่าคัดลอกบรรทัดนี้ไปยังคอนฟิกของเซิร์ฟเวอร์ และอย่าปิดการผูกบนไคลเอนต์ที่คู่ตรงข้ามกรองตามพอร์ตต้นทางแบบคงที่

เลือกเจ้าของหนึ่งรายสำหรับเส้นทางเริ่มต้น

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

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

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

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

ตรวจสอบด้วยตาราง ไม่ใช่บรรทัดสถานะ

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

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

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

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