WireGuard hoạt động trên dữ liệu di động nhưng không trên cùng một wifi
Một yêu cầu từ bên trong LAN tới địa chỉ công khai của router đi theo đường khác với yêu cầu qua dữ liệu di động. Hãy thử bên ngoài rồi chọn một đường cục bộ.
Đường hầm bật lên trên dữ liệu di động rồi nằm ở đang kết nối khi về nhà, với cùng hồ sơ, cùng khóa peer và không có thay đổi cấu hình nào ở giữa. Khác biệt nằm ở chặng đường: một yêu cầu từ bên trong LAN tới địa chỉ công khai của router không phải cùng chặng đường với một yêu cầu đến từ internet. Hầu hết gateway gia đình hoặc không triển khai đường về, hoặc chỉ triển khai cho một số giao thức nhất định. Điều đó khiến triệu chứng trông như khóa hỏng trong khi không có gì ở khóa thay đổi. Hãy xác định đường nào đã hỏng trước khi chạm vào khóa, chuyển tiếp cổng hay hồ sơ máy khách.
Một địa chỉ, hai đường khác nhau
Từ bên ngoài, một gói tin tới địa chỉ công khai của router và một quy tắc chuyển tiếp cổng chuyển nó cho trình lắng nghe WireGuard trên máy chủ nội bộ. Từ bên trong, máy khách gọi chính địa chỉ công khai đó, nên gói tin rời máy khách, tới router và phải được quay ngược trở lại LAN. Chính ở chỗ quay ngược đó hai đường tách nhau, vì router phải dịch một luồng vừa rời vừa quay lại cùng một giao diện. Nhiều bản triển khai bỏ nó thay vì dịch nó, và máy khách sau đó chờ một cái bắt tay chưa từng được gửi.
Hành vi này thường được gọi là NAT loopback hay hairpinning, và nó thuộc về router chứ không phải WireGuard; RFC 4787 trình bày các trường hợp dịch mà một gateway có thể hỗ trợ hoặc không. Bản thân WireGuard không có ý kiến về đường đi, vì nó chỉ thấy các gói tin tới được giao diện của mình. Khi router bỏ luồng, daemon không bao giờ nhận được gì, máy khách báo hết thời gian bắt tay, và nhật ký máy chủ vẫn trống. Nhật ký trống vì thế là manh mối về nơi gói tin dừng lại, không phải bằng chứng máy chủ đã chết. Đó cũng là lý do cài lại không thay đổi gì.
Điều ngược lại cũng quan trọng: một nhật ký máy chủ cho thấy nỗ lực bắt tay từ địa chỉ LAN chứng minh gói tin đã tới và đường đi tốt, điều đó chuyển cuộc điều tra sang khóa và địa chỉ được phép. Hãy đọc nhật ký theo điều nó chứng minh, không theo điều bạn mong thấy.
Tái hiện trước khi thay đổi bất cứ điều gì
Hãy thử từ một mạng bên ngoài được cấp phép với cùng thiết bị và cùng hồ sơ, rồi lặp lại phép thử bên trong LAN mà không sửa gì. Một cái bắt tay hoàn tất ở ngoài và một máy khách ở trong không bao giờ rời thiết bị tái hiện điều kiện thay vì đoán nó. Cả hai lần thử phải dùng cùng hồ sơ, nếu không phép so sánh không chứng minh gì.
Sau đó xem tên điểm cuối phân giải tới đâu cho thiết bị này. Ba lệnh sau cũng cho thấy máy khách thực sự đã gọi địa chỉ nào:
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.netLệnh đầu báo điểm cuối mà giao diện đang dùng, và hai lệnh còn lại cho thấy tên phân giải tới đâu trên máy này. Một máy khách gọi địa chỉ công khai trong khi đang ở cùng mạng với máy chủ là đang dùng đường hairpin. Một máy khách gọi địa chỉ LAN thì không, và hỏng ở đó thuộc một cuộc điều tra khác. Sự phân biệt đó quyết định phần sau có áp dụng chút nào không.
Những cách được hỗ trợ để tới máy chủ gần đó
Cách bố trí sạch nhất là một câu trả lời phân chia theo tầm nhìn: tên công khai phân giải tới địa chỉ công khai cho internet và tới địa chỉ LAN của máy chủ cho máy khách bên trong. Hồ sơ giữ một tên điểm cuối và trình phân giải chọn đường. Điều đó cần kiểm soát câu trả lời DNS nội bộ, thứ mà router gia đình thường cung cấp và một tổ chức có thể sắp đặt có chủ đích. Không có kiểm soát đó, các lựa chọn còn lại là một tính năng router hoặc hồ sơ thứ hai.
Tính năng router là phản xạ: gateway dịch luồng từ trong ra ngoài và gửi ngược vào trong. Ở nơi nó hoạt động thì không cần thay đổi máy khách, và ở nơi nó không hoạt động thì không cài đặt máy khách nào cứu được. Hãy thử bằng cách theo dõi nhật ký máy chủ trong một lần thử nội bộ thay vì đọc danh sách tính năng của router.
Sửa hồ sơ sang một địa chỉ riêng là chẩn đoán, không phải thiết kế. Nó chứng minh máy chủ trả lời trên LAN, và nó phá cùng hồ sơ đó ngay khi laptop rời khỏi nhà.
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
Giữ hồ sơ dùng được khi xa nhà
Dù chọn đường nào, hãy để yên việc kiểm tra danh tính. Địa chỉ điểm cuối không phải danh tính peer, và thay đổi địa chỉ không bao giờ biện minh cho việc chấp nhận một khóa công khai không liên quan tình cờ trả lời. WireGuard xác thực bằng khóa, nên một máy chủ sai sẽ hỏng ở bước bắt tay thay vì cấp quyền truy cập vào thứ bất ngờ.
Nếu địa chỉ công khai di chuyển, DNS động là thứ giữ tên hữu ích, và hành vi làm mới của máy khách quyết định thay đổi tới nhanh đến đâu. Hãy thử điều đó từ bên ngoài sau khi đổi địa chỉ, vì trường hợp LAN không thể xác nhận nó. Hãy để ý một trình phân giải lưu câu trả lời cũ quá vòng đời của bản ghi. Một tên vẫn trỏ tới địa chỉ trước trông y hệt một máy chủ đã sập.
Hãy ghi lại hồ sơ dùng tên nào và nó phân giải tới đâu ở mỗi phía của ranh giới. Một hồ sơ phụ thuộc vào tính năng router mà không ai ghi lại là một cuộc gọi hỗ trợ chờ bản cập nhật firmware tiếp theo. Ghi chú đó cũng là thứ nói cho người kế tiếp biết lỗi nội bộ là trường hợp hairpin đã biết hay là điều gì mới.