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

ตัวห่อบริการเชื่อมต่ออะไรจริง ๆ

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

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

application -> local listener -> TLS connection -> remote listener -> configured backend

อ่านห่วงโซ่นั้นจากการกำหนดค่า ไม่ใช่จากชื่อทางการตลาด ลูกศรแต่ละอันคือการกระโดดของเครือข่ายแยกกันหนึ่งครั้ง พร้อมที่อยู่และกฎการเข้าถึงของตัวเอง

หาว่าช่องทาง TLS สิ้นสุดที่ใด

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

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

ss -ltnp | grep -F 443
openssl s_client -connect svc.example.net:443 -servername svc.example.net </dev/null | openssl x509 -noout -subject -dates

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

VPN แบบกำหนดเส้นทางเพิ่มอะไรที่ตัวห่อไม่ได้ทำ

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

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

มีชุดค่าผสมที่ชอบด้วยกฎหมาย คือโปรโตคอล VPN ที่บรรทุกอยู่ภายในตัวห่อ TLS บนการจัดวาง TCP ที่รองรับอย่างจงใจ นั่นซ้อนสองชั้น และไม่ได้ทำให้ตัวห่อกับ VPN เป็นวัตถุชนิดเดียวกัน

เปรียบเทียบขอบเขตที่ล้มเหลว

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

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

curl -sv --resolve svc.example.net:443:203.0.113.10 https://svc.example.net/health 2>&1 | head -30

การปักชื่อไปยังที่อยู่ที่เลือกไว้แยกการแปลงชื่อออกจากการเข้าถึง และนี่มักเป็นวิธีที่เร็วที่สุดในการรู้ว่าสองอย่างนั้นเสียที่ไหน

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

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