Lưu lượng có thực sự đi qua VPN? Cách kiểm chứng

Hai sự cố trông giống nhau từ biểu tượng khay hệ thống: lưu lượng đi vào đường hầm và lưu lượng lặng lẽ đi vòng qua nó. Ứng dụng hiển thị Connected trong cả hai trường hợp, vì Connected chỉ có nghĩa là giao diện đường hầm tồn tại và ứng dụng đã cài những tuyến nó muốn. Việc một gói của một ứng dụng có dùng những tuyến đó hay không là câu hỏi riêng, được trả lời ở chỗ khác trong chồng giao thức. Bốn phép đo giải quyết phần lớn — tra cứu tuyến, chặng đầu tiên, bắt gói trên card mạng vật lý và quan sát từ bên ngoài — còn góc nhìn phiên trên máy chủ bao phần còn lại.

Bắt đầu từ tuyến mà gói sẽ đi

Bảng định tuyến chính là quyết định, nên hãy hỏi nó về một đích thay vì đọc toàn bộ rồi đoán. Trên Linux, ip route get nêu giao diện và địa chỉ nguồn mà nhân đã chọn:

ip route get 203.0.113.10
ip route get 10.20.5.7

Trên Windows, Find-NetRoute -RemoteIPAddress 203.0.113.10 hữu ích hơn route print -4 vì cùng lý do: nó báo tuyến đã thắng, không báo mọi tuyến đang có. Dù vậy hãy đọc bảng một lần vì dòng 0.0.0.0. Một cặp /1 ở đó nghĩa là ứng dụng đường hầm đầy đủ đã viết lại tuyến mặc định: tùy chọn redirect-gateway def1 của OpenVPN cài 0.0.0.0/1 và 128.0.0.0/1 qua đường hầm, điều này thắng 0.0.0.0/0 đang có ở mức khớp tiền tố dài nhất mà không xóa tuyến mặc định vật lý. Vì thế hai tuyến mặc định có thể cùng tồn tại trong khi mọi thứ vẫn đi vào đường hầm.

Hai chi tiết làm bảng nói dối. Thứ nhất, hãy nhìn tiền tố đã khớp chứ không phải số tuyến mặc định, vì metric giao diện hoặc một cặp /1 quyết định bên thắng. Thứ hai, một kết nối đã tồn tại giữ nguyên đường đi mà nó được thiết lập; sau khi đường hầm lên, một phiên đang mở có thể tiếp tục dùng tuyến cũ cho tới khi bị đặt lại, và đó là lý do kết nối lại có vẻ đã sửa được sự cố định tuyến. Một ứng dụng đang chạy — ps ax | grep openvpn — chỉ chứng minh tiến trình đã khởi động.

Theo dõi một tên nội bộ và một tên công cộng

Tra cứu tuyến cho thấy ý định; đường đi cho thấy việc giao hàng. Khi đang kết nối, hãy theo dõi một tên buộc phải nội bộ và một tên không được như vậy, rồi so sánh chặng đầu tiên:

traceroute intranet.corp.example
traceroute 1.1.1.1

Cùng một chặng đầu tiên cho cả hai nghĩa là tên nội bộ chưa bao giờ vào đường hầm và lỗi nằm ở phía trên nó, thường là một tên phân giải ra địa chỉ công cộng hoặc một tuyến chưa bao giờ được cài. Nếu lưu lượng nội bộ đi ra qua 10.8.0.1 trong khi lưu lượng công cộng đi ra qua 192.168.1.1, đường hầm chia tách đang làm đúng việc nó được cấu hình để làm. Một vết đi tới cổng VPN rồi chỉ trả về hết thời gian chờ thường là sự cố đường về hoặc tường lửa máy chủ, không phải tuyến chuyển tiếp bị thiếu.

ICMP bị lọc làm phép kiểm tra này nói dối: các dấu sao trên cả hai vết trông như đường hầm chết và thường là tường lửa. Hãy thử một cổng TCP ở nơi có thể — traceroute -T -p 443 trên Linux — và nhớ rằng vết không cho biết bộ phân giải nào đã trả lời: một tên có thể phân giải cục bộ mà vẫn tới được qua đường hầm.

Hãy bắt gói trên card mạng vật lý, không phải trên đường hầm

Liên kết vật lý là nơi duy nhất cho thấy mạng thực sự nhìn thấy gì. Khi đường hầm đã lên, một phiên tới văn phòng phải hiện ra như tải trọng được mã hóa gửi tới máy chủ VPN, không phải như một kết nối tới 10.20.5.7:

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

Bộ lọc thứ nhất bắt việc phân giải tên đi ra cục bộ, đây là rò rỉ phổ biến nhất và im lặng nhất — trang vẫn tải được, bộ phân giải chỉ thấy truy vấn. Bộ lọc thứ hai bắt lưu lượng thường đi tới một địa chỉ nội bộ chỉ nên tồn tại bên trong đường hầm. Trên Windows, pktmon làm việc đó mà không cần trình điều khiển: pktmon filter add -p 53, rồi pktmon start --capture --pkt-size 128, rồi pktmon stop và pktmon format pktmon.etl -o capture.txt. Các cờ này khác nhau chút ít giữa các bản Windows, nên hãy kiểm tra pktmon filter add /? trước khi tin cú pháp.

