Lưu lượng IPv6 nên đi qua VPN hay đi trực tiếp?

Tháng trước hai người đã yêu cầu tôi những kết quả trái ngược: một người muốn IPv6 được VPN bao phủ, người kia muốn máy in văn phòng tiếp tục hoạt động. Một tuyến ::/0 duy nhất không thể tự mình cung cấp cả hai. Tuyến đó có thuộc bên trong đường hầm hay không phụ thuộc vào ba điều kiện, và điều kiện đầu tiên loại trừ nó với hầu hết đầu ra thương mại. Nếu đầu ra không mang IPv6, việc chuyển tuyến mặc định vào đó sẽ giấu lưu lượng của bạn trong một đường hầm không có nơi nào để gửi.

Ba điều kiện quyết định câu trả lời

Tuyến mặc định là một dòng, ::/0, và nó khớp với mọi đích IPv6 không có tuyến cụ thể hơn (RFC 4291). Cài đặt nó rất dễ. Quyết định có nên làm hay không quy về ba điều kiện.

Điều kiện một: đầu ra bạn kết nối có IPv6 hoạt động và sẵn sàng chuyển tiếp nó. Điều kiện hai: máy khách của bạn có thể giữ đường dẫn đến điểm cuối của đường hầm, thường nằm trong dải bạn sắp định tuyến. Điều kiện ba: bạn có thể kể tên các đích IPv6 cục bộ phải ở ngoài đường hầm.

Mỗi điều kiện hỏng theo cách riêng, vì vậy đoán mò tốn cả một buổi tối. Điều kiện một hỏng cho bạn sự im lặng và một bảng tuyến trông có vẻ đúng. Điều kiện hai hỏng giết chết bắt tay vài giây sau khi bắt đầu. Điều kiện ba hỏng để lại một đường hầm hoạt động và một đồng nghiệp không vui bên máy in.

Đầu ra có thực sự mang IPv6 không?

Một giao diện đường hầm có địa chỉ IPv6 không chứng minh gì về phía bên kia. Nhiều hồ sơ thương mại chỉ có IPv4 bên trong: máy chủ cho bạn một địa chỉ v4 và bỏ mọi thứ khác. Cài thêm một tuyến mặc định từ AllowedIPs lên trên và nhân sẽ sẵn lòng gửi IPv6 vào một giao diện mà đối tác của nó không bao giờ thấy.

Kiểm tra từ máy khách khi đường hầm đang hoạt động. ping -6 -c 3 2001:4860:4860::8888 và ip -6 route get 2001:4860:4860::8888 trả lời những câu hỏi khác nhau: liệu có phản hồi trở lại, và nhân đã chọn thiết bị nào. Khi cái thứ hai nêu tên đường hầm của bạn còn cái thứ nhất không trả về gì, vấn đề là ở đầu ra, không phải tuyến.

Nếu bạn tự vận hành đầu ra, bài kiểm tra máy khách có thể qua và đường đi vẫn kết thúc ở ngõ cụt. Xác nhận net.ipv6.conf.all.forwarding=1 được bật trên cổng và tường lửa của nó chấp nhận các gói được chuyển ra khỏi đường hầm. Một gói được định tuyến đúng vào đầu ra từ chối chuyển tiếp trông đúng như một lỗi định tuyến từ phía máy khách.

Máy khách có giữ được đường dẫn đến điểm cuối không?

Đây là trường hợp đã bắt được tôi trên một laptop có điểm cuối WireGuard chỉ IPv6. Địa chỉ điểm cuối là một địa chỉ toàn cầu thông thường, nên nó nằm trong ::/0. Định tuyến toàn bộ tiền tố vào giao diện và các gói bắt tay sẽ tự đuổi nhau vào đường hầm mà chúng vẫn đang cố xây. Đường hầm không bao giờ lên, và không có gì trong đầu ra của máy khách nói tại sao.

wg-quick xử lý việc này trên Linux. Nó rút ra các tuyến từ AllowedIPs, cài chúng vào bảng riêng và thêm một quy tắc chính sách để lưu lượng đến điểm cuối được giải quyết trước qua bảng chính: quy tắc suppress_prefixlength 0 mà bạn tìm thấy trong ip -6 rule. Đó là lý do wg-quick up thành công ở nơi một ip -6 route add default dev wg0 viết tay cắt đứt bạn.

