GCP Classic VPN ใน Terraform: ทำให้อุโมงค์เป็นแบบอิงเส้นทาง

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

ความเชื่อผิด ๆ: ฟิลด์โหมดของอุโมงค์

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

การหาฟิลด์นั้นกินเวลาชั่วโมงแรกของปัญหา ขณะที่การอ่านค่าของตัวเลือกใช้เวลาห้านาทีสุดท้าย

แบบอิงเส้นทางในที่นี้หมายถึงอะไร

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

local_traffic_selector  = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]

คำนำหน้าของคู่ในตัวอย่างนั้นเป็นเพียงภาพประกอบ รูปแบบคือส่วนที่สำคัญ

เส้นทางเป็นออบเจ็กต์แยกต่างหาก

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

resource "google_compute_route" "office" {
  name                = "office-via-vpn"
  dest_range          = "10.20.0.0/16"
  network             = google_compute_network.vpc.name
  next_hop_vpn_tunnel = google_compute_vpn_tunnel.to_office.id
  priority            = 1000
}

สร้างเส้นทางในโมดูลเดียวกับอุโมงค์ เพื่อไม่ให้ทั้งสองแยกจากกันตอนตรวจทาน

สะท้อนตัวเลือกที่ฝั่งคู่

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

พิมพ์ตัวเลือกของทั้งสองฝั่งวางเคียงกันระหว่างการตรวจทานการเปลี่ยนแปลง

แยกที่อยู่แบบคงที่ออกเป็นการใช้งานสองครั้ง

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

การใช้งานสองครั้งตอนนี้ถูกกว่าการเปลี่ยนคู่ในทุกการออกรุ่น

ตรวจสอบการเจรจา ไม่ใช่ป้าย

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

อุโมงค์ทำงานแต่เฟส 2 ล้มลงหมายความว่าสองฝั่งไม่ตรงกันเรื่องตัวเลือก:

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

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