Kill switch sau khi chuyển từ Wi-Fi sang mạng di động: cái gì vỡ

Một lúc nào đó máy tính xách tay đang ở Wi-Fi của văn phòng, khoảnh khắc sau nó được gắn vào điện thoại, và đèn chỉ báo đường hầm lại xanh trước khi bạn chuyển xong cửa sổ. Đèn xanh chỉ báo rằng đường hầm đã kết nối lại; chính sách định tuyến và chặn đã làm gì trong khoảng trống đó là câu hỏi khác. Chính sách ấy là một tập điều kiện khớp được biên dịch ở lần cài đặt cuối, và nó nêu tên một giao diện, một địa chỉ và một họ địa chỉ mà quá trình chuyển đổi vừa gỡ bỏ. Vì vậy cùng một lần chuyển cho ra ba kết cục trông giống hệt nhau: chặn vẫn tiếp tục, chính sách tự chặn việc phục hồi của chính nó, hoặc một đường đi mở ra mà không gì bao phủ.

Không có gì trên màn hình phân biệt ba trạng thái đó, nên hãy hỏi các quy tắc được ghim vào định danh nào thay vì đèn báo hiện màu gì. Trên Linux một quy tắc có thể nêu tên một giao diện hoặc một ipset được nạp từ nó; trên Android có thể bảo một VpnService theo dõi những mạng nền nào thông qua setUnderlyingNetworks. Mỗi ràng buộc trỏ tới một liên kết sắp bị thay thế, và mỗi cái phải được đánh giá lại sau đó.

Quá trình chuyển thực sự ghi lại điều gì

Khi liên kết cũ biến mất, nhân hệ điều hành gỡ các địa chỉ của nó, thu hồi các tuyến đi qua nó và dựng lại việc chọn địa chỉ nguồn từ phần còn lại. Tuyến mặc định chuyển sang cổng mới, và chỉ số giao diện mà các quy tắc cũ tham chiếu đã mất hoặc được tái sử dụng cho thiết bị khác. Bộ phân giải theo từng liên kết cũng được làm mới, tuy không cùng thời điểm với các tuyến. Tất cả điều này diễn ra bên dưới ứng dụng khách VPN, nên một ứng dụng chỉ theo dõi trạng thái đường hầm của chính nó không thấy gì cả.

Vấn đề là một quy tắc mã hóa một định danh cụ thể thay vì ý định đằng sau nó. Quy tắc bỏ mọi thứ không đi ra qua giao diện đường hầm mã hóa một tên giao diện; quy tắc cho phép điểm cuối mã hóa một địa chỉ mà mạng mới có thể định tuyến đi nơi khác. Khi định danh biến mất, quy tắc không trở nên sai một cách rõ ràng: nó hoặc ngừng khớp với bất cứ thứ gì hoặc bắt đầu khớp với thứ sai.

Dựng lại đường hầm bên ngoài mà không đục lỗ

Vận chuyển bên ngoài đã gắn với địa chỉ nguồn cũ, nên nó phải mở một socket mới từ địa chỉ mới. Khi điểm cuối là tên máy chủ chứ không phải địa chỉ theo nghĩa đen, một lần tra cứu phải thành công trong khi chặn vẫn còn hiệu lực. Đây là bẫy thứ tự: một chính sách đủ nghiêm để bỏ mọi thứ trừ điểm cuối cũng sẽ bỏ luôn lần tra cứu cần để tìm ra nó, trừ khi việc phân giải diễn ra trước khi dỡ chặn hoặc được chở qua một đường hầm còn sống. Cả hai thứ tự đều có thể chạy được, nhưng chỉ khi ứng dụng biết mình đang ở thứ tự nào.

Các ứng dụng khác nhau ở đây theo cách quan trọng khi chẩn đoán. Một số phân giải trước rồi mới cài quy tắc, nên một lần chuyển tốn một gián đoạn thấy được rồi tự hồi phục; số khác giữ chặn và dựa vào đường hầm còn sống để chở lần tra cứu, điều này thất bại hoàn toàn khi đường hầm chết cùng liên kết. Thêm một tuyến mặc định trực tiếp rộng để khôi phục kết nối luôn làm bài kiểm tra đạt và luôn để lại rò rỉ mà bạn đang ngăn.

Một tuyến vẫn trỏ tới cổng cũ cho cùng kiểu phục hồi kẹt do nguyên nhân khác, nên hãy đọc bảng trước khi đổ lỗi cho ứng dụng. Các lệnh dưới đây nêu tên giao diện và địa chỉ nguồn mà nhân thực sự dùng, và điều đó quyết định trong một dòng liệu đường cũ còn được cài hay không.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Khi liên kết mới mang IPv6 còn quy tắc thì không

