ทำไมมีไคลเอนต์ VPN เพียงตัวเดียวเชื่อมต่อหลังเราเตอร์เดียวกัน

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

อ่านบันทึกของเกตเวย์ก่อนแตะไคลเอนต์

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

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

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

เราเตอร์ทำอะไรกับ GRE และ NAT-T

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

L2TP บน IPsec ทำงานต่างออกไปตามการออกแบบ: IKE ใช้ UDP 500 การทะลุ NAT ย้ายเพย์โหลดที่ป้องกันไปที่ UDP 4500 และการห่อหุ้มมีอยู่เพื่อให้ไคลเอนต์หลายตัวหลังที่อยู่เดียวเข้าถึงเกตเวย์เดียวกันได้ การออกแบบนั้นไม่ได้กันเกตเวย์หรือกล่องกลางจากการกำหนดเพดานเซสชันต่อที่อยู่ และจากโซฟาความล้มเหลวทั้งสองดูเหมือนกัน โปรโตคอลของ SoftEther เองก็มีปัญหาแบบเดียวกัน: เราเตอร์ที่ไม่มีการส่งผ่านที่ทำงานได้จะรับไคลเอนต์แรกจาก LAN และทิ้งตัวที่สอง ลองสวิตช์ ALG หรือการส่งผ่านของเราเตอร์ในทั้งสองตำแหน่ง เพราะตัวช่วยที่เขียนสำหรับไคลเอนต์รุ่นเก่าอาจทำให้แพ็กเก็ตที่ไคลเอนต์ปัจจุบันส่งมาเสียหาย

nc -vz 203.0.113.5 1723
sudo tcpdump -ni any proto gre

เพดานตัวตนที่ดูเหมือนเพดานการรับส่ง

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

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

sudo journalctl -u openvpn-server@server -n 60 --no-pager
cat /run/openvpn/server.status

จับคู่การซ่อมกับรายการในบันทึก

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

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

ตรวจสอบสองเซสชันที่ยังมีชีวิต

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

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