ไคลเอนต์ Kerio VPN บน Linux: ห้าขั้นตอนตรวจสอบตามลำดับ

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

ยืนยันว่าบิลด์ตรงกับเครื่อง

เริ่มจากสิ่งที่ dpkg คิดว่าเครื่องคืออะไรและแพ็กเกจถูกสร้างมาเพื่ออะไร ในระบบ 64 บิตปกติ dpkg --print-architecture จะพิมพ์ amd64 และหน้าผู้จำหน่ายระบุแพ็กเกจ amd64 ไว้ข้างแพ็กเกจ Debian ปกติ อ่านสตริงรุ่นในชื่อไฟล์ที่คุณติดตั้งจริง แทนที่จะถือว่าทั้งสองตรงกัน

ไฟล์เก็บถาวรปี 2013 ที่สร้างสำหรับ i386 ไม่กลายเป็น 64 บิตเพียงเพราะคุณส่ง --force-architecture ตอนติดตั้ง การบังคับติดตั้งจะใส่ไบนารีต่างถิ่น ซ่อนความล้มเหลวของ dependency ไว้หลังตัวเรียกที่ยังเริ่มทำงานได้ และอาจทำให้เดมอนโหลดไลบรารีผิด หากรุ่นที่คุณมีเป็น 32 บิตเท่านั้น ให้รันในสภาพแวดล้อม 32 บิตหรือขอให้เจ้าของเกตเวย์สร้างบิลด์ใหม่

ตรวจสอบบรรทัด dependency ด้วย dpkg -s kerio-control-vpnclient | grep -i depends แสดงสิ่งที่แพ็กเกจคาดหวัง และข้อจำกัดรุ่นที่ไม่เป็นไปตามหรือไลบรารีรันไทม์ที่หายไปจะปรากฏที่นี่ ไม่ใช่ในบันทึกของไคลเอนต์

กำหนดค่าผ่านตัวช่วยสร้างของแพ็กเกจ

ตามการออกแบบ ไคลเอนต์ไม่มีรายการในลิ้นชักแอป ดังนั้นไอคอนที่หายไปไม่ได้บอกอะไรเกี่ยวกับความสำเร็จของการกำหนดค่า เปิดตัวช่วยสร้างอีกครั้งด้วย sudo dpkg-reconfigure kerio-control-vpnclient แล้วตอบคำถาม: ปลายทาง VPN ข้อมูลบัญชี และลายนิ้วมือของใบรับรองเซิร์ฟเวอร์

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

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

รู้จักไฟล์ที่ตัวช่วยสร้างเขียน

การกำหนดค่าอยู่ที่ /etc/kerio-kvc.conf และเก็บทั้งบัญชีและลายนิ้วมือที่ปักหมุดไว้ ถือเป็นวัสดุลับ sudo stat -c '%a %U %G' /etc/kerio-kvc.conf ไม่ควรแสดงว่าให้ทุกคนอ่านได้

หลังการแก้ไขด้วยมือที่ได้รับอนุญาต ให้โหลดเดมอนที่เป็นเจ้าของไฟล์ใหม่ แทนการรีสตาร์ตสแตกเครือข่าย: sudo /etc/init.d/kerio-kvc reload การโหลดใหม่จะอ่านการกำหนดค่าใหม่และทิ้งเซสชันปัจจุบัน ดังนั้นจึงไม่ใช่การไม่ทำอะไรกับการเชื่อมต่อที่ยังทำงานอยู่

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

แยกเซสชันที่ใช้งานอยู่ออกจากพฤติกรรมการบูต

สคริปต์บริการควบคุมการเชื่อมต่อปัจจุบัน: sudo /etc/init.d/kerio-kvc stop จบ tunneling ทันที และ start นำกลับมา ไม่มีคำสั่งใดกำหนดว่าจะเกิดอะไรในการบูตครั้งถัดไป และความต่างนั้นสำคัญบนเครื่องที่บริหารจากระยะไกล

ตรวจสอบว่าใครเป็นเจ้าของการเริ่มอัตโนมัติก่อนลบลิงก์หรือปิดบังสิ่งใด แพ็กเกจอาจติดตั้งสคริปต์ init ของตัวเอง สร้าง unit หรือทั้งสองอย่าง และการปิดชื่อผิดจะทำให้ไคลเอนต์กลับมาหลังรีบูต systemctl status kerio-kvc เทียบกับชื่อที่เอกสารแพ็กเกจใช้ แล้วปิดพาธที่กระบวนการบูตอ่านจริง

อย่าเปลี่ยน unit ของ OpenVPN เพียงเพราะการกำหนดค่าดูคล้ายกัน ไคลเอนต์นี้พูดโปรโตคอลของตัวเองกับเกตเวย์ Kerio ดังนั้น เดมอนอื่นที่ชี้ไปยังไฟล์เดียวกันจะยืนยันตัวตนไม่ได้ และความล้มเหลวที่เพิ่มขึ้นทำให้อ่านหลักฐานได้ยากขึ้น ไคลเอนต์ GFI สำหรับ Linux ยังถือการเชื่อมต่อ VPN ได้ครั้งละหนึ่งเท่านั้น ขีดจำกัดนั้นใช้กับไคลเอนต์ ไม่ใช่ความจุผู้ใช้ของเกตเวย์

อ่านบันทึก แล้วตรวจสอบทรัพยากร

ไฟล์สามไฟล์ใต้ /var/log/kerio-kvc เล่าเรื่องของเดมอน: init.log สำหรับเหตุการณ์วงจรชีวิต error.log สำหรับความล้มเหลวร้ายแรง และ debug.log สำหรับรายละเอียด อ่านข้อความที่สั้นที่สุดที่ตอบคำถามของคุณ และลบปลายทางและชื่อผู้ใช้ก่อนวางที่ใด ๆ init.log ถ้ามีช่องว่างรอบเวลาที่คุณรันตัวช่วยสร้าง แสดงว่าเดมอนไม่เคยรีสตาร์ต

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

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