Đã kết nối OpenVPN nhưng không tải được gì: hành trình từ máy khách ra ngoài

Cửa sổ máy khách ghi Connected, địa chỉ đường hầm có đó, mà trình duyệt vẫn quay. Sự kết hợp đó là bình thường, vì một lần bắt tay thành công chỉ chứng minh rằng đường hầm đã được dựng; nó không nói gì về việc máy chủ có chuyển tiếp gói tin của bạn, viết lại nguồn của chúng hay trả lời các truy vấn DNS của bạn hay không. Sai lầm mà đa số mắc phải là mở cấu hình máy chủ trước. Thay vào đó, hãy làm việc từ máy khách ra ngoài, vì mỗi bước dưới đây cho biết bước tiếp theo có đáng kiểm tra hay không.

Bắt đầu ở máy khách và đi ra ngoài

Chạy ba phép thử theo thứ tự này và ghi lại nơi phép thử đầu tiên thất bại. Ping địa chỉ đường hầm của máy chủ, điều này chứng minh chính đường hầm có mang lưu lượng. Ping một địa chỉ công cộng bằng số, điều này chứng minh việc chuyển tiếp và dịch địa chỉ mà không cần đến phân giải tên. Sau đó thử phân giải một tên máy chủ, đây là phép thử duy nhất dùng DNS. Mỗi kết quả loại bỏ được cả một lớp khỏi nghi vấn.

Đừng nhảy sang phép thử thứ ba chỉ vì trình duyệt có cảm giác nhanh hơn. Một lần tải trang thất bại bao trùm cả ba lớp cùng lúc, và chính từ đó người ta bắt đầu rồi sau đó dựng lại một đường hầm vốn đang chạy được. Trang thất bại không cho biết lớp nào trong ba lớp bị hỏng.

Hai lần bắt gói cho thấy gói tin dừng ở đâu

Trong khi ping tới một địa chỉ công cộng đang chạy từ máy khách, hãy bắt gói một lần trên giao diện đường hầm và một lần trên đường lên được cho là sẽ ra internet. Chạy cả hai cùng lúc để dấu thời gian khớp nhau.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Nếu các yêu cầu xuất hiện trên đường hầm mà không bao giờ xuất hiện trên đường lên, máy chủ đã bỏ chúng giữa đường hầm và dây, và nguyên nhân là chuyển tiếp hoặc chính sách tường lửa cho chuyển tiếp, không phải NAT. Nếu chúng xuất hiện trên cả hai, máy chủ đã làm phần của mình và câu trả lời mất ở xa hơn, điều này chỉ ra việc dịch địa chỉ, một bộ lọc phía trên hoặc một hạn chế từ nhà cung cấp.

Lấy tên đường lên từ bảng định tuyến, không phải từ bài hướng dẫn. Ảnh đám mây và bộ điều hợp đã đổi tên hiếm khi khớp với giao diện ví dụ trong tài liệu, và một lần bắt gói trên thiết bị sai trông đúng như một máy chủ không chuyển tiếp:

ip -4 route get 9.9.9.9

Trường dev trong đầu ra đó là cái tên mà quy tắc NAT sẽ cần về sau, nên hãy giữ nó lại.

Chuyển tiếp là một công tắc trong nhân và một chính sách tường lửa

Nhân phải đồng ý chuyển tiếp ngay từ đầu. Đọc giá trị hiện tại, rồi làm cho thiết lập thành vĩnh viễn thay vì chỉ ghi vào nhân đang chạy:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Chuyển tiếp chỉ là một nửa. Trên một máy chủ dùng UFW, chính sách chuyển tiếp được đặt trong /etc/default/ufw và phải là ACCEPT trước khi việc nạp lại có hiệu lực. Việc bỏ mặc định trên đường chuyển tiếp để cho lần bắt tay vẫn hoàn toàn khỏe mạnh trong khi âm thầm vứt bỏ mọi gói tin cố ra khỏi đường hầm, và đó chính là triệu chứng bạn gặp ban đầu.

