OpenVPN push-peer-info: ติดป้ายไคลเอนต์โดยไม่ให้สิทธิ์เข้าถึง

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

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

ตั้งตัวแปรและเปิดใช้งานเส้นทาง

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

setenv UV_DEPLOY field-support
push-peer-info

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

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

อ่านฟิลด์จากฮุกของเซิร์ฟเวอร์

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

#!/bin/sh
# /etc/openvpn/server/hooks/label.sh
printf '%s %s\n' "$common_name" "${UV_DEPLOY:-unset}" \
  >> /var/log/openvpn/deploy-labels.log

อ่านตัวแปรผ่านสภาพแวดล้อมแทนการแยกวิเคราะห์บันทึก และให้ค่าเริ่มต้นเสมอ ${UV_DEPLOY:-unset} ทำให้สคริปต์ยังทำงานได้สำหรับไคลเอนต์ที่ไม่เคยส่งฟิลด์ ซึ่งเป็นสถานะปกติระหว่างการปรับใช้แบบค่อยเป็นค่อยไป อย่าเทสภาพแวดล้อมทั้งหมดลงในบันทึกเพื่อค้นหาชื่อ เพราะมันมีมากกว่าป้าย รวมถึงค่าที่คุณไม่ได้ตั้งใจจะเก็บ

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

ตรวจสอบว่าอะไรมาถึงจริง

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

tail -n 5 /var/log/openvpn/deploy-labels.log
# field-support deployed-client-07
# unset         legacy-laptop-02

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

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

ถือว่าป้ายเป็นการอ้าง ไม่ใช่ตัวตน

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

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

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

case "${UV_DEPLOY:-}" in
  field-support|field-qa|lab) : ;;
  *) UV_DEPLOY=unknown ;;
esac

ย้อนกลับอย่างสะอาด

การลบฟีเจอร์คือการลบสองครั้งและการตรวจสอบหนึ่งครั้ง ลบบรรทัด setenv และ push-peer-info ออกจากโปรไฟล์ไคลเอนต์ จากนั้นลบหรือปิดใช้งานฮุกและเป้าหมายบันทึกของมันบนเซิร์ฟเวอร์

grep -rn 'UV_DEPLOY\|push-peer-info' /etc/openvpn/
tail -n 3 /var/log/openvpn/deploy-labels.log

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

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