Always-on VPN và kill switch: bạn thực sự đã bật cái nào?

Always-on và kill switch nằm cách nhau hai dòng trên cùng một màn hình cài đặt, nên người ta đọc chúng như hai tên của một tính năng. Không phải vậy. Always-on là chính sách nối lại: khởi động đường hầm khi khởi động máy, đưa nó trở lại sau sự cố hoặc khi đổi mạng, và tiếp tục thử trong khi nó thất bại. Kill switch là chính sách lưu lượng: nó nêu tên những gói tin vẫn được rời khỏi máy khi đường hầm đang tắt. Bạn có thể bật cái đầu mà không cần cái sau, và trên hầu hết nền tảng kết quả mặc định vẫn để lưu lượng lọt ra trong khoảng trống đó.

Kiểm tra 1: chặn có phải một công tắc riêng?

Trên Android 10 trở lên, một hồ sơ VPN đã lưu mở ra hai công tắc độc lập sau biểu tượng bánh răng: Always-on VPN và Block connections without VPN. Chỉ cái thứ hai là kill switch. Chỉ với always-on, đường hầm thực sự trở lại sau khi đứt, và bất kỳ ứng dụng nào đang giữa một yêu cầu đều có thể ra mạng qua Wi-Fi hoặc dữ liệu di động cho đến khi điều đó xảy ra.

Các thiết bị được quản lý giữ nguyên cách tách đó trong API chính sách. setAlwaysOnVpnPackage() nhận tên gói và cờ lockdownEnabled; một quản trị viên đặt gói rồi để cờ là false đã dựng một đường hầm thường trực, chứ không phải một thiết bị đóng. Cách diễn đạt trên bảng điều khiển hiếm khi làm lộ ra khác biệt đó.

Đọc trạng thái từ thiết bị, không phải từ bảng điều khiển: adb shell settings get global always_on_vpn_app và adb shell settings get global always_on_vpn_lockdown. Nếu lệnh đầu trả về null, không có gói nào bị áp đặt ở cấp nền tảng; nếu lệnh thứ hai trả về 0, nền tảng không chặn gì cả. Hướng dẫn VPN của Android mô tả đây là những khả năng riêng biệt, không phải một chế độ.

Kiểm tra 2: lớp nào sở hữu việc chặn?

Nhãn nằm trong ứng dụng khách còn việc chặn thường nằm trong tường lửa, vì thế cùng một từ lại mang nghĩa khác nhau trên mỗi nền tảng. Những dòng dưới đây là những dòng đáng xác nhận trước khi tin bất kỳ dòng nào.

Windows là ví dụ rõ nhất về một nhãn không hề chặn. Ở đó Always On mô tả tính bền của đường hầm: đường hầm thiết bị cho xác thực máy và đường hầm người dùng cho tài khoản đã đăng nhập, cấu hình qua XML hồ sơ hoặc Add-VpnConnection. Không có gì trong hồ sơ đó ngăn một gói tin đi ra khi thiếu đường hầm, và việc lọc chiều ra không bật theo mặc định, nên một laptop trên Wi-Fi vẫn hoạt động trong khi VPN đang tắt.

WireGuard cũng tách theo cách đó, nhưng theo ứng dụng khách. WireGuard for Windows có tùy chọn Block untunneled traffic cho từng đường hầm, tùy chọn này cài các quy tắc lọc; công cụ trên Linux không có công tắc tương đương. wg-quick thêm một tuyến cho mỗi mục AllowedIPs cùng một quy tắc fwmark, và wg-quick down gỡ cả hai, nên tuyến mặc định vật lý lại tiếp quản mà không mất một gói tin nào.

Trên các nền tảng Apple, always-on đến dưới dạng tính năng hồ sơ quản lý cho thiết bị được giám sát và được diễn đạt bằng quy tắc theo yêu cầu, không phải ô đánh dấu. Câu hỏi cần trả lời từ phần dữ liệu là liệu một đường hầm thất bại có từ chối lưu lượng hay chỉ yêu cầu một kết nối khác. Tiêu đề menu sẽ không nói cho bạn.

