Máy khách VPN kết nối được nhưng không có internet: ba phần còn thiếu

Máy khách nhận được địa chỉ, máy chủ trả lời ping, và mỗi trang vẫn hết thời gian chờ. Hầu hết mọi người bắt đầu chỉnh sửa hồ sơ máy khách tại điểm này, việc thường là công sức lãng phí: một khi đường hầm đã lên, máy chủ phải hành xử như một bộ định tuyến. Ba điều kiện phải cùng đúng trước khi một gói tin đi ra và một câu trả lời quay về, và triệu chứng là như nhau dù thiếu điều kiện nào.

Vì sao một đường hầm hoạt động vẫn không có lối ra

Nhân hệ điều hành phải chuyển tiếp gói tin giữa các giao diện, điều này mặc định bị tắt trên hầu hết bản phân phối Linux. Lưu lượng phải được dịch sang một địa chỉ mà thế giới bên ngoài có thể trả lời, trừ khi mọi bộ định tuyến thượng nguồn đã biết đường quay về mạng con của đường hầm. Đường chuyển tiếp của tường lửa phải cho phép lưu lượng theo cả hai chiều, bao gồm cả các câu trả lời.

Mỗi điều trong số đó có thể được sửa riêng, và đó chính là cái bẫy. Bật chuyển tiếp mà không có quy tắc dịch địa chỉ khiến gói tin đi ra với nguồn riêng và không có đường quay về. Thêm dịch địa chỉ mà không có quy tắc chuyển tiếp khiến nhân hệ điều hành bỏ gói tin ở bước sau.

Vì vậy hãy kiểm tra ba tầng thay vì máy khách, và thay đổi từng thứ một để kết quả có ý nghĩa.

Chuyển tiếp là một công tắc của nhân cần được làm cho bền vững

Kiểm tra giá trị hiện tại trước khi thay đổi, sau đó đặt nó và xác nhận thay đổi đã có hiệu lực.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Lệnh đầu tiên báo giá trị hiện tại, lệnh thứ hai đặt nó khi đang chạy, và lệnh thứ ba chứng minh việc ghi đã hoạt động. Giá trị khi chạy biến mất ở lần khởi động lại tiếp theo, vì thế một phiên đang hoạt động có thể hỏng sau bảo trì mà không có bất kỳ thay đổi cấu hình nào.

Hãy làm cho nó bền vững trong một tệp dưới /etc/sysctl.d/, rồi áp dụng tệp đó thay vì khởi động lại để biết. Trên FreeBSD, tương đương là net.inet.ip.forwarding, với gateway_enable=YES trong rc.conf để duy trì. Một thiết bị báo chuyển tiếp bị tắt giải thích cả một loại báo cáo «gói tin đến mà không có gì quay về». Hãy kiểm tra cài đặt sau mỗi lần nâng cấp nữa, vì một nhân được dựng lại hoặc một ảnh thiết bị bị thay thế có thể đặt lại nó mà không báo cho ai.

Chọn masquerade hoặc một địa chỉ dịch cố định

Với địa chỉ bên ngoài động, masquerading là dạng đúng đơn giản nhất. Đặt tên mạng con của đường hầm là nguồn và giao diện bên ngoài là lối ra.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Với địa chỉ công cộng tĩnh, việc dịch nguồn sang đúng địa chỉ đó dễ dự đoán hơn và dễ kiểm toán hơn.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Dạng thứ hai mang một cái bẫy bảo trì: một địa chỉ được mã hóa cứng mà sau đó thay đổi sẽ giữ đường hầm hoạt động trong khi quyền truy cập internet âm thầm dừng lại. Hoặc dùng masquerade hoặc cập nhật quy tắc mỗi khi nhà cung cấp di chuyển bạn. Giao diện cũng quan trọng, vì một bộ định tuyến chia sẻ đường hầm thượng nguồn của chính nó phải dịch ra qua đường hầm đó chứ không phải qua WAN vật lý.

Bảng lọc là cổng thứ ba

Chuyển tiếp và dịch địa chỉ đều có thể đúng trong khi gói tin vẫn chết trong bảng lọc. ufw là thủ phạm thường gặp: chính sách chuyển tiếp của nó được cung cấp dưới dạng DROP, và phần còn lại của cấu hình có thể trông hoàn toàn đúng trong khi cài đặt duy nhất đó giết lưu lượng. Nâng nó lên là một quyết định bảo mật có chủ đích chứ không phải một ô chọn.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Quy tắc đầu tiên cho phép lưu lượng mới từ đường hầm ra ngoài, và quy tắc thứ hai chỉ cho các câu trả lời quay về. Thu hẹp cả hai vào mạng con của đường hầm và đích dự định, vì một sự cho phép toàn diện trên giao diện đường hầm biến VPN thành một điểm ra mở cho bất kỳ ai có thể xác thực.

Một đường hầm có cầu cần câu trả lời khác. Địa chỉ thuộc về cầu, không thuộc về cổng vật lý, nên việc bắt giao diện làm nô lệ sẽ xóa địa chỉ mà nó từng có và máy chủ trông không thể truy cập cho đến khi chính cầu nhận được một địa chỉ, điều mà dhclient br0 có thể cung cấp. Sự cố đó trông như vấn đề VPN và thực ra là vấn đề tầng hai. Hãy kiểm tra địa chỉ của chính cầu trước khi chạm vào tường lửa, vì thay đổi bộ lọc không thể sửa một máy chủ không còn địa chỉ để gửi đi.

Nhìn vào đâu khi một trang không bao giờ tải

Ping địa chỉ đường hầm của máy chủ để chứng minh đường hầm tồn tại. Sau đó chạy traceroute từ máy khách đến một địa chỉ công cộng và đọc xem nó dừng ở đâu: tại máy chủ gói tin đến nhưng không được chuyển tiếp hay dịch; vượt qua máy chủ thì vấn đề ở thượng nguồn và ngoài tầm tay của bạn.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Lệnh đầu tiên chứng minh đường hầm mang lưu lượng đến chính máy chủ, và lệnh thứ hai cho thấy gói tin đi được bao xa ra ngoài. Một vết kết thúc tại địa chỉ đường hầm chỉ ra việc chuyển tiếp hoặc dịch địa chỉ trên máy chủ, trong khi một vết dừng lại sau một bước nhảy chỉ ra nhà cung cấp hoặc đường quay về của bộ định tuyến thượng nguồn.

Trên máy chủ, hãy quan sát giao diện bên ngoài trong khi một máy khách tải trang. Lưu lượng đi ra với địa chỉ nguồn riêng nghĩa là thiếu dịch địa chỉ, và hoàn toàn không có câu trả lời nghĩa là đường chuyển tiếp hoặc đường quay về thượng nguồn đang bỏ nó.

Nếu máy khách từ xa cũng phải đến được các máy chủ trong LAN của máy chủ, hãy nhớ rằng LAN cần một đường quay về mạng con của đường hầm. Đó là định tuyến chứ không phải dịch địa chỉ, và đó là bước thường bị quên nhất sau khi đường internet cuối cùng đã hoạt động.