Vì sao VPN Point-to-Site của Azure không đổi IP công cộng của bạn

Tôi kết nối ứng dụng Azure VPN trên laptop Windows, mở một trang dội địa chỉ và thấy đúng địa chỉ công cộng mà router ở nhà đã cấp. Trong lúc đó, hộp nhảy tại 10.20.0.4 trả lời và một tên điểm cuối riêng được phân giải, nghĩa là đường hầm không hỏng. Cổng point-to-site đang làm đúng điều mà cấu hình mặc định của nó nói: mang các tiền tố riêng và để mọi thứ khác ở trên liên kết cục bộ. Có được một địa chỉ đầu ra thuộc sở hữu Azure là thay đổi thiết kế định tuyến, không phải sửa chữa.

Cổng quảng bá gì theo mặc định

Cổng đẩy các tuyến cho không gian địa chỉ của mạng ảo, cộng với các mạng ngang hàng nơi cho phép chuyển tiếp qua cổng và các tiền tố tại chỗ được học qua kết nối site-to-site hoặc BGP. Không có 0.0.0.0/0 trong tập đó. Hệ điều hành của bạn giữ tuyến mặc định trên Wi-Fi hoặc Ethernet, nên gói tin đến một API công cộng không bao giờ vào đường hầm.

Địa chỉ mà ứng dụng khách nhận được bên trong đường hầm là một thuê bao riêng từ nhóm point-to-site. Nó nhận diện ứng dụng khách với các tài nguyên trong VNet; đây không phải địa chỉ mà internet có thể thấy, và nó sẽ không bao giờ xuất hiện làm nguồn của một yêu cầu đi ra đến API SaaS. Một mục trong danh sách cho phép dựng quanh thuê bao đó không thể hoạt động, dù bạn chờ bao lâu để nó xuất hiện trong nhật ký của nhà cung cấp.

Đường hầm chia tách và ép đường hầm song song

Chỉ hàng thứ hai thay đổi địa chỉ mà một dịch vụ từ xa nhìn thấy. Mọi thứ khác trong bảng đó là chi phí và bề mặt vận hành mà bạn chấp nhận khi lối ra phải được kiểm tra hoặc chuyển dịch bên trong Azure. Nếu ai đó yêu cầu bạn làm IP công cộng thay đổi, họ đang yêu cầu toàn bộ cột bên phải, không phải một chỉnh sửa nhỏ ở ứng dụng khách.

Có một lựa chọn trung gian đáng nêu tên trước khi bạn xây lại bất cứ thứ gì. Một VM proxy hoặc cổng bên trong VNet cho bạn một địa chỉ nguồn được kiểm soát cho các ứng dụng có thể trỏ tới nó, mà không phải dời tuyến mặc định của ứng dụng khách. Cách đó giữ việc duyệt web bình thường ở cục bộ và vẫn thỏa mãn một đối tác chỉ cần một lần gọi API đến từ Azure. Nó thất bại khi yêu cầu thực sự là về toàn bộ lưu lượng, vì bất cứ thứ gì bỏ qua thiết lập proxy vẫn đi ra cục bộ.

Buộc đường hầm mang tuyến mặc định

Trên một cổng mạng ảo, cách được hỗ trợ để đưa toàn bộ lưu lượng internet của ứng dụng khách vào đường hầm là thêm các tuyến tùy chỉnh vào cấu hình point-to-site. Hai nửa bao phủ toàn bộ không gian IPv4, và mỗi nửa cụ thể hơn tuyến mặc định cục bộ, nên ứng dụng khách thích chúng mà không xóa gì:

Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1

Dòng đó chỉ là ví dụ, không đầy đủ để sao chép: trước tiên lấy đối tượng cổng bằng Get-AzVirtualNetworkGateway và thay GWOBJ bằng nó, và xác nhận trước khi chạy rằng SKU và mô hình triển khai chấp nhận các tuyến tùy chỉnh. Cùng những tiền tố đó xuất hiện trong cổng thông tin ở trang cấu hình point-to-site, nơi an toàn hơn để đặt chúng nếu bạn chưa viết script cho cổng.