Các máy chủ quản lý nftables trực tiếp có cùng câu hỏi với cú pháp khác. Hãy xem các bộ đếm trên chuỗi chuyển tiếp trong khi một phép thử từ máy khách đang chạy, vì chuỗi được hỏi tới và chuỗi vứt bỏ trông giống hệt nhau trong một tệp cấu hình.

Đặt tên giao diện ra thật trong quy tắc NAT

Việc dịch nguồn thuộc về giao diện thực sự rời khỏi máy chủ, cùng với nhóm địa chỉ mà máy chủ cấp. Cả hai nửa của quy tắc đó đều phải mô tả thực tế, và không nửa nào là tùy chọn.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Lỗi kinh điển là một quy tắc chép từ tài liệu nói -o eth0 trên một máy mà bộ điều hợp có tên khác. Quy tắc được cài đặt mà không có cảnh báo, không khớp với gì cả, và máy khách vẫn không có internet. Nhóm địa chỉ là nửa còn lại của cùng lỗi đó: nếu máy chủ cấp 10.44.0.0/24 mà quy tắc bao phủ 10.8.0.0/24 thì sẽ không bao giờ khớp.

Hãy xem các bộ đếm thay vì tin vào phần chữ của quy tắc. Danh sách báo cáo số gói cho mỗi quy tắc, và một quy tắc không bao giờ khớp sẽ đứng ở số không dù trông đúng đến đâu. Hãy cho nó một phút lưu lượng máy khách thật trước khi đọc bất cứ điều gì từ con số đó:

iptables -t nat -L POSTROUTING -v -n

Số gói bằng không sau một phép thử máy khách thật nghĩa là việc khớp sai, không phải đường hầm hỏng. Khi nó khớp, hãy lưu bộ quy tắc để nó sống sót qua lần khởi động lại; một bản sửa chỉ sống trong lịch sử shell của bạn sẽ biến mất ngay lần khởi động lại đầu tiên.

Nếu máy chủ cũng là một phiên bản NAT trên đám mây, nền tảng cũng có tiếng nói. Một phiên bản dịch địa chỉ thường cần tắt kiểm tra nguồn và đích ở nơi nhà cung cấp có thiết lập đó, và bản thân cổng VPN phải truy cập được từ bên ngoài.

DNS là lỗi thứ hai phía sau lỗi thứ nhất

Ping bằng địa chỉ chạy được trong khi tên thất bại là vấn đề của bộ phân giải, và nó có nguyên nhân riêng. Một máy khách giữ bộ phân giải cục bộ của mình sẽ gửi các truy vấn đó vào một đường hầm đầy đủ và chờ một câu trả lời không bao giờ đến, vì bộ phân giải cục bộ giờ ở phía bên kia của tuyến đường.

Đẩy một bộ phân giải từ máy chủ để máy khách biết hỏi ở đâu. Hai mục cho máy khách một phương án dự phòng nếu mục đầu không tới được, và cả hai nên là bộ phân giải mà đường hầm thực sự cho phép.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Máy khách Windows sau đó vẫn có thể quay lại bộ phân giải cục bộ, và đó chính là điều block-outside-dns ra đời để ngăn, với cái giá là mất những tên mà chỉ mạng cục bộ mới phân giải được. Máy khách Linux dùng systemd-resolved thường bỏ qua bộ phân giải được đẩy tới trừ khi có script cài nó, nên hãy kiểm tra resolvectl status cho thiết bị đường hầm trước khi kết luận rằng việc đẩy bị bỏ qua.

Kết thúc hành trình theo cách người dùng trải nghiệm. Tải một trang thật từ máy khách, xác nhận địa chỉ mà nó đi ra, khởi động lại máy chủ, kết nối lại và lặp lại ba phép thử. Chỉ vòng thứ hai đó mới chứng minh rằng các quy tắc đã lưu, chính sách tường lửa và bộ phân giải được đẩy tới đều sống sót cùng nhau.