Một số sự cố kết nối không phải do ứng dụng bạn đang sử dụng gây ra. Chúng đến từ đường dẫn mạng giữa các thiết bị.
Bạn có thể nhận thấy điều này khi một cuộc gọi kết nối ngay lập tức trên Wi-Fi tại nhà nhưng lại gặp khó khăn ở khách sạn Wi-Fi, khi phòng chờ trò chơi hoạt động với một người chơi nhưng không hoạt động với một người chơi khác hoặc khi một công cụ bảo mật hoạt động khác đi sau khi bạn chuyển từ dữ liệu di động sang mạng văn phòng. Một lý do phổ biến là NAT: lớp dịch địa chỉ mạng cho phép nhiều thiết bị chia sẻ một địa chỉ Internet công cộng.
Bài viết này giải thích quá trình truyền tải NAT là gì, tại sao việc đục lỗ UDP tồn tại, khi nào các dự phòng chuyển tiếp trở nên hữu ích và tại sao người đọc VPN Satelites nên coi những khái niệm này là bối cảnh kết nối thay vì những đảm bảo kỳ diệu.
NAT làm gì trong mạng hàng ngày
Hầu hết mọi người sử dụng mạng riêng mà không nghĩ đến chúng. Máy tính xách tay, điện thoại, máy tính bảng và TV của bạn đều có thể nằm sau một bộ định tuyến. Trong nhà, mỗi thiết bị đều có địa chỉ riêng. Đối với mạng internet rộng hơn, họ thường chia sẻ một địa chỉ công cộng.
Bản dịch đó thật hữu ích. Nó giúp các mạng bảo tồn các địa chỉ IPv4 công cộng và duy trì việc quản lý định tuyến thông thường tại nhà. Nhưng nó cũng tạo ra một vấn đề thực tế: một thiết bị bên ngoài mạng của bạn thường không thể mở kết nối trực tiếp đến một thiết bị bên trong mạng của bạn trừ khi bộ định tuyến biết lưu lượng truy cập đến sẽ đi đâu.
Đối với trình duyệt web thông thường, điều đó thường ổn. Thiết bị của bạn bắt đầu kết nối ra bên ngoài, bộ định tuyến ghi nhớ ánh xạ và các phản hồi sẽ quay trở lại thông qua đường dẫn tạm thời đó. Đối với các ứng dụng cần hai điểm cuối để giao tiếp trực tiếp hơn, đặc biệt là qua UDP, tình huống có thể khó dự đoán hơn.
Đó là cài đặt cơ bản cho quá trình truyền tải NAT.
Truyền tải NAT là gì?
Truyền tải NAT là tên chung cho các kỹ thuật giúp ứng dụng giao tiếp qua các mạng trong đó một hoặc cả hai điểm cuối nằm phía sau NAT.
Bằng tiếng Anh đơn giản, ứng dụng đang cố gắng trả lời một câu hỏi thực tế: “Hai thiết bị này có thể tìm thấy đường dẫn làm việc với nhau ngay cả khi bộ định tuyến của chúng đang dịch địa chỉ và lọc lưu lượng truy cập đến không?”
Không có câu trả lời chung duy nhất vì hành vi của NAT rất khác nhau. Các tiêu chuẩn như IETF RFC 4787 mô tả hoạt động của NAT dành cho UDP và giải thích tại sao tính nhất quán lại quan trọng đối với các ứng dụng thời gian thực như giao tiếp đa phương tiện và chơi game trực tuyến. Vấn đề rộng tương tự xuất hiện trong nhiều danh mục ứng dụng hiện đại: cuộc gọi, công cụ cộng tác, trò chơi, công cụ truy cập từ xa, hệ thống kiểu ngang hàng và các ứng dụng giống VPN đều có thể bị ảnh hưởng bởi cách mạng xử lý lưu lượng truy cập.
Đối với người đọc VPN Satelites, bài học hữu ích rất đơn giản: nếu một kết nối hoạt động khác nhau giữa các mạng, điều đó có thể phản ánh hành vi của bộ định tuyến, NAT cấp nhà cung cấp dịch vụ, chính sách tường lửa, lọc gói, tắc nghẽn hoặc các điều kiện đường dẫn khác. Nó sẽ không tự động được đọc làm bằng chứng cho thấy một cài đặt ứng dụng bị hỏng.
Đục lỗ UDP là gì?
UDP thường được sử dụng bởi các ứng dụng thời gian thực vì nó có thể tránh được một số độ trễ và chi phí liên quan đến lưu lượng hướng kết nối. Nhưng UDP không tạo ra phiên tồn tại lâu dài giống như cách nhiều người tưởng tượng về kết nối truyền thống.
Đục lỗ UDP là một kỹ thuật truyền tải NAT trong đó hai điểm cuối gửi các gói UDP đi để các thiết bị NAT của chúng tạo ánh xạ tạm thời. Nếu thời gian và hành vi của NAT thẳng hàng, lưu lượng truy cập từ phía bên kia có thể quay trở lại thông qua các ánh xạ đó.
Cụm từ này nghe có vẻ hung hãn nhưng khái niệm này lại bình thường hơn cái tên gợi ý. Đó là làm việc với các quy tắc hiện có của bộ định tuyến đối với lưu lượng truy cập đi và quay lại. Nghiên cứu cơ bản từ Bryan Ford, Pyda Srisuresh và Dan Kegel mô tả việc đục lỗ là một phương pháp thực tế được các ứng dụng dựa trên UDP sử dụng, đồng thời nhấn mạnh một hạn chế chính: không có kỹ thuật truyền tải nào hoạt động trên mọi thiết lập NAT.
Hạn chế đó quan trọng. Một số mạng sử dụng lại ánh xạ theo cách hữu ích. Những người khác tạo bản đồ được gắn chặt hơn với một điểm đến cụ thể. Một số mạng thêm hành vi tường lửa lên trên NAT. Một số mạng di động và ISP đặt người dùng phía sau NAT cấp nhà cung cấp dịch vụ, nơi người dùng hoàn toàn không kiểm soát lớp dịch ngược dòng.
Vì vậy, khi ai đó hỏi đục lỗ UDP là gì, câu trả lời ngắn gọn là: đó là một cách để các ứng dụng thử đường dẫn UDP trực tiếp thông qua ánh xạ do NAT tạo. Câu trả lời cẩn thận là: nó có thể hoạt động tốt trong nhiều môi trường, nhưng đó không phải là sự đảm bảo.
Tại sao kết nối trực tiếp đôi khi không thành công
Kết nối trực tiếp có thể không thành công vì một số lý do thông thường:
- Bộ định tuyến có thể không sử dụng lại cùng một ánh xạ cổng bên ngoài khi ứng dụng liên hệ với các điểm đến khác nhau.
- Mạng có thể lọc các gói UDP đến nghiêm ngặt hơn mạng khác.
- Lớp NAT cấp nhà cung cấp dịch vụ có thể nằm giữa người dùng và Internet công cộng.
- Mạng lưới nơi làm việc, trường học, khách sạn hoặc địa điểm có thể hạn chế giao thông theo chính sách riêng của họ.
- Mạng di động có thể thay đổi đường dẫn khi chất lượng tín hiệu hoặc phần đính kèm mạng thay đổi.
- Sản phẩm bảo mật hoặc tường lửa cục bộ có thể chặn lưu lượng truy cập trước khi truy cập ứng dụng.
Không có trường hợp nào trong số này có nghĩa là người dùng nên cố gắng bỏ qua các quy tắc mà họ không kiểm soát. Điểm thực tế là phải hiểu rằng hành vi kết nối phụ thuộc vào nhiều tùy chọn ứng dụng. Nếu mạng cố tình chặn hoặc giới hạn một loại lưu lượng truy cập thì bước tiếp theo thường là sử dụng mạng được phép, kiểm tra điều khoản dịch vụ hoặc nói chuyện với quản trị viên mạng.
Nơi dự phòng chuyển tiếp phù hợp
Khi kết nối trực tiếp không đáng tin cậy, một số hệ thống sử dụng rơle: cả hai điểm cuối đều kết nối ra bên ngoài với máy chủ trung gian và máy chủ sẽ chuyển lưu lượng giữa chúng. IETF RFC 5766 mô tả TURN, viết tắt của truyền tải sử dụng rơle xung quanh NAT, như một giao thức cho giao tiếp được hỗ trợ chuyển tiếp khi không thể giao tiếp ngang hàng trực tiếp trong một số tình huống NAT nhất định.
Rơle giải quyết một vấn đề khác với việc truyền tải trực tiếp NAT. Rơle có thể cải thiện khả năng kết nối vì cả hai thiết bị chỉ cần kết nối với dịch vụ chuyển tiếp. Sự đánh đổi là lưu lượng truy cập phải có thêm một đường dẫn, điều này có thể làm tăng thêm độ trễ, chi phí băng thông và độ phức tạp trong hoạt động.
Đây là lý do tại sao nhiều thiết kế kết nối thích thử đường dẫn trực tiếp trước, sau đó rút lui khi cần. IETF RFC 8445 mô tả ICE là một phương pháp tiếp cận tiêu chuẩn cho việc truyền tải NAT dành cho giao tiếp dựa trên UDP sử dụng các khái niệm STUN và TURN để khám phá và kiểm tra các đường dẫn có thể. Điều đó không có nghĩa là mọi công cụ liên quan đến VPN đều sử dụng ICE, STUN hoặc TURN. Nó chỉ hiển thị một mẫu kỹ thuật phổ biến: kiểm tra xem đường dẫn nào hoạt động, sau đó sử dụng phương án dự phòng nếu không có kết nối trực tiếp.
Đối với độc giả, bài học quan trọng là đặt ra kỳ vọng một cách thực tế. Dự phòng chuyển tiếp có thể giúp kết nối có thể thực hiện được trong trường hợp tuyến trực tiếp bị lỗi, nhưng nó không giống như việc làm cho mọi điều kiện mạng biến mất.
Điều này có ý nghĩa gì đối với độc giả VPN Satelites
Nội dung VPN Satelites thường liên quan đến các chủ đề như quyền riêng tư, kết nối, định tuyến internet và kỳ vọng của người dùng. Truyền tải NAT thuộc cùng một cộng đồng giáo dục đó vì nó giải thích tại sao mạng xung quanh một ứng dụng có thể quan trọng như chính ứng dụng đó.
Đối với chủ đề này, điều quan trọng là giữ kết nối sản phẩm ở mức khiêm tốn. Bài viết này không khẳng định rằng VPN Satelites sử dụng bất kỳ phương pháp truyền tải NAT cụ thể nào, kiến trúc chuyển tiếp, thiết lập chuyển tiếp cổng, tùy chọn IP tĩnh hoặc ngăn xếp giao thức. Giá trị ở đây là kiến thức thực tế: hiểu các thuật ngữ giúp bạn đọc hướng dẫn khắc phục sự cố cẩn thận hơn và đánh giá các sự cố kết nối mà không mong đợi bất kỳ ứng dụng nào liên quan đến VPN ghi đè mọi quy tắc mạng.
Nếu kết nối không ổn định, một số kiểm tra có mức độ rủi ro thấp có thể giúp bạn tách hành vi của ứng dụng khỏi hành vi của mạng:
- Hãy thử một mạng được phép khác, chẳng hạn như Wi-Fi tại nhà so với dữ liệu di động và lưu ý xem sự cố xảy ra do ứng dụng hay mạng.
- Khởi động lại bộ định tuyến cục bộ nếu bạn điều khiển nó và kết nối thông thường bị suy giảm.
- Kiểm tra xem mạng có được quản lý bởi nơi làm việc, trường học, khách sạn, địa điểm hoặc ISP có hạn chế về lưu lượng hay không.
- Luôn cập nhật ứng dụng và hệ điều hành vì việc xử lý kết nối có thể thay đổi giữa các phiên bản.
- Tránh thay đổi cài đặt tường lửa hoặc bộ định tuyến nâng cao trừ khi bạn hiểu tác động hoặc được sự chấp thuận của quản trị viên.
Các bước này không bỏ qua các hạn chế. Chúng giúp xác định vấn đề kết nối có thể đến từ đâu.
Cách đọc cẩn thận các xác nhận quyền sở hữu truyền tải NAT
Khi bạn thấy một sản phẩm, giao thức hoặc ứng dụng nói về quá trình truyền tải NAT, hãy đọc chính xác xác nhận quyền sở hữu đó.
Các câu hỏi hữu ích bao gồm:
- Tuyên bố về một kỹ thuật kết nối mạng chung hay một tính năng sản phẩm đã được xác nhận?
- Nó có giải thích điều kiện mạng nào được hỗ trợ và điều kiện nào không?
- Nó có đề cập đến hành vi dự phòng mà không hứa hẹn khả năng tiếp cận hoàn hảo không?
- Nó có tránh gợi ý rằng người dùng có thể bỏ qua các hạn chế về nơi làm việc, trường học, ISP, nền tảng hoặc pháp lý không?
- Nó có tách biệt các yêu cầu về quyền riêng tư khỏi các yêu cầu về kết nối không?
Điểm cuối cùng đó rất dễ bỏ lỡ. Tính năng giúp hai điểm cuối kết nối không tự động đảm bảo quyền riêng tư. Tính năng bảo mật không tự động là sự đảm bảo kết nối. Tài liệu tốt nên tách biệt những ý tưởng đó.
##Câu hỏi thường gặp
NAT có thể truyền tải giống như VPN không?
Không. Truyền tải NAT là một tập hợp các kỹ thuật mạng để xử lý việc dịch địa chỉ và lọc giữa các điểm cuối. VPN là một loại công nghệ rộng hơn để tạo các đường hầm mạng được bảo vệ. Một số ứng dụng giống VPN có thể phải tính đến hành vi của NAT, nhưng các khái niệm không giống nhau.
Việc đục lỗ UDP có luôn hiệu quả không?
Không. Việc đục lỗ UDP phụ thuộc vào hành vi, quy tắc lọc, thời gian và cấu trúc liên kết mạng của NAT. Các cuộc thảo luận về nghiên cứu và tiêu chuẩn đều hướng đến cùng một thực tế thực tế: Hành vi của NAT rất đa dạng, do đó có thể cần có các đường dẫn dự phòng.
Kết nối dự phòng chuyển tiếp có tốt hơn kết nối trực tiếp không?
Họ khác nhau. Rơle có thể trợ giúp khi không thể liên lạc trực tiếp nhưng nó có thể làm tăng thêm độ trễ, sử dụng băng thông và chi phí vận hành. Đường dẫn trực tiếp có thể hiệu quả hơn khi hoạt động nhưng có thể bị lỗi trên các mạng chặt chẽ hơn.
Bài viết này có nói VPN Satelites sử dụng STUN, TURN, ICE, rơle hoặc chuyển tiếp cổng không?
Không. Những thuật ngữ đó được thảo luận dưới dạng khái niệm mạng chung và nền tảng tiêu chuẩn. Bài viết này không đưa ra bất kỳ tuyên bố triển khai dành riêng cho sản phẩm nào về VPN Satelites.
NAT có thể vượt qua các quy tắc mạng không?
Bài viết này không cung cấp hướng dẫn bỏ qua. Truyền tải NAT có thể giúp giải thích hành vi kết nối nhưng người dùng phải tuân theo luật hiện hành, điều khoản dịch vụ và chính sách mạng.
Điểm mấu chốt
Việc truyền tải NAT rất quan trọng vì đường dẫn internet giữa hai thiết bị không phải lúc nào cũng trực tiếp hoặc có thể dự đoán được. Việc đục lỗ UDP có thể giúp một số ứng dụng thiết lập liên lạc trực tiếp trên NAT, trong khi dự phòng chuyển tiếp có thể hữu ích khi đường dẫn trực tiếp không thành công. Cả hai ý tưởng đều hữu ích nhưng không phải là giải pháp phổ biến.
Đối với độc giả VPN Satelites, bài học thiết thực nhất là đặt ra những kỳ vọng thực tế. Độ tin cậy của kết nối phụ thuộc vào ứng dụng, thiết bị, mạng cục bộ, chính sách mạng ngược dòng và tuyến đường rộng hơn giữa các điểm cuối. Việc hiểu các lớp đó giúp việc khắc phục sự cố trở nên dễ dàng hơn và các tuyên bố về sản phẩm dễ dàng được đọc một cách nghiêm túc hơn.