Một tiền tố được thêm vào đối tượng Azure sai tạo ra kết nối báo Connected mà không chuyển tiếp gì, và đây là loại lỗi đắt nhất trong ngăn xếp này. Có ba tài nguyên liên quan và chỉ một trong số đó sở hữu không gian địa chỉ từ xa: cổng mạng ảo, cổng mạng cục bộ mô tả phía xa và kết nối nối chúng. Tiền tố thuộc về cổng mạng cục bộ, kết nối phải được xây dựng lại để thay đổi có hiệu lực, và bản thân cổng thường được để nguyên. Thứ tự không thể thương lượng, và cổng thông tin chỉ hiển thị một phần của nó.

Ba đối tượng, một trong số đó giữ tiền tố

Không gian địa chỉ của mạng ảo trả lời một câu hỏi khác: cái gì sống bên trong Azure. Thêm một tiền tố từ xa ở đó không định tuyến lưu lượng đến đó, nó chỉ mở rộng không gian mà nền tảng cho là của mình, điều này có thể xung đột với dải từ xa thực tế. Cổng mạng cục bộ là đối tượng giữ các tiền tố từ xa, và kết nối tham chiếu cả hai cổng cùng một khóa được chia sẻ trước.

Còn một điều kiện thứ ba cần ghi nhớ. GatewaySubnet lưu trữ các phiên bản cổng được quản lý, phải mang chính xác tên đó, và với SKU không phải Basic, người ta kỳ vọng nó ít nhất là /27.

Không có gì khác thuộc về mạng con đó, và thay đổi tiền tố không có lý do để chạm vào nó. Một tiền tố thiếu trong cổng mạng cục bộ là không thể tiếp cận bất kể trạng thái kết nối nói gì, vì cổng chỉ cung cấp những tiền tố mà nó được thông báo khi thương lượng đường hầm. Đó là lý do triệu chứng không đối xứng: đường hầm đã lên, hiệp hội bảo mật ổn, và một mạng con không bao giờ xuất hiện trong bộ chọn lưu lượng. Nếu thiếu một dải từ xa trong khi các dải lân cận hoạt động, hãy ngừng nhìn vào đường hầm và đọc cổng mạng cục bộ.

Tại sao lại xóa kết nối

Đối tượng kết nối ghim cấu hình đã thương lượng trong suốt vòng đời của nó. Vì vậy quy trình được ghi lại sẽ xóa kết nối trước, cập nhật cổng mạng cục bộ, rồi tạo lại kết nối với cùng khóa chia sẻ. Các phiên bản cổng không được xây dựng lại cho thay đổi chỉ về tiền tố, điều này giới hạn gián đoạn ở việc tháo kết nối thay vì triển khai lại cổng.

Việc xóa đó chính là gián đoạn, nên hãy coi nó như một thay đổi được lên kế hoạch với thời điểm bắt đầu và kết thúc dự kiến thay vì một chỉnh sửa nhanh. Trong PowerShell, trình tự rất ngắn: Remove-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 -Force, sau đó Set-AzLocalNetworkGateway với -AddressPrefix mảng mới, sau đó New-AzVirtualNetworkGatewayConnection với -SharedKey cũ và cùng các cổng. Dùng lại khóa là quan trọng, vì phía xa không được cấu hình lại và khóa mới nghĩa là phải phối hợp với người sở hữu thiết bị từ xa. Nếu một nhóm khác vận hành thiết bị đó, hãy thống nhất khung thời gian với họ trước khi gỡ bỏ bất cứ thứ gì.

Khi nào phải xây dựng lại chính cổng

Câu trả lời thứ hai xoay quanh vấn đề này nói rằng phải tạo lại cổng và trao đổi khóa một lần nữa. Điều đó đúng cho một nhóm thao tác khác: thay đổi loại cổng hoặc SKU, chuyển giữa điểm-đến-trang và trang-đến-trang, hoặc sửa một cổng có cấu hình riêng bị sai. Những thay đổi đó thực sự thay đổi tài nguyên cổng, nên việc xây dựng lại thực sự cần thiết.

Cổng được tạo cho điểm-đến-trang không thể đơn giản nhận một kết nối trang-đến-trang. Phải xóa cấu hình điểm-đến-trang và tạo lại cổng, việc này cũng tạo ra khóa chia sẻ mới và gói máy khách mới.

Gói điểm-đến-trang xứng đáng có ghi chú riêng vì nó hết hạn. Cổng thông tin tạo ra một tệp có vòng đời ngắn, nên cách thực tế là tải xuống một lần và phân phối cùng với chứng chỉ máy khách thay vì gửi cho người dùng một liên kết cổng thông tin sẽ chết trước khi họ nhấp vào. Với câu hỏi về tiền tố, không điều nào trong số này áp dụng. Giữ hai quy trình tách biệt là toàn bộ kỷ luật: tiền tố là thay đổi ở cấp kết nối, và thuộc tính cổng là thay đổi ở cấp cổng.

Đọc trạng thái, không đọc huy hiệu cổng thông tin

Đọc trạng thái từ tài nguyên thay vì từ huy hiệu trong cổng thông tin. Get-AzVirtualNetworkGatewayConnection -Name Conn1 -ResourceGroupName RG1 trả về ConnectionStatus cùng với bộ đếm byte vào và ra, và chính các bộ đếm phân biệt một đường hầm đã kết nối mà không mang gì với một đường hầm chưa bao giờ được thiết lập.

Các bộ đếm ngừng tăng giữa một lần truyền chỉ vào đường đi chứ không phải xác thực. Các bộ đếm hoàn toàn không nhúc nhích chỉ vào tập tiền tố hoặc khóa chia sẻ.

Bộ hẹn giờ giải thích một nhóm ngắt kết nối bị quy sai cho VPN. Bộ cân bằng tải của Azure đóng các luồng nhàn rỗi sau thời gian chờ đã cấu hình, mặc định là bốn phút khi những ghi chú này được viết và có thể cấu hình tăng lên, nên một máy chủ OpenVPN trên VM không có keepalive có thể rớt mỗi vài phút trong khi mọi thứ khác trông khỏe mạnh. Một cổng mà nền tảng khởi động lại theo chu kỳ cũng có thể làm gián đoạn kết nối VNet tới một Web App, và lỗi đó nằm ở phía nền tảng chứ không phải trong cấu hình máy khách. Dấu hiệu là việc ngắt kết nối theo một khoảng cố định hay theo một thay đổi bạn đã làm.

Giữ ba đối tượng và giá trị của chúng trong một bản ghi: không gian địa chỉ của mạng ảo, danh sách tiền tố của cổng mạng cục bộ và tham chiếu đến khóa chia sẻ của kết nối. bài viết PowerShell về trang-đến-trang ghi lại các lệnh của cổng mạng cục bộ và thứ tự mà chúng thuộc về. So sánh một thay đổi tiền tố với trí nhớ là cách một đường hầm đang hoạt động bị xây dựng lại hai lần.

Sau đó xác minh theo thứ tự bạn đã thay đổi: cổng mạng cục bộ hiển thị danh sách tiền tố mới, kết nối trở lại Connected, và các bộ đếm nhúc nhích khi bạn gửi lưu lượng đến một máy chủ trong dải mới. Nếu bước thứ ba thất bại trong khi hai bước đầu qua, phía xa chưa chấp nhận bộ chọn lưu lượng mới và thiết bị từ xa cần mục giai đoạn 2 tương ứng. Đó là cuộc trò chuyện với đầu bên kia của đường hầm, không phải một thay đổi khác trong Azure.

Bài viết liên quan