SSH ระยะไกลผ่าน VPN: สิ่งที่อุโมงค์ไม่ได้ทำ
VPN ทำให้เซิร์ฟเวอร์ SSH เข้าถึงได้และไม่ได้ทำอะไรมากกว่านั้น เงื่อนไขสามข้อตัดสินว่ามันเหมาะสมหรือไม่ และขั้นตอนที่ล้มเหลวบ่งชี้ว่าชั้นใดเป็นปัญหา
VPN มอบเส้นทางส่วนตัวให้เซิร์ฟเวอร์ SSH และตัดความจำเป็นของตัวรับฟังสาธารณะบนพอร์ต 22 มันไม่ได้พิสูจน์ตัวตนโฮสต์ ไม่ได้อนุญาตผู้ใช้ และไม่ได้ตัดสินว่าบัญชีใดล็อกอินได้ นั่นยังเป็นงานของ SSH การที่ VPN เป็นวิธีที่ถูกต้องในการเข้าถึงเซิร์ฟเวอร์หรือไม่ขึ้นกับเงื่อนไขสามข้อ และอุโมงค์เป็นเพียงหนึ่งในคำตอบที่เป็นไปได้
อุโมงค์เปลี่ยนอะไรและ SSH ยังตัดสินอะไร
อุโมงค์เปลี่ยนการเข้าถึงได้: ที่อยู่ใดเข้าถึงได้ และจากที่ใด มันไม่เปลี่ยนสิ่งที่เกิดขึ้นหลังการเชื่อมต่อ TCP เกิดขึ้น ซึ่งเซิร์ฟเวอร์แสดงคีย์โฮสต์และขอตัวตนผู้ใช้
แยกสองชั้นออกจากกันทั้งในหัวและในเอกสารของคุณ การล็อกอิน VPN พิสูจน์ว่าใครใช้เครือข่ายได้ มันไม่บอกอะไรเกี่ยวกับบัญชีที่มีอยู่บนเป้าหมาย และไม่ใช่การอนุญาตให้ล็อกอินทุกเครื่องที่เข้าถึงได้
โหมดความล้มเหลวก็แยกจากกัน และนั่นคือสิ่งที่ทำให้การแยกมีประโยชน์ระหว่างเหตุการณ์
สามเงื่อนไขที่กำหนดรูปแบบการเข้าถึง
ข้อแรก เซิร์ฟเวอร์ต้องเข้าถึงได้โดยคนนอกเครือข่ายของคุณหรือไม่ ถ้าไม่ เส้นทางส่วนตัวพร้อมบาสเตียนหรือเมชคือการออกแบบที่เล็กกว่า ข้อสอง กลุ่มผู้ใช้ปลายทางรันไคลเอนต์ VPN ได้จริงหรือไม่ รวมถึงผู้ที่อยู่ในอุปกรณ์ที่มีการจัดการและมีข้อจำกัด
ข้อสาม คุณต้องการควบคุมระดับบริการหรือระดับผู้ใช้ VPN ให้การเข้าถึงเครือข่าย SSH ให้การเข้าถึงบัญชี หากข้อกำหนดคือผู้รับเหมาเข้าถึงโฮสต์เดียวและไม่มีอะไรอื่น นั่นคือข้อกำหนดด้านการอนุญาต และอุโมงค์เพียงอย่างเดียวแสดงสิ่งนั้นไม่ได้
ตอบสามข้อนั้นแล้วรูปแบบจะเลือกเอง ถ้าข้ามไป คุณจะลงเอยด้วยการเปิด SSH สู่สาธารณะเพื่อเลี่ยงการติดตั้งไคลเอนต์
ยืนยันเส้นทางส่วนตัวก่อนโทษ SSH
เชื่อมต่อ VPN ที่อนุมัติแล้วและใช้ชื่อหรือที่อยู่ส่วนตัวที่บันทึกไว้ของเป้าหมาย จากนั้นตรวจสอบเส้นทางที่เลือก สิทธิ์ของเกตเวย์ และเส้นทางกลับไปยังไคลเอนต์ ชื่อที่แก้ไขได้ถูกต้องไม่ใช่หลักฐานว่าที่อยู่นั้นใช้เส้นทางอุโมงค์ที่ตั้งใจ เพราะคำนำหน้าเฉพาะที่ซ้อนทับกันอาจส่งคำขอไปที่อื่นโดยสิ้นเชิง ความแตกต่างนั้นควรค่าแก่การเขียนลงในคู่มือปฏิบัติงาน
หากการเชื่อมต่อไม่เกิดขึ้นเลย ยืนยันว่าเซิร์ฟเวอร์รับฟังบนอินเทอร์เฟซที่คุณคาดไว้ และไฟร์วอลล์ของโฮสต์อนุญาตต้นทางที่มันเห็นจริง NAT ของเกตเวย์สามารถเขียนต้นทางนั้นใหม่ได้ ดังนั้นรายการที่อนุญาตซึ่งเขียนไว้สำหรับที่อยู่ tunnel ของไคลเอนต์อาจไม่ตรงเลย
ความไม่ตรงกันนั้นคือความล้มเหลว SSH ที่พบบ่อยที่สุดซึ่งสร้างขึ้นเองผ่าน VPN
อ่านขั้นตอนที่ล้มเหลว ไม่ใช่ข้อผิดพลาดรวม
สามขั้นตอนให้ข้อความที่แตกต่างกันสามแบบ และมีเพียงแบบเดียวเท่านั้นที่เกี่ยวกับข้อมูลรับรอง
| Stage | What you see | What it points at |
|---|---|---|
| Before the connection | Timeout, no route | Tunnel, route or gateway permission |
| Connection refused | Immediate reset | Nothing listening, or a host firewall rejecting |
| Authentication | Permission denied after a prompt | User, key or server policy |
ใช้ข้อผิดพลาดที่แน่นอนและบันทึกของเซิร์ฟเวอร์เอง แทนการรีเซ็ตข้อมูลรับรองทั้ง VPN และ SSH พร้อมกัน การรีเซ็ตทั้งสองคือวิธีที่การวินิจฉัยห้านาทีกลายเป็นเหตุการณ์ด้านตัวตนสองวัน
เอาต์พุตแบบละเอียดแสดงว่าคุณไปถึงขั้นตอนใด:
ssh -vv [email protected]รักษาคีย์โฮสต์และการอนุญาตให้สมบูรณ์
ตรวจสอบคีย์โฮสต์ผ่านกระบวนการที่เชื่อถือได้ตามที่ตั้งใจ โดยเฉพาะหลังการเปลี่ยนเซิร์ฟเวอร์ คำเตือนคีย์เปลี่ยนที่ไม่คาดคิดคือข้อความที่คุณต้องไม่ละเลยเพียงเพราะ VPN เชื่อมต่อได้ เพราะอุโมงค์ส่วนตัวไม่ได้ทำให้ปลายทางเป็นเครื่องที่คุณคิดว่าเป็น ตรวจสอบลายนิ้วมือกับแหล่งที่คุณเชื่อถือโดยไม่ขึ้นกับการเชื่อมต่อ
ฝั่งเซิร์ฟเวอร์ ยืนยันว่าบัญชีได้รับอนุญาตและวิธีพิสูจน์ตัวตนที่คุณกำหนดคือวิธีที่ถูกเสนอ คีย์ที่มีอยู่แต่ถูกละเลยมักเป็นปัญหาสิทธิ์หรือการกำหนดค่า ไม่ใช่เครือข่าย
จำกัดการเข้าถึงบริการให้เฉพาะตัวตนที่จำเป็นและรักษาเส้นทางการกู้คืนที่ได้รับอนุญาตสำหรับการเปลี่ยนแปลงเครือข่าย