GCP Cloud VPN: ตรวจสอบเกตเวย์ อุโมงค์ และไฟร์วอลล์ตามลำดับ

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

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

สามออบเจกต์ และมีเพียงตัวเดียวที่เข้ารหัส

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

อุโมงค์คือการจับคู่ระหว่างเกตเวย์นั้นกับคู่ มันพา รหัสลับที่ใช้ร่วมกัน และตัวเลือกทราฟฟิกที่สัญญาว่าจะปกป้อง ความล้มเหลวเงียบส่วนใหญ่เริ่มต้นที่ตัวเลือกเหล่านี้ อุโมงค์ที่ตัวเลือกภายในครอบคลุม 10.0.0.0/24 จะไม่ส่ง 10.0.1.0/24 ไม่ว่าสถานะจะดูแข็งแรงเพียงใด

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

ประเภทการกำหนดเส้นทางกำหนดว่าอะไรจะไปถึงตารางเส้นทาง

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

อุโมงค์แบบไดนามิกที่มีเส้นทางคงที่เขียนด้วยมืออยู่ข้าง ๆ จะสร้างตารางเส้นทางที่ว่างเปล่าทุกครั้งที่เซสชัน BGP แกว่ง

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

การปฏิเสธโดยนัยอยู่หลังอุโมงค์

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

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

gcloud compute firewall-rules create allow-from-dc \
  --network=vpn-vpc \
  --direction=INGRESS \
  --source-ranges=192.168.10.0/24 \
  --allow=tcp:22,tcp:5432,icmp

การทำงานเพียงทิศทางเดียวเป็นเบาะแสของไฟร์วอลล์

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

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

ตัวเลือก โควตา แล้วจึงเป็นการตรวจสอบสี่ข้อ

อุโมงค์ที่สร้างในคอนโซลบางครั้งส่งคืนตัวเลือกทราฟฟิกปลายทางว่างเปล่าจาก gcloud compute vpn-tunnels describe ในขณะที่เส้นทางที่สร้างขึ้นพาทราฟฟิกได้ถูกต้อง เปรียบเทียบสิ่งที่ API บันทึกกับช่วงที่คุณปกป้องจริงก่อนตัดสินใจว่าอุโมงค์ผิด การสร้างผ่าน API หรือ SDK ทำให้ตัวเลือกชัดเจน

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

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