Starlink Thay Đổi IP: Giải Pháp NATCloud

Tóm tắt Khi khách hàng Starlink khàn nài rằng “IP của tôi lại thay đổi,” vấn đề có thể nhìn thấy là luân phiên nhưng vấn đề sâu hơn là CGNAT. Mạng mặc định của Starlink đặt khách hàng đằng sau NAT được chia sẻ, vì vậy khả năng tiếp cập inbound IPv4 thực sự không có sẵn trừ khi bạn trả tiền cho bổ sung IP công khai. Các mẫu truy cập từ xa cổ điển — chuyển tiếp cổng, DDNS, danh sách IP được phép — bị giảm hoặc dừng hoạt động hoàn toàn. NATCloud giải quyết vấn đề này bằng cách thay thế sự phụ thuộc vào inbound bằng một đường hầm outbound được xác thực, khôi phục truy cập quản lý mà không cần IP công khai.

Tại sao Starlink liên tục thay đổi IP của tôi?

Khách hàng Starlink thấy những gì trông giống như luân phiên IP nhanh chóng vì dịch vụ mặc định đặt các thuê bao đằng sau CGNAT (NAT cấp Nhà mạng, RFC 6598 không gian địa chỉ dùng chung tại 100.64.0.0/10). Theo CGNAT, địa chỉ công khai hiển thị cho các dịch vụ bên ngoài được chia sẻ giữa nhiều thuê bao và có thể thay đổi khi tái phân bổ hồ pool egress mà không cần WAN của bộ định tuyến khách hàng thực sự được tái đánh số. Thêm vào khả năng động, khả năng phục hồi và quyết định mở rộng của Starlink, kết quả là một địa chỉ dường như trôi dạt trên khung thời gian ngắn hơn nhiều so với một WAN broadband điển hình.

Sự phân biệt này quan trọng vì nó thay đổi giải pháp. Nếu vấn đề duy nhất là “IP của tôi là động,” DDNS sẽ đủ — giữ tên máy chủ được ánh xạ tới IP hiện tại và bạn đã xong. Nhưng theo CGNAT, hoàn toàn không có IPv4 có thể định tuyến toàn cầu trên WAN khách hàng. DDNS phân giải tên máy chủ thành bất kỳ “IP của họ” nào mà khách hàng tưởng là của mình, nhưng các kết nối inbound tới địa chỉ đó hoặc thất bại hoàn toàn hoặc hạ cánh trên phiên của người khác. Không gian địa chỉ được chia sẻ phá vỡ giả định “một khách hàng, một IP công khai” mà bộ công cụ truy cập từ xa cổ điển phụ thuộc vào.

Tại sao điều này gây tổn hại truy cập hơn mọi người mong đợi

Truy cập từ xa truyền thống phụ thuộc vào một chuỗi mỏng manh: IPv4 công khai trên WAN, khả năng tiếp cập inbound thông qua ISP, quy tắc chuyển tiếp cổng trên bộ định tuyến khách hàng, lỗ hổng tường lửa cho một thiết bị cụ thể, và thường là mô hình tin cậy dựa trên IP phía đích. Chuỗi đó có những điểm yếu về bảo mật ngay cả trên một liên kết broadband bình thường. Trên Starlink CGNAT, nó trở thành không ổn định về mặt hoạt động.

Truy cập inbound biến thành một xổ số: đôi khi địa chỉ định tuyến quay lại thuê bao của bạn, đôi khi nó định tuyến tới một khách hàng khác trên cùng hồ pool egress, đôi khi xuất bản inbound không bao giờ tồn tại ở tất cả. Nhật ký, vị trí địa lý, giả định kiểm toán và danh sách IP được phép đều bị suy giảm. Điều này đặc biệt đau đớn đối với các kỹ thuật viên quản lý máy ảnh, bộ định tuyến, DVR, giao diện web và thiết bị chi nhánh không bao giờ được thiết kế cho các mô hình truy cập dựa trên danh tính — chúng giả định một IP công khai ổn định mà họ có thể liệt kê trắng.

Tại sao NATCloud phù hợp hơn với trường hợp Starlink

NATCloud không chỉ là một cách khác để tiếp cận một thiết bị từ internet — nó đảo ngược mô hình. Thay vì yêu cầu internet công khai tìm một thiết bị bằng IPv4 công khai hiện tại của nó, NATCloud giữ mối quan hệ được neo trong một đường hầm outbound được xác thực được thiết lập từ trang web khách hàng tới đám mây. Sự phụ thuộc thực tế chuyển từ “IP công khai hiện tại của tôi là gì?” thành “trang web có kết nối outbound không?” — và kết nối outbound hầu như luôn khả dụng trên Starlink, ngay cả khi xuất bản inbound không có.