Hãy bắt gói trên giao diện vật lý để tìm rò rỉ; bắt gói trên đường hầm chứa đúng những gói bạn đã tin là ở đó, còn trên máy chủ nó chứa các gói ngoài không đọc được mà nguồn là cổng. Bộ đếm byte trên bất kỳ giao diện nào mô tả gói, không mô tả chương trình; để quy lưu lượng cho một tiến trình cần một bộ giám sát ánh xạ socket sang tiến trình.

Hỏi một dịch vụ bên ngoài, rồi hỏi lại theo từng ứng dụng

Phép kiểm tra duy nhất chứng minh lối ra là một câu trả lời từ bên ngoài: một dịch vụ trả lại địa chỉ nguồn mà nó đã thấy. Hãy chạy nó từ một shell, nơi bạn chọn được giao diện, và chạy hai lần:

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

Câu trả lời khác nhau cho bạn bằng chứng về cả hai đường và cách thử một ứng dụng cụ thể: gắn nó vào giao diện, hoặc chạy nó trong một không gian tên mạng chỉ có một tuyến, rồi xem đầu xa ghi nhận địa chỉ nào. Câu trả lời giống nhau mới là sự cố đáng chú ý: hoặc việc gắn không có tác dụng, hoặc có gì đó giữa máy chủ và đầu xa viết lại địa chỉ nguồn trước khi gói tới. Trên Windows, curl --interface cần địa chỉ của card mạng chứ không phải tên.

Một trình duyệt báo địa chỉ VPN chỉ chứng minh trình duyệt đó. Ứng dụng thư, trình quản lý gói, tác nhân sao lưu hay một hồ sơ trình duyệt thứ hai đều có thể đi đường khác, nhất là khi một thiết lập proxy hoặc một tuyến của đường hầm chia tách phủ lên một trong số đó. Địa chỉ thay đổi tự nó không phải bằng chứng rò rỉ: bộ cân bằng tải có thể trả lời khác nhau tùy lối ra nó thấy, nên hãy so địa chỉ nguồn được ghi lại, không so trang.

Dùng góc nhìn máy chủ để xác nhận đầu bên kia

Máy chủ trả lời một câu hỏi khác: đầu bên kia có đang kết nối không, đã chở bao nhiêu và phiên có khởi động lại không. Đầu bên kia đang sống trên máy chủ trong khi bộ đếm của ứng dụng gần như không nhích nghĩa là lưu lượng ứng dụng không vào đường hầm, bất kể bảng định tuyến của ứng dụng nói gì. Còn một đầu bên kia chuyển nhiều dữ liệu cho người dùng báo rằng không có gì chạy là một cuộc điều tra khác.

Có hai cái bẫy ở đây. Một đường hầm được che giấu làm mọi luồng trông như đến từ cổng, nên nhật ký và việc tính cước theo từng ứng dụng đều dồn vào một địa chỉ. Và ứng dụng được coi là máy chủ cục bộ, nên câu hỏi ai đó có đang sao chép tệp qua VPN được trả lời bằng lưu lượng chia sẻ tệp trên máy chủ hoặc bằng kiểm toán máy chủ trên máy chủ — quan sát đường hầm cho điểm cuối và khối lượng, không cho tên tệp.

Phân biệt một quyết định thiết kế với một rò rỉ

Không phải mọi thứ ngoài đường hầm đều là rò rỉ. Lưu lượng liên kết cục bộ và quảng bá vẫn ở cục bộ theo thiết kế, một máy in tìm thấy qua multicast tiếp tục quảng bá trong LAN, và DHCP buộc phải đi ra cục bộ. Một ứng dụng gắn vào giao diện cụ thể cố ý bỏ qua bảng định tuyến, và chỉ một quy tắc tường lửa, một không gian tên hay một tuyến chính sách mới thay đổi được điều đó.

IPv6 xứng đáng có dòng riêng trong danh sách kiểm tra. Một đường hầm chỉ chở IPv4 để lại cho máy chủ hai chồng một đường thứ hai dùng được, và một đích hai chồng sẽ thích nó hơn — kể cả DNS, nếu bộ phân giải tới được qua IPv6. Hãy tắt IPv6 trên card mạng hoặc xác nhận đường hầm chở nó trước khi coi một kết quả IPv4 là đầy đủ.

Khi các phép kiểm tra không khớp nhau, chính chỗ không khớp thường gọi tên sự cố:

Một trình tự hiệu quả: lưu bảng định tuyến trước và sau khi kết nối, theo dõi một tên nội bộ và một tên công cộng, bắt DNS trên card mạng vật lý, trả lại địa chỉ lối ra từ shell cho ứng dụng cụ thể, rồi đọc máy chủ để xem khối lượng. Nếu bốn bước đầu khớp nhau, đường hầm đang chở đúng thứ bạn nghĩ và sự cố còn lại nằm ở phía trên. Nếu hai trong số đó không khớp, cặp không khớp chính là sự cố chứ không phải biểu tượng.