Bắt tay PiVPN thành công nhưng trang bị treo: kiểm tra MASQUERADE

Điện thoại hiển thị đường hầm là đã kết nối, máy khách báo một địa chỉ riêng, vậy mà trang đầu tiên vẫn treo giữa chừng khi tải. Sự kết hợp đó khiến phần lớn người dùng lao vào cấu hình mật mã và nhiệt độ CPU, nơi thật ra không có gì hỏng. Đường hầm đã lên, nghĩa là quá trình thương lượng xong; thứ thất bại là bước sau đó, khi máy chủ cố giao các gói của máy khách ra internet. Hãy đi đúng con đường mà những gói đó đi, và sự không khớp thường hiện ra ở một dòng của bảng NAT.

Hãy bắt đầu từ những gì máy khách tới được và không tới được

Từ máy khách đang kết nối, hãy tải một trang nằm trên internet công cộng và ghi nhận xem nó hỏng ngay hay treo giữa chừng. Sau đó mở một tài nguyên trên địa chỉ riêng của chính máy chủ VPN và so sánh hai kết quả.

Một địa chỉ đường hầm trả lời ping trong khi các trang công cộng hết thời gian chờ là dấu hiệu của vấn đề chuyển tiếp hoặc dịch địa chỉ, không phải của một cuộc bắt tay hỏng. Bảng trạng thái của chính máy khách không phân biệt được hai trường hợp, vì nó chỉ biết rằng kênh điều khiển đang hoạt động. Hãy kiểm tra trên máy chủ giao diện đường hầm bằng ip -br addr show tun0 và xác nhận địa chỉ cấp cho máy khách nằm trong nhóm địa chỉ bạn đã cấu hình. Nếu nhóm và địa chỉ máy khách không khớp, hãy sửa điều đó trước, vì mọi quy tắc bên dưới đều so khớp với nhóm.

Tiếp theo, hỏi máy chủ xem nó sẽ dùng giao diện nào để tới một địa chỉ công cộng. ip route get 203.0.113.9 in ra thiết bị và nguồn được chọn ở dòng đầu tiên. Hãy ghi lại tên thiết bị đó, vì đó chính là giá trị mà quy tắc NAT phải chứa.

Đọc quy tắc quyết định các gói có đi ra hay không

MASQUERADE chỉ ghi lại một gói khi gói đó rời khỏi giao diện được nêu trong quy tắc. Một quy tắc gắn với thiết bị có dây không làm gì cho lưu lượng đi ra qua Wi-Fi, và gói vẫn giữ địa chỉ nguồn riêng của nó cho tới router phía trên. Router đó không có tuyến quay lại nhóm đường hầm của bạn, nên nó bỏ phản hồi, và máy khách thấy một kết nối mở ra rồi chết. Triệu chứng tăng theo lượng trang đến trước khi cần phản hồi đầu tiên.

Liệt kê bảng đang hoạt động và đọc cột giao diện ra thay vì chỉ tìm chữ MASQUERADE. Kết quả ở dạng thêm vào dễ so sánh hơn một danh sách đã định dạng:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Trên một Raspberry Pi từng dùng Ethernet và nay dùng Wi-Fi, cái tên cũ gần như luôn là toàn bộ câu chuyện. Trình cài đặt đã ghi lại thiết bị nào có mặt lúc thiết lập, và bộ quy tắc đã lưu phát lại nó ở mỗi lần khởi động. Hãy so sánh thiết bị từ bước tra tuyến với thiết bị trong quy tắc trước khi đổi bất cứ thứ gì khác. Nếu chúng khớp nhau, giao diện không phải vấn đề của bạn và bạn nên chuyển sang các bộ đếm ở phần cuối. Nếu chúng khác nhau, cách sửa là chỉnh một từ trong tệp lưu trữ.

Sửa bộ quy tắc đã lưu, không chỉ bộ đang chạy

Chỉ sửa bảng đang hoạt động sẽ chỉ tồn tại tới lần khởi động lại kế tiếp, vừa đủ lâu để bạn tin rằng vấn đề đã được giải quyết. Các quy tắc quay lại khi khởi động nằm trong một tệp mà gói lưu trữ tường lửa nạp lại. Trên các ảnh Pi dựa trên Debian, tệp đó thường là /etc/iptables/rules.v4.

Hãy sao lưu trước khi chạm vào, sau đó thay giao diện ra trong dòng MASQUERADE bằng thiết bị bạn đã ghi lại, ví dụ -o wlan0 thay vì -o eth0. Giữ nguyên dải nguồn trừ khi nhóm máy khách của bạn đã thay đổi. Hãy nạp lại và xác nhận quy tắc giờ nêu đúng thiết bị:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Hai thiết lập liền kề rất dễ quên. sysctl net.ipv4.ip_forward phải báo 1, và router phía trên không được tự lọc các địa chỉ nguồn riêng.

Chứng minh quy tắc có hiệu lực, rồi tách riêng phần vẫn còn chậm

Bộ đếm là bằng chứng trung thực duy nhất cho thấy một quy tắc đã khớp. Hãy chạy danh sách chi tiết, bắt đầu một lượt tải trên máy khách và chạy lại. Cột gói và byte bên cạnh quy tắc của bạn phải tăng, và một quy tắc đứng ở số không vẫn chưa khớp. Nếu bộ đếm nhích nhưng trang vẫn hỏng, hãy so dải nguồn với nhóm thực tế bằng grep -n "^server " /etc/openvpn/server.conf. Nếu chúng nhích và trang tải được nhưng thông lượng kém, việc dịch đã xong và vấn đề còn lại nằm ở chỗ khác.

So sánh hai lượt truyền từ cùng một máy khách, một tới máy chủ trong mạng cục bộ và một qua đường hầm tới chính máy đó. Chậm ở cả hai trường hợp cho thấy tuyến lên của Pi hoặc kết nối Wi-Fi, không phải VPN. Chậm chỉ khi qua đường hầm cho thấy MTU và việc truyền lại, có thể xem bằng ip -s link show tun0 trước khi đổi bất kỳ thiết lập mật mã nào.

Để hoàn tác thí nghiệm, hãy khôi phục bản sao và nạp lại, rồi xác nhận quy tắc gốc và bộ đếm của nó đã trở lại. Ghi thiết bị ra và lệnh nạp lại vào ghi chú máy chủ, vì lần đổi tuyến lên tiếp theo sẽ phát hiện lại đúng sự không khớp đó. Một quy tắc nêu sai thiết bị vẫn vô hình cho tới khi lưu lượng cần đến nó.