Kiểm tra 3: đo khoảng trống, không đo biểu tượng

Bốn bước chuyển là quan trọng, và chúng hỏng theo những cách khác nhau: khởi động trước khi ai đăng nhập, ngủ và thức, chuyển từ Wi-Fi sang dữ liệu di động, và một cú sập ứng dụng khách để giao diện đường hầm ở trạng thái cấu hình dở dang. Nối lại sạch sẽ trên một trong số đó không chứng minh gì về ba cái còn lại.

Phép thử rẻ nhất cố ý dừng đường hầm rồi thử đi ra. Khi đường hầm tắt, curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com trả về 200 nghĩa là chính sách đang fail-open; hết thời gian chờ hoặc kết nối bị từ chối nghĩa là vẫn còn thứ gì đó đang chặn. ip route get 1.1.1.1 nêu tên giao diện sẽ chở gói tin, thường cho nhiều thông tin hơn biểu tượng ở khay hệ thống, và systemctl status wg-quick@wg0 cho biết giao diện đã được gỡ sạch hay chưa.

Chạy cùng phép kiểm tra đó trong cửa sổ thứ hai khi mạng đang thay đổi, không chỉ sau khi nó đã ổn định. Khoảng thời gian giữa lúc đứt và lần thử mới là phần quan trọng, và phân giải tên là cách nhanh nhất để nhận ra lưu lượng đã lọt: nếu trình phân giải cục bộ vẫn trả lời khi đường hầm tắt, việc chặn chưa trọn vẹn.

Kiểm tra 4: quyết định ngoại lệ trước khi khóa

Hai ngoại lệ mang tính cấu trúc. Ứng dụng khách phải tới được chính máy chủ VPN, nên một bộ quy tắc bỏ tất cả cũng ngăn luôn việc nối lại vốn sẽ khôi phục bảo vệ. Cổng bắt buộc cũng không thể tới được qua một đường hầm chưa dựng, nên một thiết bị bị khóa trên Wi-Fi khách sạn cần một cách được ghi lại để mở cổng, chứ không phải cách tùy hứng.

Dạng tối thiểu, cho phép điểm cuối và bỏ mọi thứ còn lại:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

Coi dòng điểm cuối đó là biến số, không phải hằng số. Nhà cung cấp xoay địa chỉ, và một ngoại lệ cũ là lý do thường gặp khiến một kill switch đang chạy trở thành thiết bị không thể nối lại. Máy in nội bộ, chia sẻ NAS và dịch vụ phát triển thuộc cùng danh sách bằng văn bản đó, nếu không chúng sẽ lộ ra theo từng phiếu hỗ trợ một.

Kiểm tra 5: ghi lại điều bạn thực sự đã chứng minh

Giữ một bảng bốn cột và điền bằng cách thử: trạng thái, hành vi mong đợi, hành vi quan sát, bằng chứng. Các dòng là những bước chuyển từ kiểm tra 3 cộng một lỗi cố ý. Một dòng bạn không thể điền bằng đầu ra lệnh là một dòng chưa được thử, và một thiết bị qua dòng nối lại nhưng hỏng ở dòng khởi động là đủ phổ biến để đáng mười phút thêm.

Trước khi gọi là xong:

• Xác nhận thiết lập chặn tách khỏi thiết lập nối lại, và đọc giá trị của nó trên thiết bị.
• Biết lớp nào thực thi việc chặn - tùy chọn ứng dụng khách, chính sách thiết bị hay tường lửa - và lớp đó được cấu hình ở đâu.
• Giữ một lệnh kiểm tra chứng minh việc chặn, và chạy nó trong lúc chuyển tiếp chứ không phải sau đó.
• Viết danh sách ngoại lệ, kể cả điểm cuối, và ghi ai làm mới nó.
• Trên phần cứng được quản lý, để yên chính sách đang bị áp đặt; gỡ bỏ chặn là đổi yêu cầu chứ không sửa đường hầm.