IP tĩnh trong Azure P2S VPN: vì sao địa chỉ của máy khách thay đổi

Mỗi máy khách Azure point-to-site nhận một địa chỉ từ nhóm khi xác thực và chỉ giữ nó trong suốt thời gian kết nối đó. Không có bảng đặt trước, không có ánh xạ theo người dùng và không có cài đặt cổng nào mang nghĩa «luôn cấp 172.16.0.10 cho người này». Chính cơ chế duy nhất ấy giải thích cả hai triệu chứng mà người ta gặp sau này: một quy tắc NSG không còn khớp với người dùng mà trước đây nó khớp, và một danh sách cho phép lặng lẽ nhận vào một máy mà không ai cố ý thêm. Thay quy tắc bằng một quy tắc IP thông minh hơn không sửa được cả hai, vì thứ mà quy tắc gọi tên được cấp lại theo một lịch trình bạn không kiểm soát.

Nhóm là dung lượng, không phải danh tính. Nó tồn tại để các đường hầm đồng thời có địa chỉ duy nhất, và nó tái sử dụng chúng ngay khi một lượt thuê kết thúc. Khi điều đó rõ ràng, câu hỏi hữu ích không còn là «làm sao ghim máy khách này» mà thành «tôi có thể viết quy tắc chống lại thứ gì mà cổng sẽ không tái sử dụng».

Cổng thực sự làm gì khi một máy khách kết nối

Cổng giữ nhóm địa chỉ máy khách đã cấu hình và đối xử với nó như một bảng thuê. Khi kết nối, nó lấy địa chỉ trống kế tiếp, trên thực tế là địa chỉ thấp nhất còn trống, và gán cho bộ điều hợp đường hầm cho đến khi máy khách ngắt kết nối hoặc lượt thuê hết hạn. Thứ tự quyết định, không phải danh tính: ai kết nối lại trước sau một quãng yên tĩnh sẽ nhận địa chỉ thấp nhất mà tình cờ đang trống vào lúc đó.

Kích thước nhóm che giấu hành vi. Một nhóm phòng thí nghiệm lớn hơn số người kiểm thử một hoặc hai địa chỉ có vẻ tất định, vì cùng chiếc máy tính xách tay ấy thường kết nối lại theo cùng thứ tự mỗi sáng. Thêm máy thứ ba, đổi kích thước nhóm, hoặc để một phiên vẫn kết nối qua giờ trưa, và mẫu hình vỡ. Địa chỉ chưa bao giờ ổn định; hàng đợi mới là thứ ổn định.

Bất kỳ thay đổi nào trong cấu hình point-to-site cũng đặt lại không gian thuê. Một kiểu xác thực khác, một nhóm đã đổi kích thước, một dải nhóm mới, hay một cổng bị phá và dựng lại — tất cả đều đưa máy khách trở lại một nhóm không còn khớp với địa chỉ cũ của họ. Không có gì trong thay đổi đó chạm vào NSG của bạn, nên sự cố trông như tự phát.

Bạn có thể thấy điều đó trong khoảng một phút. Kết nối, ghi lại địa chỉ đường hầm trong chi tiết kết nối của máy khách, ngắt kết nối, nối máy thứ hai, rồi nối lại máy thứ nhất. Địa chỉ nhận lại phụ thuộc vào thứ mà máy thứ hai đang giữ, và không cài đặt cổng thông tin nào khôi phục địa chỉ trước đó theo yêu cầu.

Một NSG dựa trên IP máy khách thực ra là quy tắc về thứ tự kết nối

Quy tắc mà người ta viết đầu tiên là cái hiển nhiên: một quy tắc vào trên NIC của máy ảo quản trị hoặc trên mạng con của nó, với địa chỉ nội bộ của máy khách VPN làm nguồn. Nó ngắn, nó qua bài kiểm tra ngay ngày được viết, và nó hỏng ngay khi nhóm có nhiều hơn một địa chỉ trống.

Từ đó phát sinh hai kiểu hỏng, và chỉ một kiểu trông như lỗi. Một người dùng hợp lệ bị từ chối vì người khác đang giữ địa chỉ mà quy tắc gọi tên vào lúc đó, và điều ấy đến dưới dạng một phiếu hỗ trợ khó chịu. Hoặc một người dùng không định trước được cho vào vì đã thừa hưởng một địa chỉ mà quy tắc còn tin, và điều ấy không đến dưới dạng gì cả cho đến khi có người kiểm toán quyền truy cập.

Vì quy tắc đi theo lượt thuê, chính sách hiệu lực đọc là «người đầu tiên kết nối được quyền truy cập quản trị». Đó là mô tả thứ tự kết nối khoác áo ý định, và không vệ sinh quy tắc nào biến nó thành biểu hiện của ý định.

Lượt thuê của máy khách và địa chỉ của cổng là hai đối tượng khác nhau

Phần lớn sự nhầm lẫn đến từ một từ. Cổng có một IP công khai tương đối ổn định; máy khách có địa chỉ riêng lấy từ nhóm và chúng không ổn định. Với một cổng VPN không dư thừa theo vùng, IP công khai được cấp động, nhưng nó sống qua lần đổi kích thước, lần đặt lại và bảo trì định kỳ — nó đổi khi chính cổng bị xoá và tạo lại. Các SKU cổng dư thừa theo vùng và theo vùng dùng IP công khai của SKU Standard, và việc cấp đó phải là tĩnh.

