Vì sao kill switch cắt lưu lượng khi bạn đổi máy chủ

Bạn chọn một máy chủ trông gần hơn, bấm kết nối, và trình duyệt ngừng tải trước khi đường hầm mới lên. Biểu tượng chuyển sang trạng thái đang kết nối và đứng yên ở đó trong khi mọi thẻ đều hết thời gian chờ. Khoảng dừng đó thường chính là kill switch đang chạy đúng thiết kế: lưu lượng bị chặn trong khi ứng dụng chưa có đường hầm để gửi nó đi. Khoảng dừng có chấp nhận được hay không phụ thuộc vào việc ứng dụng làm gì trong mấy giây đó, và vào việc khối chặn có được gỡ khi nó nói là đã gỡ hay không.

Ứng dụng làm gì giữa hai máy chủ

Đổi điểm cuối là nhiều bước, không phải một công tắc. Ứng dụng tháo đường hầm hiện tại, cập nhật các quy tắc chặn, phân giải và tiếp cận điểm cuối mới ở ngoài đường hầm, rồi cài các tuyến mới và gỡ khối chặn. Khoảng trống bạn cảm thấy nằm giữa bước đầu và bước cuối.

Thứ tự ở đây quan trọng hơn tốc độ. Nếu quy tắc chặn có hiệu lực trước ngoại lệ dành cho điểm cuối mới, ứng dụng không thể hoàn tất bắt tay và nằm ở trạng thái đang kết nối cho đến khi hết thời gian chờ. Nếu ngoại lệ là bản sao địa chỉ của máy chủ cũ, lần bắt tay mới trông giống mọi gói đi ra khác và bị loại bỏ. Hai trường hợp trông giống nhau từ trình duyệt, vì thế một lần đổi tự hồi phục sau sáu giây và một lần không bao giờ hồi phục có thể chung một nguyên nhân.

Điểm cuối mới cần một lỗ trong khối chặn

Để dựng đường hầm, ứng dụng phải gửi gói đến địa chỉ và cổng của máy chủ mới qua giao diện vật lý, ví dụ UDP 51820 với một hồ sơ WireGuard thông thường hoặc 1194 và 443 với OpenVPN, tùy hồ sơ của bạn quy định. Lưu lượng đó không nằm trong đường hầm sắp được tạo, nên một khối chặn cho toàn bộ thiết bị sẽ nuốt nó, trừ khi có quy tắc cho phép khớp.

Hồ sơ dựa trên tên máy chủ thêm điều kiện thứ hai: chính việc tra cứu. Nếu ứng dụng phân giải điểm cuối trước khi khối chặn dựng lên, nó có thể dùng địa chỉ đã lưu trong bộ nhớ đệm, nhưng khi hồ sơ xoay địa chỉ hoặc mục trong bộ nhớ đệm cũ đi, lần bắt tay đi tới một địa chỉ mà quy tắc cho phép không bao phủ. IPv6 làm điều này hiện rõ, vì một điểm cuối hai chồng có thể công bố cả bản ghi A lẫn AAAA, và một quy tắc cho phép chỉ phủ địa chỉ v4 sẽ để ứng dụng thử lại với một địa chỉ v6 đang bị chặn.

Tên tùy chọn và giá trị mặc định khác nhau tùy ứng dụng và phiên bản, nên hãy đọc danh sách đã được ghi tài liệu cho bản của bạn thay vì đoán từ ảnh chụp màn hình. Tài liệu tham chiếu cài đặt OpenVPN Connect tại openvpn.net/connect-docs/app-settings-windows là một ví dụ về cách một ứng dụng mô tả các tùy chọn chặn và chia đường hầm của nó.

Fail-closed là một máy trạng thái, không phải công tắc

Phần lớn ứng dụng diễn đạt khối chặn như một chính sách tường lửa ở ba trạng thái: đường hầm lên, lưu lượng đi qua đường hầm và không có khối chặn; đường hầm xuống, khối chặn đang hoạt động; và chuyển tiếp, khối chặn đang hoạt động kèm ngoại lệ tạm thời cho điểm cuối. Lỗi sống chính ở trạng thái thứ ba, vì nó phải đổi hai lần trong vài giây, và việc không thoát ra được trông đúng như một khối chặn vĩnh viễn.

