IP ทางออกของ VPN ไม่ใช่หลักฐานของอุโมงค์: สิ่งที่เซิร์ฟเวอร์เห็น

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

เซิร์ฟเวอร์เห็นหนึ่งที่อยู่ต่อการเชื่อมต่อ

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

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

ทดสอบว่าทางออกของคุณเป็นอย่างไร

ดูเส้นทางจากทั้งสองด้านก่อนเขียนกฎ มุมมองของไคลเอนต์ต่อทางออกของตนและมุมมองของเซิร์ฟเวอร์ต่อการเชื่อมต่อคือสองข้อเท็จจริงที่สำคัญ

curl -sS https://api.ipify.org; echo
ss -tn state established '( sport = :443 )' | head

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

มีเพียงหนึ่งในสองชุดทางออกที่ระบุในรายการได้

กรณีหนึ่งตรวจสอบได้ในขณะที่ร้องขอและอีกกรณีไม่ได้ ซึ่งให้การรับประกันที่ต่างกันมาก

curl -sS https://check.torproject.org/torbulkexitlist | wc -l

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

ใช้ที่อยู่เป็นข้อมูลนำเข้าของนโยบาย ไม่ใช่หลักฐาน

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

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