ทำไม nc -uz จึงพิสูจน์ไม่ได้ว่าเซิร์ฟเวอร์ OpenVPN พร้อมใช้งาน

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

สิ่งที่การตรวจ UDP สังเกตได้และสังเกตไม่ได้

nc -uz จะส่งดาตาแกรมแล้วจบ และสถานะที่คืนมาอธิบายการส่งในเครื่อง พอร์ตที่ปิดอาจตอบด้วย ICMP port unreachable แต่พฤติกรรมตามเอกสารของโหมดสแกนนี้ไม่ได้เปลี่ยนสิ่งนั้นเป็นความล้มเหลว และพอร์ตที่ถูกกรองจะไม่ให้คำตอบเลย ความเงียบและความสำเร็จจึงหมายถึงสิ่งเดียวกันสำหรับผู้เรียก

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

การปรับการตรวจให้ตรงกับทรานสปอร์ตที่กำหนดมาก่อนที่จะเชื่อถือผลลัพธ์ใด ๆ การติดตั้ง UDP ต้องใช้สัญญาณอื่น ไม่ใช่โปรโตคอลอื่น

ผู้เรียกสามราย คำถามสามข้อ

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

สิ่งเหล่านี้ไม่ใช่การตรวจเดียวกัน และการตรวจเดียวไม่อาจครอบทั้งสามอย่างได้อย่างซื่อสัตย์ เลือกผู้เรียกก่อน แล้วจึงเลือกหลักฐาน

สร้างการตรวจจากอินสแตนซ์ปัจจุบัน

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

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

ทำให้มันพังโดยเจตนาแล้วดูการตรวจ

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

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

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

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

บรรทัดสถานะควรบอกอะไร

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

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

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