Mạng di động và mạng khách thường cấp một tiền tố IPv6 toàn cầu ngay cả khi LAN có dây của văn phòng chưa bao giờ làm vậy. Một chính sách chỉ viết dưới dạng quy tắc IPv4, hình dạng mặc định của phần lớn công thức iptables và nftables làm tay, không bao phủ gì trong số đó. Đường hầm vẫn kết nối, các ứng dụng có khả năng tiếp cận IPv6 đi ra ngoài nó, và đèn báo không thể hiện khác biệt vì đường hầm thực sự đang lên. Trường hợp ngược lại cũng phổ biến không kém: một bộ quy tắc chỉ cho IPv6 không làm gì trên mạng không cung cấp v6.

So sánh điều liên kết cung cấp với điều chính sách nêu ra, ở cả hai phía của lần chuyển. Các lệnh này in ra đúng những dữ kiện mà ứng dụng đang dùng:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Nếu lệnh thứ hai in ra một tuyến mặc định trong khi lệnh thứ ba trả về không, liên kết mới có thể đưa máy ra ngoài qua IPv6 mà không quy tắc nào canh chừng. Chạy lại cả ba sau khi chuyển, vì con số thú vị là hiệu giữa hai lần chạy. Nếu lệnh thứ hai không in gì, trường hợp ngược lại áp dụng và mọi chính sách nặng về v6 ở đó chỉ là trang trí.

Bộ phân giải đổi tay giữa phiên

Trên các hệ thống hiện đại bộ phân giải gắn với liên kết, nên một liên kết mới đến với một bộ bộ phân giải mới và có thể là một góc nhìn split-DNS khác. systemd-resolved giữ một phạm vi cho mỗi liên kết và chọn giữa chúng theo tuyến, còn macOS đọc các bộ phân giải có phạm vi từ kho động và tôn trọng thứ tự giao diện. Một ứng dụng cài bộ phân giải riêng của mình cạnh tranh với bộ phân giải của liên kết, và các quy tắc ưu tiên mà không ai để ý quyết định người thắng. Khi đó việc phân giải tên có thể vỡ trong khi lọc gói tin làm đúng điều nó được viết ra để làm.

Đọc bộ phân giải đang hoạt động chứ không phải bộ đã cấu hình. Trên máy chủ systemd, lệnh con status cho thấy mỗi phạm vi đến từ liên kết nào và liệu một tên private-DNS có hiệu lực:

resolvectl status --no-pager
resolvectl query intranet.example.com

Nếu truy vấn đi ra qua liên kết vật lý thay vì qua đường hầm, ứng dụng đã thua cuộc đua ưu tiên và không chỉnh sửa tường lửa nào sửa được việc đặt tên. So sánh đường đi của truy vấn ở cả hai phía của lần chuyển để xem cái nào đã dịch chuyển. Một tên phân giải thành địa chỉ riêng mà mạng mới không thể định tuyến là trường hợp thứ ba, và nó hiện ra như hết thời gian chứ không như lỗi.

Luyện tập lần chuyển và giữ bản ghi

Tái tạo thay đổi một cách có chủ ý thay vì chờ nó. Dựng đường hầm trên liên kết đầu, bắt đầu một lần truyền dài và một lần tra cứu lặp lại, rồi chuyển liên kết và xem cái nào sống sót. Ghi lại khoảng giữa lúc liên kết cũ biến mất và lúc đường hầm báo đã kết nối, vì chính trong cửa sổ đó chính sách đã trụ hoặc không. Chạy trình tự theo chiều ngược lại nữa, để kết quả không một chiều.

Các ngoại lệ cần lượt riêng, vì một đường vòng hợp lý trên mạng cũ không tự động hợp lý trên mạng mới. Máy in, NAS hay cổng bắt giữ trên LAN nhà không có tương đương trên mạng di động, và ngoại lệ từng đến được chúng trở thành quy tắc không có tương đương.

Ghi lại tên giao diện, các họ địa chỉ được cấp, bộ phân giải đang hiệu lực và độ dài gián đoạn cho từng chiều. Việc kết nối lại chứng minh vận chuyển đã hồi phục, không phải rằng chặn đã trụ trong khoảng trống, và đó là những tuyên bố riêng để đưa vào phiếu. Với bản ghi đó, lần chuyển tiếp theo được so với một trạng thái đã biết chứ không phải với trí nhớ.