Thay đổi các tiền tố đó làm gói ứng dụng khách mất hiệu lực. Tải lại gói ứng dụng khách VPN và cài lại, vì các tuyến đi bên trong hồ sơ. Một ứng dụng khách kết nối lại bằng hồ sơ cũ sẽ giữ bộ tuyến cũ, và bạn có thể mất một giờ để gỡ lỗi một thay đổi chưa bao giờ đến được nó.

Trong một hub WAN ảo được bảo vệ, tương đương là một tuyến mặc định trong bảng tuyến của hub gắn với cổng point-to-site, còn lưu lượng do Azure Firewall trong hub đảm nhận. Tường lửa chuyển các kết nối hướng ra internet sang địa chỉ IP công cộng của chính nó, và chính từ phép chuyển đó mà địa chỉ đầu ra mới ra đời. Khi một tường lửa có nhiều IP công cộng, bất kỳ địa chỉ nào cũng có thể xuất hiện làm nguồn, nên danh sách cho phép phải chứa tất cả.

Cả hai thiết kế trên đều là IPv4. Hai tiền tố /1 không làm gì cho IPv6, và hỗ trợ IPv6 của point-to-site hẹp đến mức bạn nên kiểm tra tổ hợp trước khi hứa về sự tương đương.

Kiểm tra tuyến, rồi kiểm tra lối ra

Sau khi cài lại gói và kết nối lại, xác nhận rằng ứng dụng khách thực sự đã cài hai nửa. Trên Windows, Get-NetRoute -DestinationPrefix 0.0.0.0/1 và cùng truy vấn cho 128.0.0.0/1 phải nêu tên giao diện đường hầm, và route print hiển thị cả hai bên cạnh tuyến mặc định ban đầu của bạn. Trên Linux, ip route show phải liệt kê hai tiền tố; nếu không, hồ sơ chưa bao giờ mang chúng.

Sau đó kiểm tra lại địa chỉ công cộng từ ứng dụng khách và đọc nhật ký tường lửa cho cùng kết nối. Nguồn phải là IP công cộng của tường lửa với cổng đã chuyển. Một ứng dụng khách vẫn đi ra cục bộ trong khi cả hai tuyến tồn tại nghĩa là các gói đã đến Azure và ra bằng đường khác: một tuyến do người dùng định nghĩa trên mạng con của cổng, một tường lửa tự nó bị ép đường hầm về mạng tại chỗ, hoặc một chính sách loại bỏ luồng trước khi chuyển dịch.

Kiểm tra lại một đích riêng trong cùng phiên. Một máy nhảy ngừng trả lời sau thay đổi là dấu hiệu thường gặp rằng các tiền tố mới đã đẩy lùi thứ gì đó, hoặc một tuyến cục bộ hẹp hơn từng được quảng bá hoặc việc phân giải tên giờ đi đến một bộ phân giải không có bộ chuyển tiếp cho các vùng riêng của bạn.

Khi nào để yên đường hầm chia tách

Nếu mục tiêu chỉ là đến một API riêng, một điểm cuối riêng hoặc một trang quản trị nội bộ, hành vi mặc định rẻ hơn và yên tĩnh hơn. Ép đường hầm thêm giờ tường lửa và phí xử lý dữ liệu, một đường dài hơn và thêm một chỗ mà mọi luồng ứng dụng khách có thể thất bại. Nó cũng bắt được nhiều lưu lượng hơn hẳn so với một đích duy nhất mà bạn quan tâm.

Hãy dùng nó khi yêu cầu được phát biểu theo góc độ lối ra: một đối tác phải thấy một địa chỉ Azure cố định, bộ phận an ninh muốn các kết nối được ghi nhật ký và kiểm tra, hoặc dữ liệu phải ra qua một điểm được kiểm soát. Ngay cả khi đó, thiết kế cho mọi người dùng một lối ra chung, nên trách nhiệm theo từng người dùng phải đến từ danh tính trong ứng dụng chứ không phải từ địa chỉ nguồn.

Trước khi đóng thay đổi, xác nhận bốn điều: gói ứng dụng khách đã cài là bản mới, hai tuyến /1 nằm trên giao diện đường hầm, một đích riêng vẫn trả lời, và nhật ký của dịch vụ từ xa hiển thị địa chỉ tường lửa.