Công tắc an toàn chỉ chặn IPv4: vì sao IPv6 vẫn thoát ra

Đường hầm sập, công tắc an toàn báo rằng nó đã kích hoạt, và một bản tải xuống vẫn tiếp tục. Không có gì hỏng trong các quy tắc IPv4. Ứng dụng chỉ đơn giản chuyển sang một đường đi mà các quy tắc đó chưa bao giờ được viết cho.

Các thiết bị hai ngăn xếp có hai lối ra độc lập. Chặn một trong số chúng là chặn một nửa.

Hai bộ quy tắc, hai mặc định

Trên Linux, iptables và ip6tables là hai bảng riêng với chính sách riêng. Đặt các chuỗi INPUT và OUTPUT của bảng IPv4 thành DROP không thay đổi gì trong bảng IPv6, nơi mặc định thường là ACCEPT. Cách chia tách tương tự cũng tồn tại trong nftables, nơi bạn có thể kiểm tra một họ và thấy rằng chỉ một trong số chúng mang các quy tắc của bạn. Sự bất đối xứng đó là bình thường, và đó là toàn bộ vấn đề.

Đó là lý do một công tắc an toàn có thể trông đầy đủ mà lại hành xử một phần. Tập lệnh đã ghi các quy tắc IPv4 đã chạy, các bộ đếm tăng lên, dòng nhật ký xuất hiện, và một gói IPv6 rời khỏi giao diện vật lý hoàn toàn không bị chạm tới.

Hãy đọc những gì máy khách của bạn thực sự cài đặt, không phải những gì trang tiếp thị hứa hẹn. Một số máy khách định tuyến IPv6 vào đường hầm, một số cố ý chặn nó, và một số để yên nó trong khi khóa ở cấp nền tảng áp dụng một quy tắc khác. Tài liệu của nhà cung cấp là nguồn duy nhất đáng tin ở đây.

Cấu hình giao diện cho bạn biết điều gì

Trang hướng dẫn của wg-quick bao gồm các quy tắc IPv6 trong cấu hình ví dụ, và lý do chính là khoảng trống này. Ví dụ không phải đồ trang trí. Nó tồn tại vì chỉ các quy tắc IPv4 sẽ để họ thứ hai mở.

Sao chép một nửa ví dụ tạo ra một nửa chính sách. Đây là nguồn gốc phổ biến nhất của rò rỉ này. Một bài đăng blog đã rút ngắn ví dụ vì độ dài. Phiên bản rút gọn sau đó trở thành mẫu mà mọi người dùng lại.

# what is actually installed, per family?
sudo iptables -S OUTPUT | head -20
sudo ip6tables -S OUTPUT | head -20

# nftables: inspect each family separately
sudo nft list ruleset inet | head -40

# does this host even have a usable IPv6 path?
ip -6 route show default

Nếu lệnh thứ hai in ra một chính sách cho phép trong khi lệnh thứ nhất in ra DROP, bạn đã tìm ra câu trả lời mà không cần chạm vào máy khách. Sự bất đối xứng đó là lỗi.

Vì sao một lần tra cứu không phải toàn bộ câu chuyện

Một tên có thể trả về cả bản ghi A và bản ghi AAAA, và các ứng dụng không phải đều chọn giống nhau. Trình duyệt có thể ưu tiên IPv6 khi mạng cung cấp và quay lại khi thất bại, trong khi đồng bộ nền hoặc trình cập nhật dùng trình phân giải và sở thích riêng của nó. Vì vậy một bài kiểm tra thành công qua IPv4 chứng minh một đường đi, không phải chính sách.

Các chuyển đổi mạng cũng thay đổi câu trả lời. Tham gia một mạng Wi-Fi khác, thức dậy từ chế độ ngủ hoặc chuyển sang mạng di động có thể cấp cho thiết bị một tiền tố IPv6 mới, và chính sách trông có vẻ đủ ở LAN văn phòng có thể không bao phủ nó.

Kiểm tra trạng thái khi đường hầm tắt

Kiểm tra khi đang kết nối cho bạn biết đường hầm hoạt động. Bài kiểm tra thú vị là trạng thái không khả dụng, vì đó là lúc công tắc an toàn phải giữ. Dừng đường hầm một cách có chủ đích, sau đó thử các đích quan trọng từ ứng dụng bạn đang bảo vệ.

# with the tunnel stopped, does anything still leave?
ip -6 route get 2606:4700:4700::1111
curl -6 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv6.example.net/
curl -4 -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://ipv4.example.net/

Cả hai họ đều phải thất bại theo hướng đóng. Nếu yêu cầu IPv4 hết thời gian và yêu cầu IPv6 trả về mã trạng thái, chính sách chưa đầy đủ, và dù kiểm tra lại đường hầm bao nhiêu lần cũng không thay đổi điều đó.

Hãy giữ cả các ngoại lệ đã được ghi lại trong bài kiểm tra đó. Khám phá mạng cục bộ, gia hạn DHCP hoặc đường khởi động tới điểm cuối VPN có thể cần vẫn truy cập được, và những ngoại lệ đó nên được nêu tên trong chính sách thay vì bị phát hiện trong một sự cố. Một bài kiểm tra rò rỉ thất bại vì đường hầm không thể trở lại không phải là phát hiện bảo mật, mà là phát hiện kết nối.