Kiểm tra cả hai trạng thái bằng ip -6 route get <endpoint-v6>, trước và sau khi dựng đường hầm. Nếu câu trả lời chuyển sang thiết bị đường hầm của bạn, bạn đã xóa con đường mà đường hầm cần. Khi bạn tự viết các tuyến, hãy thêm một tuyến máy chủ đến điểm cuối qua cổng gốc, hoặc kết nối đến điểm cuối qua IPv4 và để IPv6 cho tải trọng.

Điều gì phải ở ngoài đường hầm?

Các tuyến cụ thể hơn đánh bại tuyến mặc định, nên một tiền tố trên liên kết hoặc một dải ULA có tuyến riêng vẫn tiếp tục hoạt động mà không cần thêm công sức. Đây là lý do thầm lặng khiến nhiều cấu hình IPv4 đường hầm đầy đủ tồn tại: các tiền tố LAN cụ thể hơn tuyến mặc định và không bao giờ vào đường hầm.

Nó vỡ khi một thiết bị cục bộ có thể tiếp cận qua địa chỉ toàn cầu, điều này bình thường với máy in được cùng router cấp tiền tố công khai, NAS hoặc tivi. Những địa chỉ đó khớp với ::/0 và không gì khác, nên chúng chuyển vào đường hầm cùng mọi thứ khác và biến mất.

Quyết định theo đích, không theo giao thức. Nếu hai hoặc ba máy chủ cục bộ quan trọng, hãy cho tiền tố của chúng một tuyến ra ngoài qua giao diện vật lý, hoặc bỏ chúng khỏi tập đã thương lượng. Nếu danh sách tiếp tục tăng, câu trả lời trung thực là chia đường hầm cho IPv6 với một danh sách ngoại lệ bằng văn bản, không phải một tuyến mặc định mà bạn cứ vá mãi.

Nếu câu trả lời là không, hãy chặn nó

Để IPv6 không có tuyến không giống như để yên nó. Một máy chủ có tuyến mặc định IPv6 hoạt động tiếp tục dùng nó trong khi đường hầm mang IPv4, nên lưu lượng đi ra bên cạnh VPN và mọi dịch vụ ưu tiên IPv6 đều thấy địa chỉ thật của bạn. Đó là rò rỉ, không phải đường hầm chia.

Chọn một và ghi lại bạn đã chọn cái nào. Định tuyến tuyến mặc định và chấp nhận các đánh đổi ở trên, hoặc tắt IPv6 trong suốt thời gian đường hầm tồn tại. Bỏ tiền tố khỏi AllowedIPs tự nó không đủ, vì hệ điều hành vẫn giữ tuyến mặc định của riêng nó. Trên Linux, phiên bản thô là sysctl -w net.ipv6.conf.all.disable_ipv6=1; phiên bản tinh tế hơn thả IPv6 ra ngoài đường hầm bằng một quy tắc tường lửa. Máy khách trên điện thoại có nút chặn IPv6 rõ ràng làm cùng công việc đó.

Xác minh nó như một rò rỉ

Dựng đường hầm lên và đọc trạng thái thay vì tin vào nút gạt. ip -6 route show default phải hiển thị một tuyến mặc định, và ip -6 route get cho một đích ngoài LAN của bạn phải nêu tên thiết bị đường hầm. Lặp lại cả hai sau khi ngắt kết nối: một tuyến mặc định sống lâu hơn đường hầm chính là lỗi bạn đang tìm.

Sau đó kiểm tra hướng ngược lại. Từ một máy chủ trên mạng cục bộ, tiếp cận máy khách tại địa chỉ IPv6 cục bộ của nó. Nếu điều đó ngừng hoạt động, điều kiện ba chưa bao giờ được thỏa mãn, bất kể bảng tuyến nói gì lúc đó.

Viết kết quả ở nơi người tiếp theo sẽ tìm thấy: những tiền tố nào ở lại cục bộ, tại sao và máy khách làm gì sau khi ngắt kết nối. Hai dòng trong một runbook giúp kỹ sư tiếp theo khỏi phải khám phá lại vòng lặp điểm cuối lúc nửa đêm.