Sử dụng Internet mà không cần kết nối IPv4
(jamesmcm.github.io)- Ngay cả khi kết nối IPv4 bị gián đoạn, vẫn có thể sử dụng toàn bộ Internet thông qua IPv6, WireGuard và VPS Hetzner
- Do Carrier Grade NAT (NAT quy mô lớn), chỉ IPv4 gặp sự cố, còn IPv6 không bị ảnh hưởng
- Bằng cách thiết lập đường hầm WireGuard và tunnel lưu lượng IPv4 qua VPS, môi trường truy cập web bình thường đã được khôi phục
- Bài viết cũng đề cập đến cách dùng network namespace và Docker, cùng phương pháp xử lý vấn đề MTU
- Nhấn mạnh trải nghiệm tự giải quyết các sự cố mạng phức tạp nhờ môi trường Linux và các công cụ mã nguồn mở
Tổng quan
Vài ngày trước, tác giả gặp sự cố mất kết nối IPv4 trên router tại nhà sau một lần mất điện. May mắn là kết nối IPv6 vẫn hoạt động bình thường, nên vẫn có thể truy cập một số website như Google, Meta, nhưng phần lớn trang khác như GitHub thì không truy cập được. Vì vậy, tác giả đã tổng hợp lại quá trình dùng Linux, WireGuard và VPS Hetzner để khôi phục môi trường sử dụng toàn bộ Internet chỉ với IPv6.
Nguyên nhân sự cố và bối cảnh
Phát hiện bất thường trong môi trường mạng
- Trong quá trình khôi phục sau mất điện, xác nhận hiện tượng máy chủ IPv6 truy cập bình thường nhưng máy chủ IPv4 không thể truy cập
- Kết quả chạy các lệnh chẩn đoán (
ping -6,traceroute) cũng chỉ cho thấy sự khác biệt theo phiên bản IP - Sau khi liên hệ, xác định rằng lớp CG-NAT (Carrier Grade NAT) phía nhà mạng gặp lỗi trong quá trình chuyển đổi IPv4
- Dự kiến phải mất vài ngày để ISP xử lý xong, nên cần tự tìm cách khắc phục
Giải thích về NAT và CG-NAT
- NAT (Network Address Translation): phương thức cho phép nhiều thiết bị dùng chung một địa chỉ IPv4 công cộng
- Router thay thế IP nội bộ bằng IP công cộng và cổng tương ứng để quản lý lưu lượng, rồi khi gói tin quay về sẽ dùng thông tin ánh xạ để khôi phục đích nội bộ
- Cấu trúc này tạo ra vai trò tường lửa ngầm định và nhu cầu phải dùng port forwarding
- CG-NAT (Carrier Grade NAT): cấu trúc phân tầng trong đó ISP áp dụng NAT thêm một lần nữa đối với từng router gia đình
- Do thiếu hụt địa chỉ IPv4, ISP chồng thêm một lớp NAT trong nội bộ
- Trong môi trường CG-NAT, việc cung cấp dịch vụ như port forwarding càng bị hạn chế hơn
- Lý do chỉ lưu lượng IPv4 bị ảnh hưởng trong sự cố này chính là do lỗi xử lý gói IPv4 ở lớp này
Ưu điểm của IPv6
- Không gian địa chỉ IPv6 lớn vượt trội, cho phép cấp địa chỉ trực tiếp cho từng thiết bị mà không cần NAT
- Phần lớn router gia đình được cấp một subnet
/64, đủ để dùng hàng tỷ tỷ địa chỉ
- Phần lớn router gia đình được cấp một subnet
- Vì không cần NAT riêng nên có thể giao tiếp trực tiếp, nhưng cấu hình tường lửa lại càng quan trọng hơn
- CG-NAT chỉ áp dụng cho IPv4, nên trong sự cố này chỉ IPv6 vẫn hoạt động bình thường
- Tuy vậy, hiện vẫn có nhiều máy chủ (ví dụ: GitHub) không thể truy cập chỉ bằng IPv6
Khôi phục IPv4 bằng đường hầm WireGuard
Tổng quan triển khai
- Sử dụng VPS Hetzner (hỗ trợ cả IPv4/IPv6 stack) và WireGuard để xây dựng môi trường truy cập toàn bộ Internet trong tình trạng chỉ còn kết nối Internet qua IPv6
- Chạy máy chủ WireGuard trên VPS và thiết lập đường hầm với thiết bị khách
- Lưu lượng được chuyển hướng tới VPS qua IPv6, sau đó đi tiếp qua VPS để truy cập toàn bộ website, bao gồm cả IPv4
- Nguyên lý tương tự Dual-Stack Lite
Ví dụ cấu hình máy chủ và máy khách
- Trong cấu hình máy chủ WireGuard, xử lý cả lưu lượng IPv4 và IPv6
- Có kèm ví dụ về các rule MASQUERADE (chuyển đổi IP động) và SNAT (chuyển đổi IP cố định)
- Có thể kết nối trực tiếp WireGuard peer mà không cần NAT bằng cách dùng IPv6 global được cấp trực tiếp
- Có thể viết nhiều mục PostUp/PostDown để chạy tuần tự nhiều lệnh
- Ví dụ cấu hình máy khách
- Giải thích ví dụ kết hợp địa chỉ IPv6 được cấp trực tiếp hoặc ULA đã qua NAT
- Có thể tunnel toàn bộ lưu lượng bằng cách đặt
AllowedIPslà0.0.0.0/0, ::/0 - Cung cấp cách thiết lập Google DNS (IPv4, IPv6) và MTU
Đường hầm hoạt động bình thường
- Sau khi hoàn tất cấu hình WireGuard ở cả hai phía, cả IPv4 và IPv6 đều được tunnel bình thường
- Tác giả cũng áp dụng cùng cách này cho PC của vợ, cài nhanh WireGuard client trên Linux
- Tuy nhiên, thường không thể kết nối đồng thời với VPN công ty, nên cần dùng thêm network namespace
Network namespace và Docker
Tính năng và cách sử dụng
- Dùng các công cụ như vopono để tạo network namespace theo từng ứng dụng, rồi chỉ định trực tiếp giao diện VPN hoặc WireGuard trong namespace đó
- Cần chỉ định thêm các rule MASQUERADE riêng để buộc lưu lượng nội bộ đi qua đường hầm WireGuard
- Có kèm các mẹo cấu hình như DNS tách biệt với bên ngoài,
gai.conf(thiết lập DNS ưu tiên IPv4), v.v.
- Ví dụ cách kết nối VPN và chạy ứng dụng bên trong namespace
- Chạy nhiều dịch vụ trong cùng một namespace để ngăn ngừa xung đột mạng từ sớm
Kết hợp với container Docker
- Docker daemon mặc định dùng network socket của host, nên chỉ chạy trong namespace thông thường thì không thể truy cập được
- Bài viết đưa ra workaround bằng các kỹ thuật ảo hóa Unix như mount namespace, bind mount
/sys, v.v. - Chạy dockerd bên trong namespace, đồng thời chỉ định socket và data root riêng để khôi phục kết nối Internet trong container
- Cũng đề cập rằng với môi trường bridge mạng phức tạp có thể cần thêm cấu hình bổ sung
- Bài viết đưa ra workaround bằng các kỹ thuật ảo hóa Unix như mount namespace, bind mount
Vấn đề MTU của WireGuard (MTU: đơn vị truyền tối đa)
- Sau khi kết nối WireGuard, xuất hiện hiện tượng chỉ một số website không truy cập được (như SSL), trong khi ping vẫn phản hồi bình thường
- Qua thử nghiệm ping với nhiều kích thước khác nhau, xác định nguyên nhân là MTU quá cao khiến các gói lớn bị rơi giữa đường
- Hạ MTU xuống 1280 thì vấn đề được giải quyết ngay lập tức
- MTU là kích thước gói tối đa có thể truyền trong một lần
- Cần đặt MTU phù hợp có tính đến overhead của tunnel/encapsulation, nếu không sẽ phát sinh lỗi kết nối khi truyền gói lớn
- Theo chuẩn, IPv6 có MTU tối thiểu là 1280
Kết luận và gợi ý ứng dụng
- Bài viết nhấn mạnh trải nghiệm tự chẩn đoán và xử lý sự cố mạng bằng Linux và các công cụ mã nguồn mở, bao gồm dựng máy chủ WireGuard VPN, quản lý network namespace, cấu hình Docker trong môi trường đặc biệt và troubleshooting MTU
- Các dịch vụ như VPS Hetzner có độ ổn định tốt so với chi phí và thuận tiện để vận hành các dịch vụ mạng hợp pháp như WireGuard
- Giá trị của firmware router mã nguồn mở (OpenWRT) và các kỹ thuật networking trên Linux cũng được nhìn nhận lại
- Sự linh hoạt khi có thể trực tiếp quản lý/chỉnh sửa mạng mang lại lợi thế lớn trong môi trường làm việc từ xa
- Nếu có đủ hiểu biết và luyện tập, ngay cả các sự cố mạng phức tạp cũng có thể tự mình giải quyết
Tài liệu tham khảo
- Tailscale – How NAT Traversal Works
- ArchWiki – Ví dụ use case của WireGuard
- Unix StackExchange – Mẹo dùng Docker trong namespace
- AskUbuntu – Thiết lập độ ưu tiên DNS
(Tham khảo bài gốc để xem các script, config, mẹo và liên kết liên quan)
1 bình luận
Ý kiến Hacker News
Tiêu đề có hơi dễ gây hiểu nhầm, vì thực ra bài này gần với kiểu “kết nối tới VPS qua đường hầm IPv6 rồi truy cập Internet IPv4” hơn, thường gọi là 4in6
Dù sao thì đây vẫn là một cách làm thú vị
Theo kinh nghiệm của tôi, nếu ISP của chúng tôi gặp sự cố với IPv4 thì toàn bộ sẽ sập ngay nên vấn đề hỗ trợ tương đối đơn giản, còn nếu IPv6 gặp sự cố thì nó hỏng theo kiểu cục bộ, biểu hiện kỳ quặc như kết nối chậm hoặc lúc được lúc không
Đặc biệt nếu gateway tưởng rằng nó có IPv6, thì từ góc nhìn người dùng vấn đề sẽ khó chịu hơn nhiều, kiểu chỉ có vài tính năng không hoạt động
Gần đây khi IPv4 bị gián đoạn một lúc, tôi chỉ nhận ra khi Github không vào được
Dạo này phần lớn website cho người dùng phổ thông đều hoạt động bình thường qua IPv6
Tuy vậy, những ai có router chỉ cung cấp DNS IPv4 thì sẽ gặp tình trạng mất Internet hoàn toàn
Tôi nghĩ Microsoft nên chú ý hơn một chút
Để kiểm tra xem IPv4 đã quay lại chưa, tôi còn phải nhớ hostname mDNS đã gán cho router
Thành thật mà nói, đã có lần IPv4 ở nhà tôi bị đứt mà vợ tôi còn không nhận ra
Google, Facebook, Apple/iCloud và gần như mọi dịch vụ dựa trên CloudFlare đều hoạt động tốt qua IPv6
Trải nghiệm của tôi cũng tương tự
Sự cố IPv6 thực sự rất khó xác định nguyên nhân và tái hiện, rồi cứ lặp đi lặp lại kiểu “máy tôi vẫn chạy mà?”
Phần lớn ISP vẫn đang chặn IPv6, mà ngay cả các doanh nghiệp nhỏ cũng thường chỉ thử triển khai IPv6 rồi lại quên mất những thứ như bản ghi AAAA
Vì thế người dùng rơi vào tình huống ở nhà bạn bè hay quán cà phê dùng ISP giá rẻ thì một thứ gì đó lại chạy, còn ở nhà mình thì không
Nghe có thể hơi kỳ, nhưng dường như cũng không có giải pháp tốt nào đặc biệt, thực tế chỉ còn biết hy vọng IPv4 biến mất
Có những kỹ thuật như Happy Eyeballs (thử kết nối IPv4/IPv6 đồng thời rồi chọn cái nhanh hơn), nhưng trên thực tế vấn đề lại hay phát sinh ở tầng ứng dụng hơn, và thiếu một cách tổng quát để xử lý
Trường hợp của tôi là bật IPv6 trên mạng, nhưng tắt DNS IPv6 trong trình duyệt như một giải pháp thỏa hiệp, và nó cũng không thật sự thỏa đáng
Nếu bạn muốn dùng IPv6 nhưng ISP không cung cấp, Hurricane Electric (HE) đã cung cấp dịch vụ đường hầm miễn phí từ rất lâu rồi
Có thể tham khảo các liên kết như tunnelbroker.net, ipv6.he.net, cách cấu hình trên Fedora, blog của Brandon Rozek, cách cấu hình DD-WRT, script tự động cập nhật trên diễn đàn Mikrotik, hướng dẫn RockyLinux cùng nhiều cách thiết lập khác nhau
Có một điều cần lưu ý là khi dùng dịch vụ streaming, nhiều nơi sẽ chặn kiểu đường hầm này, như thể nhận diện nó là đường vòng VPN nên chặn nội dung bị giới hạn theo vùng
Dù vậy, nhờ tính năng RA (router advertisement), bất kỳ thiết bị mạng nào cũng có thể phát quảng bá mạng IPv6 theo đơn vị /64, nên ngay cả khi router không hỗ trợ trực tiếp đường hầm HE, nhiều thiết bị trong mạng vẫn có thể dùng địa chỉ IPv6 được (miễn là router không lọc RA vì lý do bảo mật)
Khi muốn tự host thứ gì đó ở nhà thì việc làm chỉ với IPv6 mà không cần port forwarding là cực kỳ tiện
Dịch vụ của Hurricane Electric thì tốt, nhưng giờ ngày càng nhiều ISP cung cấp IPv6 mặc định nên người dùng phổ thông đang dần rời bỏ dịch vụ đường hầm
Thêm nữa, một số dịch vụ mạng ngày càng xem đường hầm he.net là lạm dụng hoặc bị lợi dụng nên chặn luôn, thành ra cuối cùng tôi phải tắt IPv6 ở phần lớn mạng của mình
Một điểm cần biết là đường hầm Hurricane Electric bắt buộc phải có địa chỉ IPv4 công cộng do ISP cấp thì mới chạy được
Nếu bạn đang ở sau NAT như carrier-grade NAT thì muốn đưa IPv6 vào nhà sẽ phải tìm giải pháp khác chứ không dùng cách này được
Đây là trải nghiệm của một “khách hàng” đã dùng đường hầm 6in4 miễn phí của HE với OpenBSD suốt 5 năm
Chỉ với cấu hình mạng như file /etc/hostname.gif0 là nó vẫn chạy ổn định đều đặn
Tôi cũng dùng nó để liên lạc với một cụm VPS được cấu hình cố ý không có IPv4 trên AWS
Vì AWS đang tính phí địa chỉ IPv4 khá mạnh tay, tôi thấy cách này giúp tiết kiệm chi phí rất đáng kể
Nếu bạn thực sự ở môi trường chỉ có v6 mà vẫn cần truy cập v4, thì có thể giải quyết rất dễ bằng public DNS64+NAT64 gateway
Xem danh sách provider công khai của nat64.net
Bình thường chỉ cần đổi DNS server là được
DNS64 sẽ tổng hợp bản ghi AAAA cho các trang không có bản ghi AAAA để chúng có thể kết nối tới hộp NAT64
Sau đó NAT64 sẽ nhận lưu lượng và thực hiện chuyển đổi giao thức + NAT
Với các ví dụ thực hành dùng lệnh
dighaycurl, bạn có thể truy cập ngay những nơi như githubỞ châu Âu, dùng trực tiếp nat64.net cũng hoạt động khá mượt
Thực sự tôi chỉ có trải nghiệm tốt với nó
Nếu dùng Cloudflare WARP thì có thể cảm nhận tốc độ nhanh hơn nhiều
Qua WARP cũng có thể truy cập trực tiếp địa chỉ IPv4
Thỉnh thoảng tôi thấy lạ khi vẫn có người dùng IPv6-only
Ngày trước ở tình huống ngược lại (môi trường chỉ có IPv4 nhưng cần truy cập IPv6), nếu có toàn quyền với máy chủ thì giải pháp tốt nhất và cực nhanh là dùng proxy SOCKS5 (
ssh -D)Chỉ cần cấu hình riêng trình duyệt dùng socks proxy là dùng được ngay
Nếu áp dụng cho toàn hệ thống thì ngược lại có thể làm đứt luôn kết nối ssh, nên đó là điều khiến tôi lo ngại
Tôi cũng ở tình huống tương tự
Đã khoảng 2 tuần có ticket về sự cố IPv4 mở ra, nhưng chỉ luôn nhận câu trả lời “kỹ thuật viên sẽ xử lý sớm”
Có vẻ vì IPv6 vẫn bình thường nên họ không xem đó là sự cố toàn phần
Ở Đức có luật về bồi thường cho người tiêu dùng trong những trường hợp như vậy, và tôi định kiểm tra xem ca này có thuộc diện áp dụng không
Vấn đề với cách làm mà bài blog đề xuất là dải IP của datacenter thường bị nhiều dịch vụ chặn, hoặc bị yêu cầu CAPTCHA hay các biện pháp kiểu như với IP của nhà cung cấp VPN, nên gần như không có cách tránh
Trường hợp của tôi cần xử lý cho cả nhà, nên tôi đã thiết lập định tuyến và quy tắc NAT bằng Wireguard trên router, và may là tôi dùng thiết bị mở kiểu Ubiquiti EdgeRouter
Nếu là FritzBox thì chắc việc này sẽ khó hơn nhiều
Tuy vậy, nhược điểm là router không đủ mạnh sẽ bị chậm khi lượng kết nối nhiều, nên tôi đang cân nhắc chuyển sang IPSec có hỗ trợ hardware offloading
FritzBox cũng cung cấp một quy trình cấu hình GUI rất tốt cho kết nối VPN
Mặc định giả định là FritzBox to FritzBox, nhưng VPN tương thích thì vẫn OK
Nó cũng cho cấu hình route IPv4/IPv6 tĩnh
Vấn đề lớn nhất là tìm ra phía bên kia yêu cầu cấu hình mã hóa IPSec như thế nào; Wireguard thì dễ hơn, nhưng ngược lại lại có vấn đề về tăng tốc phần cứng
Nếu cần, còn có mẹo sao lưu toàn bộ cấu hình FritzBox rồi chỉnh sửa trực tiếp, sau đó chỉ cần tính lại checksum và nạp lại
AVM giấu đi một lượng khổng lồ các thiết lập chi tiết mà người dùng không thấy, và điều đó là có chủ đích
Có vẻ họ cố ý làm nó hơi khó để tránh người dùng vô tình làm hỏng router
Tôi không rõ tình hình ở Đức, nhưng ở Hà Lan nếu bạn dùng cùng một ISP cho cả Internet cố định lẫn di động, thì khi mạng dây gặp sự cố bạn có thể yêu cầu dung lượng di động miễn phí
Nếu có thể, tôi khuyên nên hỏi ISP về tùy chọn đó
Dù đã rất lâu, tôi vẫn chưa tìm ra lý do thật sự rõ ràng để chuyển toàn bộ thiết bị và homelab sang IPv6
Port forwarding và cấu hình firewall vẫn còn trực quan hơn, còn nếu chuyển sang IPv6 thì tôi hình dung sẽ phải mất hàng tuần để xử lý sự cố, firewall, đổi địa chỉ và đủ thứ phức tạp khác
Tôi đang tự hỏi liệu mình có đang bỏ sót điều gì không
Thực tế ở giai đoạn hiện tại thì bạn gần như không bỏ sót gì cả
Trong tương lai, khi các ông lớn như Google hay Cloudflare không còn gánh nổi chi phí địa chỉ IPv4 ngày càng tăng, họ có thể tạo động lực cho IPv6 nhiều hơn, ví dụ giới hạn tốc độ trên kết nối IPv4
AWS trước đây chỉ tính phí IPv4 Elastic IP không dùng, còn giờ thì ngay cả đang dùng cũng tính phí
Khi sau này nâng cấp gateway hay router, có lẽ nên cứ bật IPv6 lên, và hiện tại dùng dual-stack thì vẫn chạy tốt với thiết bị cũ và dịch vụ cũ
Về tự động cấp phát địa chỉ IPv6, trong lịch sử từng khá lộn xộn, nhưng có vẻ đang dần ổn định quanh SLAAC, còn từ góc nhìn ISP thì DHCPv6 có lẽ vẫn sẽ được dùng khá lâu nữa
Thực ra không khó đến vậy
Nếu mạng gia đình của bạn không quá phức tạp thì chỉ cần bỏ ra một buổi tối là có thể cấu hình IPv6 xong
Với Comcast chẳng hạn, chỉ cần bật tùy chọn IPv6 trên router là ISP sẽ cấp prefix, rồi chỉ riêng vậy thôi cũng sẽ tự quảng bá ra toàn mạng, sau đó chỉ cần mở firewall cho những cổng bạn muốn là xong
Bạn không bỏ sót gì cả
Trong môi trường enterprise, việc đưa IPv6 vào thường có nhiều nhược điểm hoặc độ phức tạp hơn là lợi ích
Tôi đang quản lý khoảng 3.500 thiết bị, 7 tòa nhà, 2 WAN 10Gbps, 1 WAN 4Gbps và 26 địa chỉ IPv4 công cộng
Đến giờ tôi vẫn chưa thấy bất kỳ lý do nào bắt buộc phải dùng IPv6
Vận hành dual-stack chỉ làm phát sinh tải và độ phức tạp không cần thiết cho mạng
Trớ trêu là gần đây tôi đã nộp đơn 2 lần để xin khối IPv6 tĩnh mà vẫn liên tục bị từ chối
Thực tế chẳng có lợi ích gì rõ ràng, mà thậm chí còn khó được cấp
Nếu xem hướng dẫn yêu cầu IPv6 lần đầu của ARIN, thì
→ đang sở hữu phân bổ IPv4
→ có kế hoạch multihome IPv6 ngay lập tức
→ có 13 end-site (văn phòng v.v.) trong vòng 1 năm
→ có 2.000 địa chỉ IPv6 trong vòng 1 năm
→ có 200 subnet /64 trong vòng 1 năm
chỉ cần đáp ứng một trong các điều kiện đó mới đủ điều kiện nộp đơn
Tôi thật sự đánh giá cao chính sách của Apple App Store yêu cầu mọi ứng dụng phải hoạt động được trên mạng IPv6-only
Từ góc nhìn nhà phát triển, lần đầu gặp quy định này có thể sẽ bất ngờ, nhưng với người dùng thì đây là một yêu cầu rất đáng hoan nghênh
Nhưng chính sách này không bắt buộc phía máy chủ phải có địa chỉ IPv6
Vậy thì tôi tò mò không biết github có truy cập được qua v6 từ trong ứng dụng hay không
Trong công việc, tôi đang vận hành nhiều VPN IPv6-only để truy cập hạ tầng nội bộ
Vấn đề lớn nhất là các client Windows và macOS bắt buộc phải có DNS server v6
Vì client có thể đang ở trên mạng có hỗ trợ v6 hoặc không, tôi chạy DNS server ngay trong VPN rồi tự động đẩy xuống client
Nhưng sau khi VPN ngắt kết nối, ứng dụng Wireguard lại không thể khôi phục DNS ban đầu, dẫn đến nhiều vấn đề khác nhau
Tôi không nhớ chính xác cách làm, nhưng macOS vẫn hoạt động bình thường chỉ với địa chỉ v6
Bạn chỉ cần gán địa chỉ ULA cho host, và việc này khá dễ nếu người dùng biết cách
Ứng dụng VPN có thể dùng script để tự thêm ULA vào mạng IPv6-only
Tuy nhiên, nếu cứ để nguyên địa chỉ ULA đó thì khi người dùng chuyển sang mạng v6 khác có thể phát sinh vấn đề
Nếu gặp đúng tình huống này, bạn có thể rất dễ tạo môi trường socks proxy bằng ssh proxy (
ssh -D 8080 user@hostname)Sau khi kết nối, chỉ cần đặt địa chỉ proxy của trình duyệt là
localhost:8080Tôi cũng định đưa ra đúng lời khuyên đó
Nó cực kỳ đơn giản để xử lý tạm thời, và khi cần còn có thể dùng như công cụ lâu dài rất tốt
Tuy nhiên,
AllowTcpForwardingphải được bật trongsshd_configTôi luôn dùng cách này khi sử dụng Wi‑Fi công cộng
Không cần trả tiền cho dịch vụ VPN, cũng không cần tin tưởng bên nào cả, chỉ cần gửi qua socks proxy trên máy chủ infomaniak của chính mình là được
Cá nhân tôi có rất nhiều bất mãn với IPv4, đặc biệt là vì ISP của tôi ép buộc chỉ cung cấp IPv4 nên lại càng bức bối
Tôi xem việc triển khai IPv6 chậm đến mức này là một thất bại lớn của ngành công nghệ
Tôi vẫn băn khoăn ai nên chịu trách nhiệm
Là do các hãng sản xuất router làm firmware quá tệ, do thiếu sự dẫn dắt từ ISP với IPv4, do giới đầu cơ địa chỉ IPv4, hay do thiếu đào tạo cho kỹ sư mạng và nhân sự hỗ trợ — tôi nghĩ cần có thêm thảo luận gốc rễ về nguyên nhân
Giống như Internet đã chuyển đổi khá ổn khỏi TLS 1.0, IPv4 lẽ ra cũng phải chuyển được chứ
Có lẽ sau này một thứ như AI proxy cho legacy code cũng có thể trở thành lời giải
Việc chuyển khỏi TLS 1.0 dễ hơn là nhờ nguyên lý end-to-end
Chỉ cần server và client hỗ trợ giao thức mới, còn thiết bị trung gian (router, switch v.v.) chỉ cần nhìn tầng mạng (IP) nên không liên quan đến phiên bản TLS mới
Nhưng nếu thay cả giao thức ở tầng mạng (IP), thì toàn bộ thiết bị mạng trung gian đều bị ảnh hưởng
Nhân tiện, ngay cả khi triển khai TLS 1.3, cũng từng có chuyện middlebox phá vỡ nguyên lý end-to-end bằng cách giám sát/chỉnh sửa lưu lượng, khiến TLS 1.3 phải dùng mẹo ngụy trang như một lần nối lại TLS 1.2 để tương thích — một chuyện khá lố bịch
Khác biệt nằm ở chỗ TLS chỉ cần server/client hỗ trợ, còn thiết bị mạng trung gian chỉ cần hiểu gói TCP
IPv6 thì tất cả thiết bị trung gian giữa server và client đều phải hỗ trợ, nên nó là loại công nghệ phụ thuộc vào “mẫu số chung nhỏ nhất”
Việc nâng cấp TLS không thay đổi quá nhiều thứ, trong khi IPv6 lại thay đổi quá nhiều phần cùng lúc
Nhìn lại thì, giá như IPv6 chỉ đơn giản tăng địa chỉ lên 64-bit thôi thì có lẽ đã dễ phổ biến hơn
Thực tế, nhiều người không nhiệt tình triển khai đơn giản vì lợi ích thực tế của việc thay thế là quá ít hoặc gần như không có
Không có thuyết âm mưu IPv4 khổng lồ nào cả, chỉ là hiệu quả không tương xứng với công sức và rủi ro
Trong giới mạng có câu đùa rằng “IPv6 là lời giải mang tính hàn lâm được nhét vào một bài toán kỹ thuật”
Nếu tính đến việc vừa phải giữ tương thích với IPv4 ở quy mô lớn, vừa phải triển khai, vận hành và bảo trì ngoài thực tế, thì IPv6 quá phức tạp
IPv4 về cơ bản cũng chẳng biến mất được, vì ngoài chuyện thiếu địa chỉ ra thì nó không có vấn đề thực chất nào khác
Thành ra ngoài hiện trường, IPv6 vẫn chưa trở thành một giải pháp thật sự