Kiến trúc có một lợi ích bậc hai. Khi truy cập không còn phụ thuộc vào WAN IP được giữ nguyên, phần còn lại của mô hình hoạt động trở nên sạch hơn: giám sát, cảnh báo, báo cáo tính khả dụng, quyền dựa trên nhóm và hàng tồn kho trở thành một phần của cùng một mặt phẳng điều khiển thay vì được được phát minh xung quanh những thay đổi địa chỉ, ngoại lệ tường lửa ad-hoc và danh sách bảng tính. Quyền tập trung, hàng tồn kho tự động, báo cáo và hỗ trợ cho các tình huống CGNAT, NAT kép và NAT ba lần là các tính năng hạng nhất thay vì cách khắc phục.

Điều này có ý nghĩa gì đối với phần còn lại của kiến trúc

Thiết kế truy cập có trung tâm NATCloud định hình lại cách ba quyết định liền kề được đưa ra.

DDNS trở thành thứ cấp, không phải chính. DDNS rất hữu ích khi tồn tại một địa chỉ inbound thực sự và thay đổi đôi khi. Theo CGNAT, DDNS không thể tạo khả năng tiếp cập inbound chỉ bằng chính nó. Kiến trúc Starlink + NATCloud hoạt động mạnh hơn so với Starlink + DDNS đối với hầu hết các triển khai. DDNS vẫn có vai trò cho các trang web không phải CGNAT trong cùng một hạm đội, nhưng nó ngừng trở thành câu trả lời mặc định. Đối với cơ sở chỉ DDNS, hãy xem hướng dẫn Intelbras DDNS của chúng tôi và hướng dẫn quản lý MikroTik dựa trên VPS.

Bổ sung IPv4 công khai trở thành lựa chọn kinh doanh, không phải để khắc phục. Nếu khối lượng công việc cụ thể thực sự cần IPv4 inbound cổ điển và Starlink hỗ trợ IPv4 công khai trên kế hoạch đó, hãy thực hiện nó cho khối lượng công việc đó. Coi nó như một ngoại lệ cho một yêu cầu đã biết — không phải là kiến trúc cơ sở cho mỗi thiết bị. Hầu hết các thiết bị đó chỉ cần truy cập quản lý bảo mật, không phải xuất bản trên internet công khai.

IPv6 giúp nhưng không phải là cây đũa phép. Starlink hỗ trợ IPv6 với các cơ chế như SLAAC và tiền tố được ủy quyền. IPv6 có thể khôi phục khả năng tiếp cận từ đầu đến đầu khi tiền tố được ủy quyền và lọc đúng cách, nhưng nó vẫn yêu cầu chính sách tường lửa kỷ luật. Đối với nhiều đội hoạt động, NATCloud đơn giản hơn so với việc cải tổ mỗi quy trình làm việc xung quanh phơi bày IPv6 trực tiếp — đặc biệt khi hạm đội thiết bị bao gồm các thiết bị cũ hơn có hỗ trợ IPv6 yếu hoặc không có.

Tài liệu và tham khảo

Hai nền tảng kỹ thuật cơ bản làm nên trường hợp Starlink: RFC 1918 định nghĩa các phạm vi IPv4 riêng cho các mạng nội bộ, trong khi RFC 6598 dự trữ 100.64.0.0/10 làm không gian địa chỉ dùng chung được sử dụng bởi CGNAT. RFC 4862 bao gồm IPv6 SLAAC. Với nhau, những tài liệu này giải thích tại sao “internet hoạt động” không giống với “tôi có khả năng tiếp cập inbound công khai ổn định.”

Các tài liệu hỗ trợ của Starlink xác nhận rằng IPv4 công khai là một cấu hình tùy chọn được gắn với các kế hoạch dịch vụ nhất định, trong khi hành vi mặc định sử dụng CGNAT, và mạng là động với địa chỉ có thể thay đổi như một phần của các quyết định về sức chứa, khả năng phục hồi và mở rộng. Kết hợp hai sự kiện này — CGNAT theo mặc định cộng với địa chỉ động — là những gì làm cho các mẫu truy cập dựa trên IP inbound không đáng tin cậy.

Thực hiện bước tiếp theo

Nếu thiết kế truy cập của bạn vẫn phụ thuộc vào “IP công khai hiện tại của tôi,” Starlink sẽ tiếp tục cảm thấy không ổn định. Vấn đề sâu hơn không phải là cảm xúc, và thậm chí không hoàn toàn riêng biệt với Starlink — nó là về kiến trúc. Trong mô hình Starlink mặc định, tính ổn định IPv4 công khai và khả năng tiếp cập inbound không phải là những giả định an toàn. NATCloud giải quyết vấn đề này bằng cách loại bỏ sự phụ thuộc vào IP công khai khỏi đường dẫn quản lý và thay thế nó bằng một đường hầm outbound được kiểm soát hoạt động tốt hơn nhiều theo CGNAT và địa chỉ động.

Phản ứng tốt nhất đối với những thay đổi IP Starlink không phải là chiến đấu kịch liệt hơn cho cùng một phương pháp truy cập cũ. Nó là ngừng làm cho IPv4 công khai ổn định trở thành nền tảng của chiến lược truy cập của bạn.

Bắt đầu dùng thử miễn phí MKController