Chính sự ổn định ấy là thứ một đối tác tại chỗ cần trong cấu hình của họ, và nó không nói gì về việc nhận diện một máy khách riêng lẻ. Khi đối tác hỏi họ sẽ thấy địa chỉ nào, câu trả lời là IP công khai của cổng trong site-to-site, hoặc một dải NAT dùng chung — không bao giờ là lượt thuê đường hầm của một máy tính xách tay.

Nhóm theo nhóm người dùng cho bạn một dải đáng để viết quy tắc chống lại

Virtual WAN point-to-site hỗ trợ nhóm người dùng, và mỗi nhóm có thể được gán nhóm địa chỉ máy khách riêng. Tư cách thành viên do danh tính quyết định, nên dải mà máy khách rơi vào trở nên dự đoán được: vận hành ở một dải, nhà thầu ở dải khác, và dải là thứ mà một quy tắc tường lửa hoặc NSG có thể gọi tên mà không phải đoán.

Bộ quy tắc tạo thành có một hình dạng bạn có thể xem lại:

• một nhóm cho mỗi đối tượng, định cỡ theo đỉnh phiên đồng thời chứ không theo số người;
• tư cách thành viên nhóm được quản lý qua danh tính, không phải bằng cách sửa quy tắc mỗi lần có người tham gia;
• quy tắc NSG hoặc Azure Firewall viết theo dải của nhóm, không bao giờ theo từng lượt thuê riêng lẻ;
• một hub hoặc cổng riêng cho những đối tượng không bao giờ được chia sẻ một dải.

Đưa cả nhóm vào danh sách cho phép là trung thực nhưng thô: mọi máy khách đã kết nối trong dải đó nhận cùng một mức truy cập. Đó là một quyết định chính sách đáng nói to thay vì phát hiện trong một lần rà soát. Bất cứ thứ gì vẫn cần câu trả lời theo từng người thì thuộc về tài nguyên thông qua gán vai trò, không thuộc về bộ lọc gói.

Khi việc triển khai không thể chuyển sang Virtual WAN

Nhiều cổng vẫn là cổng VPN thường, và chuyển sang Virtual WAN không phải thay đổi nhỏ. Câu trả lời thực tế là chuyển quyết định theo từng người dùng khỏi bộ lọc gói sang thứ đã biết người dùng là ai.

Danh tính ở cấp tài nguyên là phiên bản rẻ nhất. Storage, SQL và Key Vault đều hỗ trợ xác thực Entra ID với gán vai trò theo người dùng hoặc theo nhóm, nên VPN chỉ cần chứng minh khả năng tiếp cận mạng. Một máy chủ nhảy có tài khoản định danh làm cùng việc đó cho công tác quản trị, vì máy chủ ghi nhận con người còn đường hầm chỉ chuyên chở gói tin. Đăng ký máy khách trong DNS và cho phép tên thay vì số sẽ nâng quy tắc lên một tầng. Danh tính ở tầng ứng dụng — chủ thể chứng chỉ, yêu cầu token, tư cách thành viên nhóm — hoạt động khi thứ được yêu cầu quyết định là ứng dụng, không phải mạng.

Với một đối tác khăng khăng đòi địa chỉ nguồn cố định, câu trả lời là site-to-site hoặc ExpressRoute với một tiền tố đối tác đã xác định. Họ cho phép tiền tố đối tác, địa chỉ xuất hiện ở phía họ thuộc về cổng và không đổi khi ai đó khởi động lại máy tính xách tay.

Kiểm tra nhóm trước khi sửa một danh sách cho phép khác

Hai thuộc tính của nhóm gây ra phần lớn hành vi mà người ta đổ lỗi cho máy khách. Một nhóm quá nhỏ tái sử dụng lượt thuê nhanh, nên địa chỉ trông như luôn di chuyển và bất kỳ quy tắc dựa trên địa chỉ nào cũng trông không đáng tin ngay từ thiết kế. Một nhóm chồng lấn với các dải tại chỗ hoặc với không gian địa chỉ của mạng ảo tạo ra sự mơ hồ định tuyến mà không quy tắc tường lửa nào sửa được.

Đặt ba thứ lên một trang trước khi chạm vào một quy tắc: nhóm point-to-site, không gian địa chỉ của mạng ảo và các dải tại chỗ. Chúng không được chồng lấn, và nhóm cần chỗ cho mỗi máy khách đồng thời cộng thêm biên cho việc kết nối lại.

Sau đó khép vòng theo thứ tự này:

• Kết nối từ hai máy theo cả hai thứ tự và so sánh địa chỉ; nếu chúng có thể hoán đổi, không quy tắc dựa trên địa chỉ nào là an toàn.
• Kiểm tra xem cổng có phải Virtual WAN không; nếu đúng, dùng nhóm theo nhóm thay vì quy tắc theo từng địa chỉ.
• Hỏi điều gì xảy ra khi một quy tắc khớp nhầm người; nếu câu trả lời là một sự cố truy cập, hãy chuyển kiểm soát sang danh tính.
• Ghi lại dải nào thuộc nhóm nào trong cùng kho lưu trữ với các định nghĩa NSG.
• Kiểm thử lại sau mỗi thay đổi về nhóm, xác thực hoặc cổng, vì những thay đổi đó viết lại ánh xạ mà không thông báo.