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

ผลลัพธ์สองแบบเบื้องหลังรายการเมนูเดียว

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

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

แต่ละโหมดต้องมีอะไรก่อนจึงจะทำงานได้

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

ModeWhat must existWhat still has to be true
Tunnel deviceCompatible TUN/TAP arrangement on both ends, permission, addressingA route policy that actually sends the intended prefixes into it
Forwarding onlyA chosen SOCKS, local-forward or remote-forward listenerA permitted destination path on the far side

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

อินเทอร์เฟซจำลองไม่ใช่อุโมงค์

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

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

nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"

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

เตรียมฝั่งระยะไกลแทนการบังคับมัน

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

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

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

บริบทของการตรวจสอบสิทธิ์ และสิ่งที่ควรใส่ในตั๋ว

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

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

บทความที่เกี่ยวข้อง