Bắt tay WireGuard hoạt động nhưng mạng con của văn phòng không phản hồi
WireGuard đang chạy và ping được máy chủ, nhưng không có gì trên LAN của nó phản hồi. Kiểm tra tiền tố của máy khách, việc chuyển tiếp trên máy chủ và đường đi của phản hồi.
Bắt tay hoàn tất, wg show báo cáo truyền tải gần đây, và địa chỉ đường hầm của máy chủ phản hồi ping. Nhưng một máy trong LAN của máy chủ thì không. Ba điều kiện phải cùng đúng: máy khách phải định tuyến tiền tố LAN vào đường hầm, máy chủ phải chuyển tiếp các gói, và phản hồi cần một đường quay lại. Khi thiếu một trong ba, triệu chứng giống hệt nhau.
AllowedIPs vừa là danh sách truy cập vừa là bảng định tuyến
Trên máy khách, danh sách AllowedIPs quyết định cả những gì được gửi đến peer đó lẫn những tuyến mà WireGuard cài đặt. Một mục peer chỉ liệt kê địa chỉ đường hầm của máy chủ sẽ cài một tuyến máy duy nhất, nên các đích trong LAN không bao giờ vào đường hầm. Thêm tiền tố LAN là việc đầu tiên cần kiểm tra, và cũng là thay đổi thường thiếu nhất sau khi sao chép cấu hình. Một peer được mở rộng thành tuyến mặc định là thiết kế khác, và nó cũng sẽ chuyển lưu lượng internet của máy khách.
Giữ tuyến máy và tiền tố LAN thành các mục riêng. Nếu văn phòng có hai mạng con, cả hai đều thuộc danh sách, và tiền tố thứ hai bị thiếu tạo ra lỗi trông có vẻ chọn lọc chứ không toàn phần.
[Peer] PublicKey = <server public key> Endpoint = vpn.example.net:51820 AllowedIPs = 10.66.0.1/32, 192.168.50.0/24
Chuyển tiếp và dịch thuộc về máy chủ
Máy chủ cần bật chuyển tiếp IP, một quy tắc chuyển tiếp chấp nhận lưu lượng đến từ đường hầm, và một quy tắc dịch về phía giao diện LAN của nó. Chính việc dịch giúp thiết kế hoạt động mà không phải chạm vào từng máy trong mạng văn phòng. Khi đó phản hồi quay về máy chủ thay vì một địa chỉ mà LAN chưa từng nghe. Không có nó, mỗi máy cần một tuyến đến mạng con của đường hầm và một quy tắc tường lửa cho phép, điều hiếm khi chấp nhận được trên mạng do người khác quản lý.
sysctl -w net.ipv4.ip_forward=1 iptables -A FORWARD -i wg0 -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Các quy tắc thêm thủ công biến mất khi khởi động lại, vì vậy hãy gắn chúng với giao diện bằng các lệnh hook trong cấu hình máy chủ. Một bộ quy tắc sống lâu hơn giao diện của nó là cách một máy cuối cùng dịch lưu lượng cho một đường hầm không còn tồn tại.
Khi LAN chuyển đi mà quy tắc thì không
Thay bộ định tuyến đánh số lại mạng con của văn phòng là phiên bản kinh điển của lỗi này. Đường hầm vẫn hoạt động, bắt tay vẫn mới, và không có gì sau máy chủ phản hồi, vì quy tắc dịch vẫn nêu địa chỉ cũ. Các script cài đặt thường nhúng địa chỉ LAN của máy chủ vào một quy tắc POSTROUTING, và sau khi đánh số lại thì địa chỉ đó không tồn tại trên giao diện nào. Các gói sau đó được viết lại đến một đích không thể phản hồi.
iptables -t nat -n -L POSTROUTING ip -br addr show
So sánh hai đầu ra. Một đích dịch không xuất hiện trong danh sách giao diện chính là lỗi, và sửa nó là thay đổi một dòng sau khi bạn đã thấy. Quy tắc có thể nằm trong một unit được tạo ra thay vì trong cấu hình WireGuard, vì vậy hãy tải lại unit đó sau khi sửa và xác nhận lần khởi động sau không ghi đè thay đổi của bạn.
Hai trang sau NAT cần một nơi gặp nhau
Khi không bên nào chấp nhận kết nối vào, câu trả lời thực tế là một máy nhỏ có địa chỉ công cộng và hai giao diện WireGuard. Mỗi trang kết nối ra ngoài, máy ở giữa liệt kê LAN của từng peer trong AllowedIPs, tức là danh sách riêng của nó, và chuyển tiếp mang gói giữa hai đường hầm. Không có gì trong tường lửa của trang nào phải thay đổi, đó là lý do thiết kế này lan rộng dễ dàng.
Định tuyến giữa các trang giữ địa chỉ nguồn gốc và do đó giữ việc ghi log theo từng máy có ý nghĩa. Dịch tại máy ở giữa đơn giản hơn khi hai LAN chồng lấn, nhưng với cái giá là mất danh tính nguồn trong log. Hãy quyết định thuộc tính nào quan trọng trước khi chọn.
Tách các tầng bằng bốn kiểm tra
Chạy một kiểm tra mỗi tầng thay vì thay đổi ba thứ rồi hy vọng. Cái đầu tiên cho thấy tuổi bắt tay và bộ đếm cho từng peer. Cái thứ hai cho thấy máy khách có thực sự định tuyến đích đó vào đường hầm không. Cái thứ ba và thứ tư cho biết yêu cầu đã đến chưa và liệu một chính sách có bỏ nó sau khi đến không.
wg show ip route get 192.168.50.20 tcpdump -ni wg0 icmp iptables -vnL FORWARD --line-numbers
Một yêu cầu đến mà không tạo ra phản hồi chỉ vào đường đi của phản hồi hoặc máy trong LAN. Một yêu cầu không bao giờ đến chỉ vào AllowedIPs hoặc tuyến của máy khách. Hai kết quả này cần cách sửa khác nhau, và việc bắt gói là thứ phân biệt chúng.