เก็บ SSH ภายในไว้เมื่อโฮสต์ใช้ VPN ขาออก

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

ขั้นตอนด้านล่างถือว่าผู้ดูแลระบบอยู่ใน LAN เดียวกันการดูแลระยะไกลเป็นปัญหาอีกข้อที่มีคำตอบอีกอย่าง

ผูก SSH กับที่อยู่ที่ผู้ดูแลระบบใช้

เริ่มจากตัวรับฟังss -ltnp | grep :22แสดงว่า sshd ผูกกับอะไร และตัวรับฟังบน 0.0.0.0 ยอมรับการเชื่อมต่อจากทุกอินเทอร์เฟซรวมถึงอุโมงค์ การผูกกับที่อยู่ LAN แคบกว่าและทำให้เจตนาเห็นได้ชัด:ListenAddress 192.168.10.20ในsshd_config ตามด้วยการทดสอบการกำหนดค่าและการโหลดใหม่ การพิมพ์ผิดในที่อยู่ดังกล่าวเห็นได้ชัดกว่าอักขระแทน เพราะ sshd ปฏิเสธที่จะเริ่มเมื่อที่อยู่ไม่มีอยู่

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

เก็บเส้นทาง LAN ไว้นอกอุโมงค์

โฮสต์ที่มีที่อยู่ใน 192.168.10.0/24 มีเส้นทางที่เชื่อมต่อสำหรับคำนำหน้านั้น และเส้นทางที่เฉพาะเจาะจงกว่าจะชนะเส้นทางเริ่มต้นของ VPN ภายในตารางเดียวกัน นี่คือเหตุผลที่ SSH ภายในมักทำงานต่อไปได้เองเมื่ออุโมงค์ขึ้น ตรวจสอบแทนการสันนิษฐาน:ip route get 192.168.10.50ระบุอินเทอร์เฟซและที่อยู่ต้นทางที่เคอร์เนลจะใช้ และคำตอบควรเป็นอุปกรณ์ LAN ไม่ใช่อุโมงค์ ทำการตรวจสอบซ้ำจากเครื่องของผู้ดูแลระบบด้วย เพราะตารางของเครื่องนั้นเป็นตัวตัดสินว่าแพ็กเก็ตจะมาถึงหรือไม่ โฮสต์สองเครื่องบนสายเดียวกันอาจไม่ตรงกันว่าทิศทางใดเข้าถึงได้

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

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

ทำให้ข้อยกเว้นไฟร์วอลล์แคบเท่ากับกฎ

ถ้าโฮสต์รันไฟร์วอลล์ อนุญาต SSH จากต้นทางการจัดการเท่านั้น และเฉพาะบนอินเทอร์เฟซ LAN กฎที่อนุญาตพอร์ต 22 จากทุกที่กว้างกว่าความต้องการและยากที่จะปกป้องในการตรวจสอบ บนโฮสต์ nftables กฎอยู่ในเชนอินพุตโดยจับคู่อินเทอร์เฟซและต้นทาง บนโฮสต์ iptables สิ่งที่เทียบเท่าคือคู่ของการจับคู่บน-iและ-s ให้ความเห็นในกฎพร้อมกลุ่มผู้ดูแลระบบที่กฎนั้นให้บริการ เพื่อให้การตรวจสอบครั้งต่อไปไม่ต้องเดาว่าทำไมพอร์ต 22 จึงเปิดอยู่

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

ทดสอบทั้งสองสถานะ

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

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

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

เขียนเส้นทางการกู้คืนลงใน runbook

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

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