GCP Classic VPN trong Terraform: làm tunnel dựa trên tuyến
Trong Classic VPN nhãn không quyết định hành vi. Dựa trên tuyến nghĩa là bộ chọn cục bộ 0.0.0.0/0, bộ chọn từ xa khớp và một tuyến tường minh.
Kế hoạch áp dụng sạch sẽ, tunnel khởi lên và bảng điều khiển gọi nó là dựa trên chính sách. Lưu lượng vẫn không đi qua, và việc tìm công tắc dựa trên tuyến trong tài nguyên Terraform không dẫn đến đâu vì không có trường như vậy. Trong Classic VPN, hành vi dựa trên tuyến không phải là chế độ bạn chọn. Đó là thứ bạn nhận được khi bộ chọn lưu lượng cục bộ là 0.0.0.0/0, bộ chọn từ xa liệt kê các mạng bạn thực sự muốn và một tuyến trỏ tới tunnel. Ba thứ, và nhãn đi theo.
Huyền thoại: trường chế độ tunnel
Nhãn trên bảng điều khiển phản ánh những gì API thấy trong các bộ chọn. Không có gì trong tài nguyên nói dựa trên tuyến, nên không có gì để đặt thành đúng.
Tìm trường đó tiêu tốn giờ đầu tiên của vấn đề, trong khi đọc các giá trị bộ chọn mất năm phút cuối.
Dựa trên tuyến ở đây nghĩa là gì
Google ghi nhận các tunnel dựa trên tuyến của Classic VPN là tunnel dựa trên chính sách có bộ chọn cục bộ là 0.0.0.0/0. Chỉ các dải từ xa được đặt tên, và phía cục bộ được coi như bất kỳ địa chỉ nào. Vì thế dấu hiệu trong cấu hình của bạn là một giá trị chứ không phải chế độ. Viết cả hai bộ chọn một cách tường minh và đọc chúng trong đầu ra của kế hoạch:
local_traffic_selector = ["0.0.0.0/0"]
remote_traffic_selector = ["10.20.0.0/16"]Tiền tố của đối tác trong đoạn đó chỉ là minh hoạ; hình dạng mới là phần quan trọng.
Tuyến là một đối tượng riêng
Đối tượng tunnel không cài đặt tuyến. Các gói có thể khớp với chính sách của tunnel mà vẫn không có nơi để đi, vì bảng định tuyến của VPC quyết định bước nhảy tiếp theo. Tuyến cần dải đích, mạng, tunnel làm bước nhảy tiếp theo và mức ưu tiên thắng mọi thứ rộng hơn. Nếu quên điều đó, bạn nhận được một tunnel báo đã thiết lập và một ping không bao giờ rời khỏi 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
}Tạo tuyến trong cùng mô-đun với tunnel, để hai thứ không tách rời khi xem xét.
Phản chiếu các bộ chọn ở phía đối tác
Thiết bị từ xa phải được cấu hình theo hình ảnh gương: dải cục bộ của nó là bộ chọn từ xa của bạn, và dải từ xa của nó phải bao phủ các mạng con GCP mà bạn dự định dùng. Nếu một trong hai phía thu hẹp, pha 2 thất bại dù pha 1 thành công. Đây là dạng phổ biến nhất của cấu hình trông đúng trong bảng điều khiển mà không mang lưu lượng.
In các bộ chọn của hai phía cạnh nhau trong lần xem xét thay đổi.
Tách địa chỉ tĩnh thành hai lần áp dụng
Tạo địa chỉ dành riêng và tunnel tham chiếu đến nó trong một lần áp dụng là nguồn bất ổn đã biết, vì địa chỉ phải tồn tại trước khi quy tắc chuyển tiếp có thể dùng nó. Trước tiên chỉ áp dụng tài nguyên địa chỉ, sau đó thêm cổng, quy tắc chuyển tiếp và tunnel rồi áp dụng lại. Terraform đọc địa chỉ hiện có từ trạng thái ở lần chạy thứ hai và dùng lại. Nếu bỏ qua bước đó, tunnel có thể nhận địa chỉ công cộng mới ở mỗi lần áp dụng, điều này phá vỡ cấu hình của đối tác mỗi lần.
Hai lần áp dụng bây giờ rẻ hơn một lần đổi đối tác ở mỗi bản phát hành.
Xác minh việc thương lượng, không phải nhãn
Sau khi áp dụng, kiểm tra ba sự thật riêng biệt: tunnel báo đã thiết lập, tuyến tồn tại với bước nhảy tiếp theo dự định, và đối tác báo cả pha 1 và pha 2 đều hoạt động.
Tunnel hoạt động mà pha 2 hỏng nghĩa là hai phía không thống nhất về các bộ chọn:
- Một phía liệt kê mạng con mà phía kia không liệt kê.
- Một phía dùng tập hợp mà phía kia đã thu hẹp.
- Tuyến tồn tại nhưng trỏ tới tunnel khác.
Classic VPN là một tunnel duy nhất với SLA thấp hơn HA VPN, và HA VPN dùng hai giao diện, hai tunnel và BGP với các loại tài nguyên khác nhau. Sao chép một ví dụ cổ điển vào cấu hình HA và mong các trường bộ chọn hành xử giống nhau là một lỗi riêng đáng tránh. Bản thân các trường của tunnel được ghi lại trong tài liệu tham chiếu google_compute_vpn_tunnel.