GCP HA VPN: phiên BGP kẹt ở Waiting for peer, việc hoán đổi cặp địa chỉ
Phiên BGP của Cloud VPN kẹt ở Waiting for peer thường đã hoán đổi địa chỉ đường hầm và địa chỉ đối tác. Hãy kiểm tra cặp địa chỉ trước khi dựng lại bất cứ thứ gì.
Một phiên BGP không bao giờ đạt tới Established trên đường hầm Cloud VPN thường không phải là vấn đề định tuyến. Đó là vấn đề đấu dây: hai địa chỉ phải phản chiếu lẫn nhau đã được nhập theo thứ tự ngược, hoặc cặp của đường hầm thứ nhất bị dùng lại cho đường hầm thứ hai. Bản thân đường hầm có thể hoàn toàn khỏe mạnh trong khi phiên vẫn đứng ở Waiting for peer, vì IPsec và BGP là hai cuộc thương lượng riêng biệt giữa cùng hai điểm cuối. Hãy xác định cái nào trong hai cái bị hỏng trước khi dựng lại bất cứ thứ gì.
Một câu hỏi giải quyết phần lớn trường hợp: thiết bị đối tác có nhìn thấy địa chỉ của Cloud Router hay không?
Trạng thái đường hầm và trạng thái phiên là hai kiểm tra khác nhau
IKE và ESP đến trước. Nếu đường hầm chưa được thiết lập thì bên trong nó không có gì quan trọng và việc bàn về địa chỉ BGP là quá sớm. Hãy đọc trạng thái và trạng thái chi tiết của đường hầm, sau đó đọc trạng thái đối tác BGP của bộ định tuyến cho chính đường hầm đó.
Đường hầm đang lên trong khi đối tác BGP của nó xuống sẽ thu hẹp lỗi vào phiên: địa chỉ đối tác, ASN hoặc TCP 179 đi vào địa chỉ bên trong. Đường hầm lên, phiên lên và vẫn chưa có tuyến nào trong VPC là trường hợp thứ ba. Đổi địa chỉ không giúp ích ở đó, vì phiên đã hoạt động và tiền tố đơn giản là không được quảng bá hoặc không được ưu tiên. Tách ba trường hợp này ra chính là phần lớn công việc.
Mỗi đường hầm cần /30 riêng với cả hai đầu được điền
Mỗi đường hầm HA VPN nhận một /30 link-local từ 169.254.0.0/16, một địa chỉ trên giao diện Cloud Router và địa chỉ còn lại trên đối tác của bạn. Trường đối tác phải nêu đầu xa, không bao giờ là địa chỉ của chính bộ định tuyến.
Hai đường hầm nghĩa là hai giao diện trên Cloud Router, mỗi giao diện một /30 khác nhau. Dùng lại cặp của đường hầm 0 cho đường hầm 1 là lỗi trông gọn gàng trong bảng tóm tắt và chết trong gói OPEN.
| Tunnel | Router interface | Peer address | What a swap produces |
|---|---|---|---|
| tunnel 0 | 169.254.1.1/30 | 169.254.1.2 | OPEN sent to itself or to nothing; session waits |
| tunnel 1 | 169.254.1.5/30 | 169.254.1.6 | same failure on the second session |
| both | one pair reused | one address reused | one session up, the other never leaves waiting |
Đọc cặp địa chỉ từ tài nguyên của bộ định tuyến chứ không phải từ bản tóm tắt trên bảng điều khiển. Bản tóm tắt liệt kê địa chỉ đối tác trong một cột dễ đọc nhầm, và ipRange của giao diện cùng peerIpAddress của đối tác phải mô tả hai đầu đối diện của cùng một /30.
Việc hoán đổi thường xảy ra trong lúc dựng lại
Chính khi dựng lại đường hầm là lúc các cặp bị chéo nhau. Địa chỉ đối tác của đường hầm cũ bị sao chép vào trường giao diện của đường hầm mới, hoặc phiên mới bị trỏ vào đối tác của phiên trước. Dù thế nào thì Cloud Router cũng gửi gói OPEN tới một địa chỉ mà giờ đây là chính nó hoặc tới một địa chỉ không có đường hầm phía sau.
Ghi các cặp ra trước khi mở bảng điều khiển: tên đường hầm, giao diện, địa chỉ bộ định tuyến, địa chỉ đối tác, ASN của đối tác. Sau đó tạo cả hai đường hầm trong một lượt, để cái thứ hai không bị điền bằng phần thừa của cái thứ nhất.
Ba lý do khác khiến một phiên phải chờ
Thứ nhất là ASN của đối tác: mỗi bên phải được cấu hình bằng ASN của bên kia, và sự không khớp sẽ tới được đối tác nhưng không bao giờ thiết lập. Thứ hai là tường lửa của chính đối tác, phải cho phép TCP 179 trên giao diện đường hầm; một quy tắc IKE hay ESP không bao phủ điều đó. Thứ ba là đối tác trả lời từ một địa chỉ nguồn khác với địa chỉ được cấu hình làm láng giềng của nó.
Nhật ký của chính đối tác là căn cứ phân biệt. Nếu bản tóm tắt BGP của nó không liệt kê láng giềng nào cho địa chỉ đó thì gói không đến và cặp hay đường đi bị sai. Nếu láng giềng nằm ở Active hoặc Connect thì gói có đến nhưng tham số phiên không khớp.
Kiểm tra theo thứ tự gói tin đi
Làm việc từ trong ra ngoài: trạng thái đường hầm, rồi trạng thái đối tác BGP của bộ định tuyến, rồi bản tóm tắt BGP của đối tác, rồi các tuyến. Nếu hai mục đầu khỏe mạnh thì đừng sửa phía Cloud VPN nữa mà làm việc trên thiết bị đối tác. Nếu bộ định tuyến báo đối tác xuống và thiết bị của bạn không có láng giềng nào thì cặp địa chỉ sai hoặc cổng BGP bị lọc. Bắt gói trên giao diện đường hầm của đối tác sẽ giải quyết trong một cái nhìn, vì gói OPEN hoặc đến đó hoặc không bao giờ đến.
gcloud compute routers get-status ROUTER --region=REGION in trạng thái đối tác bên cạnh địa chỉ mà nó đang dùng, và đó chính là cặp bạn cần so sánh.
Khi phiên đã thiết lập, hãy xác nhận rằng tiền tố học được xuất hiện trong bảng tuyến của VPC và mỗi bên có một máy trả lời. Sau đó ghi các cặp cuối cùng bên cạnh tên đường hầm, để lần dựng lại sau bắt đầu từ một bảng đã kiểm chứng thay vì bản tóm tắt trên bảng điều khiển.