Tắt IPv6 để sửa rò rỉ VPN? Hãy quyết định chính sách trước đã
Địa chỉ link-local không phải rò rỉ và tuyến IPv6 toàn cầu cũng không. Trước tiên hãy chọn giữa chặn, mang và để yên.
Một địa chỉ thuộc dải IPv6 xuất hiện trên trang kiểm tra, đường hầm rõ ràng không mang nó, và lời khuyên phổ biến nhất trên internet là tắt IPv6 ở mọi nơi. Lệnh đó thật sự làm bảng điều khiển im lặng. Nhưng nó cũng loại bỏ một giao thức mà mạng truy cập có thể phụ thuộc vào, và để bạn không biết địa chỉ đó là rò rỉ thật, địa chỉ giao diện link-local, hay một trình phân giải đang làm việc của nó. Ba điều kiện quyết định cách kiểm soát đúng, và chỉ một trong số đó dẫn đến chặn.
Xác định công cụ thực sự đã đo gì
Báo động giả phổ biến nhất là địa chỉ link-local, bắt đầu bằng fe80: và tồn tại trên mọi giao diện có khả năng IPv6, bất kể máy có truy cập internet qua IPv6 hay không. Nó xuất hiện trong danh sách giao diện và trong một số chẩn đoán ứng dụng, và không nói gì về đường đi của lưu lượng bạn.
Báo động giả thứ hai là địa chỉ cục bộ duy nhất trong fc00::/7, đây là dải riêng dùng bên trong một mạng. Một công cụ in mọi địa chỉ của máy chủ sẽ vui vẻ liệt kê nó bên cạnh địa chỉ công cộng. Ai đọc vội gọi đó là rò rỉ, rồi dành một giờ cho một vấn đề không tồn tại.
Cái thứ ba hoàn toàn không phải báo động giả. Địa chỉ toàn cầu đến được internet bên ngoài đường hầm chính là rò rỉ thật, và đáng để đo trước khi quyết định bất cứ điều gì:
ip -6 addr show scope global
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.coNếu lệnh đầu tiên in một địa chỉ toàn cầu và lệnh thứ ba trả về một địa chỉ IPv6 công cộng không phải của đường hầm, bạn có đường đi thật ra ngoài đường hầm. Nếu lệnh đầu chỉ in các mục link-local, thì chưa từng có rò rỉ nào để sửa.
Ba điều kiện quyết định cách kiểm soát
Quyết định không phải "IPv6 tốt" hay "IPv6 xấu". Đó là bạn đang ở tình huống nào trong ba tình huống, và mỗi tình huống có câu trả lời đúng khác nhau với chi phí khác nhau nếu bạn sai.
| Situation | Correct control | Cost if you disable IPv6 instead |
|---|---|---|
| Exit has no IPv6, host does | Block IPv6 deliberately in the tunnel policy | Same visible result, no documentation of intent |
| Exit carries IPv6, host leaks | Route IPv6 into the tunnel and verify | You lose IPv6 reachability entirely |
| Access network is IPv6-only | Change nothing; use the tunnel's IPv6 | Machine loses connectivity completely |
Hàng đầu tiên là điều người ta thường muốn nói, và nó chính đáng. Một máy khách có đầu ra không hỗ trợ IPv6 không nên lặng lẽ để lưu lượng IPv6 gốc của máy chủ đi ra, vì đó là rò rỉ chồng đôi đã được ghi nhận. Vấn đề là chặn nó như một chính sách được tuyên bố, không phải tắt một giao thức trong nhân. Kết quả nhìn thấy thì giống hệt và chỉ một trong hai có thể được xem lại sau này.
Hàng thứ ba là nơi lời khuyên chung trở nên thực sự có hại. Các nhà mạng di động và một số kết nối gia đình vận hành mạng IPv6-only với bản dịch cho các đích IPv4. Bỏ IPv6 ở đó là bỏ phương tiện vận chuyển duy nhất mà mạng cung cấp, điều này tạo ra sự cố tệ hơn nhiều so với cái bạn đang gỡ lỗi.
Nếu đầu ra không có IPv6, hãy chặn nó một cách có chủ đích
Ưu tiên cơ chế của chính máy khách, vì nó chỉ áp dụng đúng trong lúc đường hầm hoạt động và được hoàn lại khi đường hầm sập. OpenVPN có tùy chọn cho việc này, và iptables có quy tắc tương đương cho các máy khách khác:
block-ipv6
ip6tables -A OUTPUT -o eth0 -j REJECT --reject-with ipv6-port-unreachableChỉ thị thuộc về hồ sơ; quy tắc thuộc về một tường lửa mà bạn có thể xem lại và gỡ bỏ. Cả hai đều thất bại theo hướng đóng, đó là điều bạn muốn, và cả hai đều hiện ra trong diff cấu hình, điều mà một sysctl nhân bị chôn trong script khởi động thì không.
Ghi lại vì sao nó ở đó. Một quy tắc chặn không có chú thích sẽ bị người tiếp theo cần IPv6 cho việc khác gỡ bỏ, và rồi rò rỉ lặng lẽ quay lại.
Nếu đầu ra mang IPv6, hãy định tuyến nó và kiểm tra cả hai họ địa chỉ
Mang IPv6 là câu trả lời tốt hơn khi máy chủ hỗ trợ, và nó không khó hơn bao nhiêu. Yêu cầu là giao diện đường hầm có một địa chỉ trong họ đó và tuyến mặc định của nó trỏ vào trong đường hầm chứ không phải ra ngoài giao diện vật lý:
ip -6 route get 2606:4700:4700::1111
ip -6 route show default
curl -6 -sS --max-time 6 https://ifconfig.co
curl -4 -sS --max-time 6 https://ifconfig.coTra cứu tuyến là phép thử quyết định: nếu nó nêu tên giao diện đường hầm, lưu lượng IPv6 đang được mang. Hai lệnh gọi curl sau đó xác nhận mỗi họ thấy gì, và so sánh chúng là cách chứng minh cả hai đường đi nay ra cùng một đầu ra.
Đừng dừng ở một kết nối thành công. Kết nối lại đường hầm và kiểm tra lần nữa, vì một tuyến IPv6 được đẩy có thể mất khi thiết lập lại nếu máy chủ chỉ gửi nó trong cấu hình ban đầu. Sau đó kiểm tra một đích bị loại trừ, vì các quy tắc đường hầm chia tách là nơi hai họ thường bất đồng nhất.
Nếu mạng truy cập chỉ có IPv6, hãy để yên
Một số mạng chỉ cung cấp IPv6 và mong thiết bị đến được các dịch vụ IPv4 qua cơ chế dịch ở phía nhà mạng. Tắt IPv6 trên một máy như vậy không phải là cải thiện bảo mật; nó loại bỏ con đường duy nhất đến bất cứ thứ gì. Đó là sự cố tự gây ra để đổi lấy một kết quả kiểm tra mà không ai cần.
Triệu chứng của việc làm sai ở đây rất đặc trưng và khó chịu: đường hầm có vẻ được thiết lập, phân giải tên hoạt động, và không có gì tải được. Nếu bạn thấy điều đó sau một thay đổi IPv6, hãy khôi phục cài đặt ngay và tiếp tục chẩn đoán ở nơi khác.
Dù bạn chọn gì, hãy giữ quyết định rõ ràng trong hồ sơ hoặc tường lửa, gắn nó với điều mà đầu ra thực sự hỗ trợ, và ghi lại hành vi chồng đôi mà cuộc thảo luận về chồng đôi của RFC 7359 mô tả. Một sự chặn được tuyên bố là chính sách. Một giao thức bị tắt là lối vòng mà không ai kiểm toán được, và từ trang kiểm tra chúng trông giống hệt nhau.