VPN บน Mac เชื่อมต่อได้ครั้งเดียวแล้วหมดเวลา: ล้างเดมอน IKE

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

บน macOS สิ่งนั้นมักเป็นเดมอน IKE

รูปแบบ: เชื่อมต่อครั้งเดียว แล้วหมดเวลา

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

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

สองเดมอน หนึ่งพอร์ต

ระบบเรียกใช้ racoon เมื่อการเชื่อมต่อพูด IKE เวอร์ชัน 1 รุ่นปัจจุบันยังนำเข้ามาซึ่ง iked สำหรับ IKEv2 และสแตก IPsec ที่ใหม่กว่า ทั้งคู่สามารถยึด UDP 500 และ UDP 4500 และทั้งคู่สามารถคงสมาคมความปลอดภัยแบบเปิดครึ่งหนึ่งไว้ได้หลังจากความพยายามเชื่อมต่อถูกยกเลิกที่พรอมป์รหัสผ่านหรือถูกขัดจังหวะจากการเปลี่ยนแปลงเครือข่าย

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

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

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

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

รีสตาร์ตงาน ไม่ใช่โปรเซส

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

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

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

จากนั้นเชื่อมต่อหนึ่งครั้งและอ่านบันทึกฝั่งไคลเอนต์ตั้งแต่ต้น การเจรจาที่ผ่านเฟส 1 แล้วรายงานความล้มเหลวในการส่งกำลังทำซ้ำปัญหาซ็อกเก็ตภายในเครื่อง; การเจรจาที่คู่ตรงข้ามปฏิเสธ เป็นตั๋วที่แตกต่างไปเลย

เมื่อเซิร์ฟเวอร์เป็นฝ่ายปฏิเสธ

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

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

อ่านบันทึกของคู่ตรงข้ามก่อนที่จะเปลี่ยนไคลเอนต์อีกครั้ง การปฏิเสธ ความไม่สอดคล้องของนโยบาย และการทิ้งอย่างเงียบ ๆ เป็นสามสาเหตุที่แตกต่างกันซึ่งบนหน้าจอ Mac ดูเหมือน “กำลังเชื่อมต่อ” ทั้งหมด

ไคลเอนต์รุ่นเก่าและเคอร์เนล 64 บิต

ไคลเอนต์ Cisco IPSec รุ่นเก่าโหลดส่วนขยายเคอร์เนลที่สร้างสำหรับระบบ 32 บิตและ PowerPC บน Mac ที่บูตเข้าสู่เคอร์เนล 64 บิต ส่วนขยายนั้นโหลดไม่ได้ และไคลเอนต์ล้มเหลวตั้งแต่เนิ่น ๆ ด้วยข้อผิดพลาด 51 เพราะไม่สามารถเข้าถึงระบบย่อย VPN ได้เลย ไม่ว่าจะรีสตาร์ตเดมอนกี่ครั้งก็ไม่ซ่อมส่วนขยายเคอร์เนลที่มีสถาปัตยกรรมผิด

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

• จำลองปัญหาหนึ่งครั้ง แล้วตรวจสอบว่าเดมอนใดเป็นเจ้าของ UDP 500 ก่อนแตะโปรไฟล์
• อ่านความล้มเหลวแรกหลังเฟส 1: ข้อผิดพลาดในการส่งชี้ไปที่ซ็อกเก็ตภายในเครื่อง
• รีสตาร์ตงานของ launchd ไม่ใช่แค่โปรเซส และยืนยันว่าพอร์ตว่าง
• ลองบัญชีที่สองเพื่อแยกหน้าต่างการยืนยันตัวตนซ้ำฝั่งเซิร์ฟเวอร์ออกจากความผิดพลาดของไคลเอนต์
• บันทึกสถาปัตยกรรมเคอร์เนลก่อนที่จะโทษไคลเอนต์

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