เตรียมเส้นทางกู้คืนทางอนุกรมก่อนเปลี่ยน VPN บน GCE

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

ขั้นตอนที่ 1: ยืนยันสิทธิ์ฝั่งคลาวด์

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

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

ขั้นตอนที่ 2: พิสูจน์ว่าคุณอ่านเอาต์พุตได้

การอ่านเอาต์พุตทางอนุกรมเป็นการตรวจสอบที่ถูกที่สุด และฝึกการรับส่งโดยไม่แตะการเข้าสู่ระบบของผู้เยี่ยมชม:

gcloud compute instances get-serial-port-output VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

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

ขั้นตอนที่ 3: พิสูจน์ว่าคุณได้รับการเข้าสู่ระบบแบบโต้ตอบได้

คำสั่งเชื่อมต่อเปิดเซสชันจริง ไม่ใช่ตัวอย่าง:

gcloud compute connect-to-serial-port VM_NAME \
    --project PROJECT_ID --zone ZONE --port 1

ปฏิบัติต่อมันเหมือนคอนโซลสด ยืนยันปลายทางก่อนพิมพ์ข้อมูลรับรอง เพราะทุกการกดแป้นจะไปถึงอินสแตนซ์

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

ขั้นตอนที่ 4: เตรียมข้อมูลรับรองที่ผู้เยี่ยมชมจะยอมรับ

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

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

เก็บข้อมูลรับรองการกู้คืนไว้เป็นส่วนตัว รหัสผ่าน root ที่วางไว้ในตัวอย่าง startup-script สาธารณะคือเหตุการณ์ที่สองที่รอเกิดขึ้น

ขั้นตอนที่ 5: บันทึกเจ้าของและการย้อนกลับ

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

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

ขั้นตอนที่ 6: ตรวจสอบหลังการเปลี่ยนแปลง

เซสชัน SSH ที่มีอยู่อาจรอดจากนโยบายที่บล็อกเซสชันใหม่ ดังนั้นทดสอบด้วยเซสชันผู้ดูแลระบบปกติใหม่ จากนั้นทดสอบพฤติกรรม VPN ที่คุณเปลี่ยนแยกต่างหาก

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