Cài đặt punchy của Nebula: cái nào sửa được NAT của bạn

Hai peer tìm thấy nhau qua ngọn hải đăng rồi không dựng được đường đi trực tiếp, và phản xạ đầu tiên là bật mọi tùy chọn punchy. Phản xạ đó tạo ra một cấu hình có ba thay đổi mà không biết thay đổi nào quan trọng. Các cài đặt trả lời những câu hỏi khác nhau: một cái duy trì ánh xạ đã tồn tại, cái kia thử một cái bắt tay theo hướng ngược lại. Hãy quyết định bạn đang có câu hỏi nào trước khi chạm vào cái nào.

Xác nhận điểm cuối trước khi bàn đến thời điểm

Một peer không bao giờ xuất hiện ở địa chỉ mong đợi sẽ không được cứu bằng việc chỉnh punch. Hãy xem ngọn hải đăng biết gì về peer và cấu hình của chính peer công bố điều gì, vì một địa chỉ bootstrap cũ hoặc một địa chỉ riêng bị công bố nhầm vô hiệu hóa mọi mẹo xuyên qua. Cũng xác nhận rằng chứng chỉ đáng tin cậy, vì một danh tính không đáng tin sẽ dừng cuộc trao đổi rất lâu trước khi NAT trở nên quan trọng. Sau đó kiểm tra xem UDP có đến được ngọn hải đăng hay không. Các giá trị thời gian là thứ cuối cùng cần xem, không phải thứ đầu tiên.

Ghi lại cặp điểm cuối bạn đang thử, để các so sánh sau dùng đúng những peer đó chứ không phải hai máy khác.

punch giữ ánh xạ, respond mở một hướng

Tùy chọn punch định kỳ gửi các gói rỗng đến địa chỉ lớp dưới của một peer đã có đường hầm. Mục đích không hào nhoáng: nó ngăn NAT có trạng thái hoặc tường lửa để ánh xạ mà đường đi trực tiếp phụ thuộc vào bị hết hạn. Tùy chọn respond thay đổi điều xảy ra khi có thông báo từ ngọn hải đăng, khiến máy chủ thử một cái bắt tay ngược về phía peer đang cố tiếp cận nó. Đây là những cơ chế khác nhau với kiểu hỏng khác nhau.

Chọn punch khi đường đi trực tiếp hoạt động rồi sau đó suy yếu. Chọn respond khi đường đi không bao giờ hình thành theo một hướng. Bật cả hai và hy vọng là cách một bản sửa năm phút biến thành một tuần chỉnh sửa.

Độ trễ quyết định khi nào, không phải có hay không

Các giá trị độ trễ dịch chuyển thời điểm: một cái áp dụng cho gói được gửi sau thông báo, cái kia cho lần thử bắt tay ngược. Không cái nào làm một hướng bị chặn hoạt động. Thay đổi cả hai cùng lúc phá hủy phép so sánh bạn sắp thực hiện.

Hãy để chúng yên cho đến khi cơ chế đúng. Sau đó chỉnh một cái, và ghi lại giá trị cũ.

Khi một relay là câu trả lời trung thực

Một số tổ hợp NAT không thể hỗ trợ đường đi trực tiếp, dù thời điểm được sắp xếp thế nào. NAT đối xứng ở cả hai phía, hoặc tường lửa loại bỏ hoàn toàn lưu lượng vào không được yêu cầu, không để lại gì để đục qua.

Một nút relay có địa chỉ tiếp cận được cho các peer đó một đường đi không phụ thuộc vào việc xuyên qua thành công. Nó tốn băng thông qua nút đó, nên đây là quyết định về dung lượng chứ không phải cách lách. Cấu hình relay một cách có chủ đích và kiểm tra rằng các peer tiếp cận được nó, vì một relay tự nó nằm sau NAT khó thì không thay đổi gì. Sau đó ngừng chỉnh cài đặt punch cho cặp đó, vì đường đi trực tiếp sẽ không bao giờ xuất hiện.

Thử lại cặp đã hỏng, sau khi để rỗi

Tái tạo điều kiện đã hỏng: để cặp đó rỗi trong cùng khoảng thời gian, hoặc lặp lại trình tự bắt tay từng thất bại. Sau đó chạy ứng dụng giữa hai peer đó, không phải một yêu cầu tới ngọn hải đăng. Câu trả lời từ ngọn hải đăng chứng minh đường điều khiển và không nói gì về đường dữ liệu.

Ghi lại cài đặt nào đã thay đổi, thời điểm, và liệu một đường đi trực tiếp có xuất hiện hay lưu lượng vẫn ở trên relay. Nếu vẫn ở, câu trả lời là một relay và một ghi chú dung lượng, và đó là kết quả hoàn toàn tốt. Nếu xuất hiện, câu hỏi tiếp theo là liệu nó có sống qua một giờ để rỗi, vì một ánh xạ suy yếu chính là vấn đề mà punch tồn tại để giải quyết.