วิธีทำให้ AWS เริ่มอุโมงค์ Site-to-Site VPN
การกระทำตอนเริ่มและการกระทำตอนหมดเวลา DPD ตอบคำถามที่ต่างกัน ตั้งค่าตัวที่ทำให้ AWS เริ่ม แล้วตรวจที่อยู่ของ peer และเส้นทางของแอป
โดยค่าเริ่มต้น AWS Site-to-Site VPN จะรอให้ customer gateway เริ่มการเจรจา ค่าเริ่มต้นนั้นเป็นการตั้งค่า ไม่ใช่กฎหมาย และการตั้งค่านี้ชื่อ Startup action ก่อนจะเอื้อมไปหามัน จงแยกสองคำถามที่มักถูกปนกันเสมอ: ใครเป็นคนสร้างอุโมงค์ และแพ็กเก็ตที่คุณสนใจมีเส้นทางผ่านมันหรือไม่ มีเพียงข้อแรกที่อยู่ในตัวเลือกของอุโมงค์
แยกการกระทำตอนเริ่มออกจากการกระทำตอนหมดเวลา DPD
สองตัวเลือกต่ออุโมงค์ควบคุมสองเหตุการณ์ที่ต่างกัน และการตั้งค่าตัวหนึ่งไม่ได้บอกอะไรเกี่ยวกับอีกตัว
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
ถ้า AWS ต้องสร้างอุโมงค์ใหม่หรือที่เปลี่ยนแปลง ให้เลือก start. ถ้า AWS ต้องเริ่มการเจรจาใหม่หลังหมดเวลา DPD ด้วย ให้กำหนดค่า restart สำหรับเหตุการณ์นั้นแยกต่างหาก ไม่มีตัวเลือกใดเป็นนโยบายลองใหม่ของแอป และไม่มีตัวใดเป็นช่วงเวลาสลับคีย์: DPD ตรวจว่า peer ยังมีชีวิตอยู่ ส่วนการสลับคีย์จะแทนที่ security associations บนอุโมงค์ที่ทำงานอยู่
แอปที่หมดเวลาขณะที่อุโมงค์ยังรายงาน up มีปัญหาเส้นทางข้อมูล การย่นตัวจับเวลา DPD จะไม่แก้ไข และอาจเพิ่มความวุ่นวายที่คุณต้องอธิบายภายหลัง
ตรวจว่า AWS มีที่ให้ส่งการเจรจาไป
การเริ่มจากฝั่ง AWS ใช้ได้กับ IKEv2 เท่านั้น และ AWS ต้องมีที่อยู่สาธารณะของ customer gateway เพื่อรู้ว่าจะส่งข้อเสนอไปที่ใด กรณีที่เจ็บที่สุดคือทรัพยากร customer gateway ที่ยืนยันด้วยใบรับรองซึ่งสร้างขึ้นโดยไม่มีที่อยู่: เอกสารของ AWS อธิบายการสร้างทรัพยากร customer gateway ใหม่พร้อมที่อยู่ แล้วจึงแก้ไขการเชื่อมต่อ VPN ให้ชี้มาที่มัน
ใบรับรองพิสูจน์ว่า peer เป็นใคร มันไม่ได้บอก AWS ว่า peer อยู่ที่ใด และนั่นเป็นสองข้อกำหนดที่ต่างกัน จึงเป็นเหตุให้ทางแก้คือทรัพยากร customer gateway ใหม่ ไม่ใช่ใบรับรองใหม่ การเปลี่ยนใบรับรองทำให้ AWS เหลือปลายทางที่หายไปเหมือนเดิม
ถ้า customer gateway อยู่หลัง NATAWS ยังต้องมี responder identity ที่กำหนดค่าไว้, IDrเพื่อให้ตัวตนของ peer ตรงกับสิ่งที่อุปกรณ์คาดหวัง ยืนยันค่านั้นและเส้นทางไฟร์วอลล์ที่ยอมให้ทราฟฟิก IKE ผ่านก่อนจะโทษตัวเลือกที่คุณเพิ่งเปลี่ยน การเลือก start ไม่สามารถทำให้ peer ที่เข้าถึงไม่ได้หรือถูกระบุผิดยอมรับข้อเสนอได้
ใช้การเปลี่ยนแปลงกับอุโมงค์เดียวและคาดว่าจะมีการหยุดชะงัก
การเชื่อมต่อ VPN มีสองอุโมงค์ที่มีตัวเลือกอิสระ ดังนั้นยืนยันด้วยที่อยู่ภายนอกว่าคุณกำลังแก้ไขอันไหน AWS อนุญาตให้แก้ไขหนึ่งอุโมงค์ต่อครั้ง และการเชื่อมต่อผ่านอุโมงค์ที่เลือกอาจขาดหายได้หลายนาที
- เลือกการเชื่อมต่อ Site-to-Site VPN แล้วเปิด Modify VPN tunnel options
- เลือกอุโมงค์ตามที่อยู่ IP ภายนอกและยืนยันเวอร์ชัน IKE และทรัพยากร customer gateway
- ตั้งค่าการกระทำตอนเริ่มและ DPD ที่คุณต้องการจริง ๆ แล้วบันทึกในช่วงเวลาที่คุณควบคุมได้
- ยืนยันว่าอุโมงค์ที่แก้ไขสร้างสำเร็จ และตรวจอุโมงค์อีกอันและการกำหนดเส้นทางก่อนการเปลี่ยนแปลงครั้งถัดไป
มีพฤติกรรมหนึ่งที่ควรใส่ใจก่อนการบำรุงรักษา เมื่อเปิดการเริ่มจาก AWS ไว้จะไม่มีเวลาหมด: AWS ลองต่อไปจนอุโมงค์ขึ้น และเริ่มใหม่เมื่อ customer gateway ส่งข้อความ delete-SA ถ้าคุณปิด peer โดยเจตนา AWS จะยังคงเคาะอยู่ และบันทึกของ peer จะแสดงให้เห็น
ตรวจเส้นทางของแอป ไม่ใช่แค่สถานะของอุโมงค์
อุโมงค์ที่รายงาน up ไม่เหมือนกับคำขอที่ใช้งานได้ ฟังก์ชัน Lambda ที่ผูกกับ VPC ยังต้องมีเส้นทาง subnet ไปยังคำนำหน้าของลูกค้า กฎ security group และ network ACL ที่อนุญาตทราฟฟิก การแปลงชื่อที่คืนที่อยู่ถูกต้อง และ เส้นทางขากลับฝั่งลูกค้า.
ทดสอบสักครั้งด้วยคำขอจริงจากบริบทของแอป แล้วอ่าน flow logs หากล้มเหลว ทราฟฟิก keepalive เป็นตัวเลือกที่ชอบด้วยกฎหมายเมื่อการเริ่มจาก AWS ปิดอยู่และอุโมงค์ที่ว่างเปล่าต้องการแพ็กเก็ตเพื่อคงอยู่ แต่ควรเป็นการตัดสินใจด้านการติดตามที่คุณเรียกชื่อได้ ไม่ใช่ลูป ping ที่อธิบายไม่ได้ซึ่งยึดติดกับฟังก์ชัน
เลือกก่อนว่าใครสร้างอุโมงค์ แล้ววินิจฉัยความล้มเหลวที่เหลือในชั้นของมันเอง เอกสารของ AWS เกี่ยวกับการเริ่ม ครอบคลุมข้อกำหนดเรื่องที่อยู่ ตัวตน และการลองใหม่ได้ละเอียดกว่าคำใบ้ในคอนโซล