Đặt lại TCP không chứng minh VPN của bạn đang bị chặn

«Kết nối bị đặt lại, đang khởi động lại» xuất hiện trong nhật ký máy khách, và kết luận đến trước bằng chứng. Ai đó quyết định rằng mạng đang chặn VPN, hoặc chứng chỉ sai, hoặc một quốc gia cụ thể đang can thiệp. Đặt lại là một gói TCP kết thúc kết nối, và dòng nhật ký ghi rằng máy khách của bạn đã nhận một gói. Nó không nêu tên thiết bị đã gửi hay lý do.

Đặt lại là một gói, không phải phán quyết

TCP định nghĩa cách xử lý đặt lại: một đoạn có cờ RST kết thúc kết nối ngay lập tức. Bên nhận không thương lượng, không thử lại và không hỏi tại sao. Nó báo cáo việc đặt lại rồi tiếp tục.

Đó là tất cả những gì máy khách biết. RST có thể đến từ máy chủ, một proxy, một tường lửa hoặc một bộ cân bằng tải đã mất trạng thái.

Việc quy nguồn gốc là một bài tập riêng. Địa chỉ nguồn trông thấy trong bản ghi không phải bằng chứng về nguồn gốc vật lý và không nói gì về quyết định chính sách phía sau. Các thiết bị trung gian có thể giả mạo địa chỉ, và thiết bị có trạng thái có thể đặt lại do hết thời gian chứ không phải do ý định. Coi việc đặt lại là phán quyết sẽ bỏ qua phần bạn tìm ra sự thật.

Xác nhận kết nối nào đã bị đặt lại

Trước tiên hãy kiểm tra hồ sơ đang hoạt động có thực sự dùng TCP không. Đặt lại trên một đường hầm UDP không có nghĩa lý, và nhật ký từ một proxy HTTP có thể liên quan đến một chặng TCP khác với chính VPN.

Ghi lại đích đến, cổng, thời điểm thử và giai đoạn mà máy khách đã đạt tới.

Giai đoạn là trường hữu ích nhất. Đặt lại trong lúc bắt tay TLS chỉ vào một nhóm nghi vấn; đặt lại sau khi xác thực chỉ vào nhóm khác. Không có giai đoạn, mọi giả thuyết đều khớp.

So sánh hai đầu của đường đi

Nếu bạn quản trị máy chủ, hãy so sánh các sự kiện của nó cho cùng lần thử. Nó có chấp nhận kết nối không? Nó có đóng nó một cách có chủ ý không? Một phản hồi có rời một ranh giới và không bao giờ đến ranh giới tiếp theo không?

Bắt gói ở máy khách và ở máy chủ nếu có thể. Một lần đặt lại xuất hiện ở máy khách nhưng không ở máy chủ thì không bắt nguồn từ máy chủ.

Chú ý các đoạn RST ở cả hai chiều:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Thu hẹp bằng một so sánh có kiểm soát

Một mạng thứ hai đã được phê duyệt có thể cho bạn biết lỗi đi theo máy khách hay theo đường đi. Nếu cùng hồ sơ hoạt động ở nơi khác, cấu hình máy khách có lẽ ổn và biến số là đường đi.

Điều đó vẫn chưa xác định một thiết bị trung gian cụ thể. Nó thu hẹp phạm vi về một tuyến, đó là kết quả hữu ích và trung thực.

Giữ sự phân biệt giữa «đường này thất bại» và «tác nhân được nêu tên này đã gây ra nó». Điều đầu có thể kiểm chứng; điều sau thường không thể từ một máy khách.

Kiểm tra bản sửa mà không thay đổi cài đặt tin cậy

Đừng tắt xác minh TLS, đừng tạo lại thông tin đăng nhập và đừng công bố chính sách chặn từ một dòng đặt lại. Mỗi thay đổi đó đều thay đổi hệ thống đang được kiểm tra và khiến lần so sánh tiếp theo vô nghĩa.

Sửa thành phần đã xác định thông qua chủ sở hữu của nó, sau đó lặp lại cùng hồ sơ và cùng quan sát:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Kết quả hữu ích là một lỗi được định vị tốt hơn, không phải một câu chuyện tự tin hơn. Nếu lần đặt lại biến mất sau khi sửa proxy, bạn có nguyên nhân. Nếu nó chuyển sang giai đoạn khác, bạn đã học được điều gì đó về đường đi. Dù thế nào, bằng chứng phải chịu được việc người thứ hai đọc. Hãy viết điều bạn quan sát, không phải điều bạn kết luận.