Định tuyến lưu lượng giữa hai chi nhánh qua cổng VPN của Azure
Hai kết nối Site-to-Site trên một cổng VPN của Azure có thể chuyển lưu lượng giữa các chi nhánh, nhưng chỉ khi cả hai đầu học được tiền tố và có đường trở về trong LAN.
Hai chi nhánh có thể trao đổi lưu lượng qua một cổng VPN của Azure mà không cần bất kỳ đường hầm trực tiếp nào giữa chúng. Mỗi chi nhánh mở một kết nối Site-to-Site đến cùng cổng, và cổng chuyển các tiền tố đã học giữa hai kết nối. Điều làm nên hoạt động này không phải đường hầm thứ hai mà là việc trao đổi tuyến: chi nhánh A phải học tiền tố của chi nhánh B, và B phải học tiền tố của A. Hãy đi qua các kiểm tra dưới đây theo thứ tự và dừng ở kiểm tra đầu tiên thất bại, vì mọi bước sau đều phụ thuộc vào nó.
Điều kiện tiên quyết, trước khi cấu hình bất cứ thứ gì
Bốn điều kiện quyết định thiết kế này có thể hoạt động hay không. Cổng phải dựa trên tuyến và nằm trên SKU hỗ trợ BGP, cả hai kết nối phải bật BGP, không gian địa chỉ của các chi nhánh không được chồng lấn, và không bên nào được dựa vào NAT để che giấu tiền tố thật của mình.
Hãy lập kế hoạch ASN một cách có chủ đích. Giá trị mặc định được Azure ghi trong tài liệu là 65515, và mỗi bộ định tuyến chi nhánh cần ASN riêng tư của chính nó, không xung đột với cổng hay chi nhánh kia. Dùng lại giá trị mặc định mà không kiểm tra cấu hình cổng hiện có chính là cách một đường AS bị từ chối về sau.
Cũng hãy xác nhận rằng bạn không mong đợi hành vi peering của VNet. Cổng trao đổi tuyến giữa hai kết nối bạn đã cấu hình; nó không làm các peering tùy ý trở thành bắc cầu. Nếu một mạng thứ ba cần đến được cả hai chi nhánh, mạng đó cần kết nối riêng hoặc đường tuyến riêng, không phải giả định rằng cổng sẽ phân phát lưu lượng. Hãy ghi lại ranh giới đó trước cửa sổ thay đổi đầu tiên, vì đó là quyết định thiết kế mà mọi người quay lại khi một site được thêm vào sau này.
Cấu hình theo thứ tự này
Mỗi bước có một kết quả quan sát được, nên đừng đi tiếp cho đến khi nó xuất hiện.
- Bật BGP trên cổng mạng ảo và ghi lại ASN cùng địa chỉ peer của nó.
- Tạo một cổng mạng cục bộ cho mỗi chi nhánh với không gian địa chỉ thật của chi nhánh đó, ASN và địa chỉ peer BGP của nó.
- Tạo từng kết nối Site-to-Site và bật BGP trên chính kết nối đó.
- Cấu hình bộ định tuyến chi nhánh để peering với địa chỉ cổng do Azure gán, không phải với điểm cuối IKE công khai của cổng theo giả định.
Bước thứ tư là nơi hầu hết các nỗ lực bị mắc kẹt. Địa chỉ peer BGP mà Azure báo cáo là địa chỉ mà bộ định tuyến chi nhánh phải dùng làm hàng xóm, và nó không phải lúc nào cũng là địa chỉ mà mọi người mong đợi từ sơ đồ đường hầm.
Quảng bá chính tiền tố của chi nhánh, ví dụ 10.10.0.0/16 từ A và 10.20.0.0/16 từ B. Đừng quảng bá tuyến mặc định hay một tổng hợp rộng để che một mạng cụ thể bị thiếu; khoảng trống sẽ quay lại sau này như một lỗ đen im lặng.
Xác minh việc trao đổi tuyến ở cả hai đầu
Trạng thái kết nối không phải là kiểm tra. IPsec có thể hoạt động trên cả hai kết nối trong khi không có tiền tố nào đi qua giữa chúng. Hãy đọc các peer BGP của cổng và các tuyến đã học, sau đó xác nhận rằng tuyến về phía chi nhánh kia xuất hiện như một đường dùng được.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Một tiền tố có trong bảng BGP vẫn có thể thua quyết định chuyển tiếp trước một tuyến tĩnh hoặc một tiền tố cụ thể hơn. Hãy kiểm tra tuyến được chọn, không chỉ tuyến nhận được.
Theo đường trở về ở phía LAN
Đây là phần trông đúng trong Azure nhưng thất bại tại chỗ. Một máy chủ trong chi nhánh A chỉ gửi gói tin đến bộ định tuyến VPN của A nếu bộ định tuyến đó là cổng mặc định của nó, hoặc nếu máy chủ hay cổng của nó có tuyến cho tiền tố của B. Điều tương tự cũng phải đúng ở chiều ngược lại.
Nếu một switch lõi riêng là cổng mặc định của LAN, nó cần tuyến về phía chi nhánh kia trỏ đến bộ định tuyến VPN. Không có tuyến đó, yêu cầu đến nơi còn phản hồi đi ra theo đường internet, và người dùng thấy một kết nối mở ra rồi bị treo.
Đừng dùng nhóm bảo mật mạng trên subnet của cổng để sửa việc này. Subnet đó có những yêu cầu riêng và một NSG ở đó không phải là thứ thay thế được hỗ trợ cho chính sách phía chi nhánh. Việc lọc thuộc về tường lửa của các chi nhánh và chính các khối công việc, nơi chủ sở hữu có thể xem xét các quy tắc. Chuyển những quy tắc đó sang NSG của subnet cũng che chúng khỏi nhóm sẽ gỡ lỗi sự cố tiếp theo.
Cho phép hoạt động, rồi chứng minh bằng một bài kiểm tra bị từ chối
Một tuyến đã học không phải là sự cho phép. Hãy cho phép nguồn, đích và dịch vụ mà bạn thực sự cần đi qua tường lửa của các chi nhánh và chính sách điểm cuối, còn phần còn lại để bị từ chối.
Hãy kiểm tra từ một khối công việc bình thường ở chi nhánh A đến một dịch vụ thật ở chi nhánh B, xác nhận phản hồi, rồi thử một thao tác phải tiếp tục bị cấm. Lưu lượng do chính thiết bị VPN tạo ra có thể dùng địa chỉ nguồn khác và bỏ qua bước định tuyến LAN, nên một ping thành công từ bộ định tuyến chứng minh ít hơn vẻ ngoài của nó.
Kết thúc bằng việc ghi lại bốn sự thật: các tiền tố đã trao đổi, các ASN đang dùng, đường trở về LAN của mỗi bên và chính sách cho phép dịch vụ. Nếu thiếu một trong số đó, thiết lập sẽ hoạt động cho đến lần thay đổi đầu tiên, và sau đó không ai giải thích được tại sao.