Cơ chế khác nhau tùy nền tảng, và cả kiểu hỏng nữa. Bộ lọc của Windows Filtering Platform có trọng số, nên một bộ lọc chặn lấn át quyền cho phép của bạn vẫn tiếp tục loại bỏ gói dù quyền cho phép tồn tại, và những bộ lọc do tiến trình ứng dụng bị giết để lại có thể giữ máy ở trạng thái ngoại tuyến sau khi ứng dụng biến mất. Ứng dụng trên macOS thường ghi quy tắc pf vào một anchor, nơi thứ tự quy tắc và các quyết định nhanh quyết định quy tắc nào áp dụng. Ứng dụng trên Linux thường quản lý một chuỗi nftables hoặc iptables với chính sách drop và các quyền cho phép tường minh cho điểm cuối, giao diện đường hầm và loopback. Chế độ always-on VPN của Android với tùy chọn chặn kết nối không có VPN là chặt nhất trong nhóm, vì hệ điều hành áp khối chặn cho toàn bộ thiết bị chứ không theo từng ứng dụng.

WireGuard cần một ghi chú riêng, vì AllowedIPs là bộ chọn định tuyến, không phải bộ chặn. Nó quyết định đích nào đi vào đường hầm; nó không làm gì để ngăn một gói chưa có đường hầm ra ngoài qua Wi-Fi. Trong một cấu hình chỉ có WireGuard và không có quy tắc tường lửa, kill switch thực chất là sự thiếu vắng tuyến đường, và sau một lần bắt tay bị loại bỏ, một gói thật có thể ra ngoài qua giao diện vật lý.

Hãy đo khoảng trống thay vì nhìn biểu tượng

Theo dõi gói, không phải đèn trạng thái. Trên Linux, khởi động một lệnh ping chậm tới một địa chỉ công cộng trong một terminal và bắt cổng vận chuyển của đường hầm trên giao diện vật lý ở terminal khác:

ping -i 0.2 -c 100 1.1.1.1 | tail -5

sudo tcpdump -ni eth0 'udp port 51820'

Đổi máy chủ trong ứng dụng khi cả hai đang chạy. Ba điều quan trọng: ping dừng bao lâu, bản bắt có cho thấy lần bắt tay đến được điểm cuối mới hay không, và lưu lượng quay lại trước hay sau khi trạng thái ứng dụng chuyển sang đã kết nối. Nếu khoảng trống ping kết thúc trước, hoặc khối chặn được gỡ quá sớm hoặc đường hầm đã lên trước khi chỉ báo thừa nhận. Nếu khoảng trống kết thúc muộn hơn, chỉ báo đang lạc quan quá mức.

Trên Windows, netsh wfp show state ghi một ảnh chụp mà trong đó bạn có thể tìm các bộ lọc chặn vẫn còn tồn tại trong khi ứng dụng khẳng định đã ngắt kết nối. Trên macOS, sudo pfctl -sr liệt kê các quy tắc đã nạp và thứ tự của chúng. Ghép một trong hai ảnh chụp với nhật ký của chính ứng dụng; dòng thời gian từ ping của bạn cho biết khối chặn kết thúc muộn hay không bao giờ kết thúc.

Tối bình thường so với khối bị kẹt

Một chút gián đoạn chính là mục đích của tính năng này, nên hãy phân loại trước khi đổi bất kỳ cài đặt nào:

Nếu bạn rơi vào hàng thứ hai hoặc thứ năm, đừng tắt kill switch để thử, vì điều đó biến một lỗi định tuyến thành rò rỉ. Khởi động lại dịch vụ của ứng dụng, hoặc khởi động lại máy ở nơi bộ lọc sống sót sau khi tiến trình bị giết, rồi xem khối chặn có được dọn đi không. Nếu được dọn, lỗi nằm ở việc dọn dẹp trong lúc đổi chứ không phải ở bản thân khối chặn.

Trước lần đổi tiếp theo, hãy xác nhận bốn điều: quyền cho phép của điểm cuối bao phủ mọi họ địa chỉ mà hồ sơ của bạn phân giải, nhật ký ứng dụng cho thấy quá trình chuyển đã hoàn tất, bài kiểm tra ping của bạn đo khoảng trống chứ không phải biểu tượng, và việc thoát ứng dụng khôi phục kết nối bình thường. Một kill switch giữ được trong lúc đổi và nhả ra sau đó là đang làm tốt việc của nó. Cái nhả ra quá sớm, hoặc không bao giờ, thì đáng để gỡ lỗi.