VPN บนคลาวด์ของคุณยังคงพึ่งพาผู้ให้บริการโฮสติ้ง

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

บัญชีคือระนาบควบคุมที่แท้จริง

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

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

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

เหตุการณ์โครงสร้างพื้นฐานที่คุณดูแลไม่ได้

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

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

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

ตรวจสอบว่าอะไรอยู่รอดหลังการสร้างใหม่

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

curl -s http://169.254.169.254/latest/meta-data/instance-id
curl -s http://169.254.169.254/latest/meta-data/public-ipv4
cloud-init status --long

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

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

ตัดสินใจว่าการโฮสต์เองเปลี่ยนอะไรจริง ๆ

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

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

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