Biểu tượng xanh, cùng IP công cộng: VPN đã bỏ qua tuyến nào

Đã kết nối, biểu tượng khay màu xanh và trang hiển thị địa chỉ vẫn báo địa chỉ của nhà cung cấp — điều đó không tự động có nghĩa là lỗi. Máy khách làm hai việc riêng biệt: nó dựng đường hầm và sửa bảng định tuyến. Việc này có thể xảy ra mà không có việc kia, và định tuyến chọn lọc là cấu hình trong đó việc thứ hai bị bỏ qua có chủ ý.

Máy khách thực sự đã cài gì

Hãy hỏi giao diện nào sẽ mang gói tin đến một đích thực sự thay vì hỏi đường hầm có hoạt động không. Một đường hầm không có tuyến đến đích đó là con đường riêng không ai dùng.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

Lệnh đầu tiên trả lời trên Linux và macOS, hai lệnh còn lại là tương đương cho Windows, nơi chỉ một là đủ. Nếu câu trả lời nêu bộ điều hợp vật lý, đường hầm đang hoạt động và tuyến mặc định chưa bao giờ dịch chuyển. Lặp lại kiểm tra cho một đích nên dùng đường hầm, vì hai lần kiểm tra, một xa và một thông thường, cho biết thiết kế nào đang được triển khai.

Ba dạng định tuyến chọn lọc

Hồ sơ đường hầm đầy đủ thường ghi tuyến mặc định trỏ vào giao diện, hoặc ghi cặp tiền tố nửa phạm vi thắng theo độ dài tiền tố trong khi tuyến mặc định gốc vẫn nằm trong bảng. Định tuyến chọn lọc là lựa chọn còn lại, và nó có nhiều dạng. Một hồ sơ định tuyến một máy chủ như máy chủ RDP, một hồ sơ khác định tuyến một dải công cộng phải đến từ một vị trí cụ thể, và hồ sơ thứ ba cố ý loại trừ một ứng dụng. Cả ba đều hợp lệ, và không cái nào thay đổi địa chỉ mà một trang web thông thường nhìn thấy.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Đọc hồ sơ để tìm chỉ thị quyết định, rồi đọc bảng để xem nó tạo ra gì. Một chỉ thị bị đẩy xuống cũng có thể bị chặn ở máy khách, vì vậy hồ sơ và bảng phải khớp nhau trước khi đổ lỗi cho máy chủ.

Phía xa phải viết lại địa chỉ nguồn

Có một lỗi thứ hai trông giống hệt từ trình duyệt. Tuyến đi vào đường hầm, máy chủ nhận gói tin rồi chuyển tiếp chúng với địa chỉ riêng của máy khách còn nguyên vẹn. Bước nhảy tiếp theo không có đường về cho địa chỉ đó, nên các câu trả lời biến mất và trang bị treo. Máy chủ phải chuyển tiếp, và phải chuyển đổi nguồn thành thứ mà internet có thể định tuyến trở lại.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Hãy nêu tên giao diện thực sự hướng ra internet, mà trên một bản phân phối hiện đại không phải lúc nào cũng là eth0. Một máy chủ lưu trữ có địa chỉ cố định có thể chuyển đổi rõ ràng sang địa chỉ đó thay vì dùng masquerade. Cả hai nửa đều quan trọng, vì chuyển tiếp mà không chuyển đổi sẽ rò rỉ nguồn không thể định tuyến, còn chuyển đổi mà không chuyển tiếp thì không bao giờ thấy gói tin.

Phân giải tên đi theo con đường riêng

Lưu lượng có thể ra qua đường hầm trong khi truy vấn tìm ra tên đã đi đến một bộ phân giải trong mạng cục bộ. Địa chỉ nhìn thấy vẫn như cũ, các truy vấn thì không, và chính khoảng trống đó là thứ một thiết kế DNS chia tách chọn.

resolvectl status | head -20
resolvectl query example.org

Ghi nhận máy chủ nào đã trả lời và liệu nó có khác với mức cơ sở trước đường hầm không. Trong một đường hầm chia tách, đây thường là cài đặt mà mọi người muốn thay đổi khi phàn nàn về địa chỉ, và cũng là thứ họ chưa bao giờ nhìn.

Bốn quan sát kết luận vấn đề

Ghi lại địa chỉ ra khi đường hầm tắt, rồi khi bật. Chạy kiểm tra đích ở cả hai trạng thái và ghi lại giao diện mỗi lần.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Khi kiểm tra rơi vào trong đường hầm và tiếng vọng vẫn báo địa chỉ nhà cung cấp, việc chuyển đổi ở đầu ra bị thiếu. Khi kiểm tra rơi vào bộ điều hợp vật lý, hồ sơ là chọn lọc và địa chỉ công cộng chưa bao giờ nằm trong phạm vi. Thay dịch vụ vọng bằng dịch vụ bạn tin cậy và ghi lại bốn quan sát cùng nhau, vì tách riêng chúng chỉ là giai thoại. Cùng nhau, chúng cho biết máy khách thực sự đã làm việc nào trong hai việc.