- Sau khi mất điện, ở phía ISP xảy ra tình huống chỉ kết nối IPv4 bị ngắt còn IPv6 vẫn hoạt động, nên tác giả dùng một VPS Hetzner có cả IPv4/IPv6 cùng đường hầm WireGuard để khôi phục truy cập các trang chỉ hỗ trợ IPv4
- Sự cố có vẻ nằm ở lớp CG-NAT, nơi các gói IPv4 không được chuyển đổi đúng cách và bị drop; các dịch vụ hỗ trợ IPv6 như Google, Meta vẫn truy cập được
- Khi đặt máy chủ WireGuard trên VPS và để client dùng địa chỉ IPv6 của VPS làm endpoint, có thể gửi lưu lượng IPv4 qua VPS và khôi phục duyệt web thông thường
- VPN dùng cho công việc và Docker cần xử lý riêng, nên được chạy trong cùng namespace với network namespace dựa trên vopono và các cách vòng như
unshare cùng bind mount /sys
- Triệu chứng chỉ một số trang không tải được là do MTU của WireGuard quá lớn; hạ xuống 1280, MTU tối thiểu của IPv6, thì được giải quyết ngay
Sự cố sau mất điện: chỉ IPv4 bị ngắt
- Sau khi mất điện và bật lại cầu dao, tác giả không thể truy cập GitHub cùng nhiều website khác, trong khi Google và Meta vẫn hoạt động bình thường
- Kiểm tra
ping -6 và traceroute trên máy cục bộ và trang chẩn đoán của router cho thấy vấn đề chỉ nằm ở kết nối tới máy chủ IPv4
- ISP nói có thể cần kỹ thuật viên đến kiểm tra và có thể mất vài ngày sau cuối tuần; do cần truy cập phục vụ công việc và làm bài nghiên cứu nên khó có thể chỉ chờ sự cố được khắc phục
- VPS Hetzner sẵn có có địa chỉ IPv4 và IPv6 tĩnh, và vì website Hetzner hỗ trợ IPv6 nên tác giả có thể truy cập console để cấu hình
Sự phụ thuộc vào IPv4 do NAT và CG-NAT tạo ra
- Địa chỉ IPv4 dài 32 bit, và nếu loại trừ các khối được dành riêng thì chỉ có khoảng 3,7 tỷ địa chỉ IPv4 công khai, nên không thể cấp địa chỉ trực tiếp cho mọi thiết bị kết nối Internet
- NAT cho phép nhiều thiết bị dùng chung một IP công khai
- Router gia đình chuyển IP cục bộ của các thiết bị bên trong, như
192.168.1.xxx, thành IPv4 công khai của chính router
- conntrack của Linux lưu ánh xạ giữa IP và cổng nguồn ban đầu với cổng đã được chuyển đổi
- Khi gói phản hồi đến cổng đó, conntrack chuyển đích trở lại IP và cổng nội bộ ban đầu
- Trên Linux có thể xem các ánh xạ đã lưu bằng
conntrack -L trong conntrack-tools
- NAT hoạt động như một tường lửa ngầm định, khiến các dịch vụ trên thiết bị cục bộ phía sau router khó được truy cập từ bên ngoài nếu không có port forwarding rõ ràng
- Do thiếu IPv4, ISP có thể áp dụng thêm một lớp NAT nữa trong mạng nội bộ của họ, gọi là Carrier Grade NAT(CG-NAT)
- Giống như router gia đình NAT nhiều thiết bị cục bộ, router của ISP NAT nhiều router gia đình
- Tùy theo số địa chỉ IPv4 ISP có và chính sách cấp phát, cơ chế này có thể lặp lại qua nhiều tầng, chẳng hạn theo khu vực
- Sự cố lần này có vẻ là tình trạng lưu lượng IPv4 bị ngắt hoàn toàn vì các gói IPv4 không được NAT đúng cách ở đâu đó trong lớp CG-NAT và bị drop
- Có thể tham khảo cách vượt NAT traversal trong How NAT Traversal Works của Tailscale
Vì sao IPv6 vẫn tiếp tục hoạt động
- Địa chỉ IPv6 dài 128 bit, và ngay cả khi tính đến các khối được dành riêng thì vẫn cung cấp khoảng 3.4E38 địa chỉ
- Router gia đình thường nhận subnet
/64, tương đương 1.84E19 địa chỉ
- Với IPv6, mỗi thiết bị có thể có địa chỉ trực tiếp trên Internet mà không cần dùng NAT trên router gia đình
- Vấn đề port forwarding giảm đi
- Đổi lại, router hoặc từng thiết bị cần có quy tắc tường lửa phù hợp để chặn các kết nối mới tùy ý từ bên ngoài
- Vì CG-NAT không được áp dụng cho IPv6 nên nó không bị ảnh hưởng bởi sự cố lần này
- Vẫn có các web server như GitHub không thể truy cập bằng IPv6, nên chỉ với kết nối IPv6 thì không thể trực tiếp dùng toàn bộ Internet
Tạo đường hầm IPv4 trên IPv6 bằng WireGuard
- Giải pháp là cài WireGuard trên VPS và cấu hình đường hầm để client dùng địa chỉ IPv6 của VPS làm endpoint
- Khi đường hầm được thiết lập, lưu lượng IPv4 đi qua VPS và hoạt động bình thường
- Độ trễ tăng lên do đi qua VPS
- Cách hoạt động gần giống Dual-Stack Lite tự cấu hình
- Máy chủ là VPS Hetzner đã được cài Arch Linux bằng vps2arch, dùng trên nền image Debian mới nhất của Hetzner
- Cấu hình WireGuard dựa trên ví dụ máy chủ VPN cho use case cụ thể của WireGuard trên ArchWiki, với phần lưu lượng IPv6 được bổ sung
- Cấu hình máy chủ bao gồm:
Address = 10.200.200.1/24, fd42:42:42::1/64, 2001:db8:abcd:1234::1/128- IPv4 được forward bằng
MASQUERADE của iptables
- IPv6 ULA được NAT bằng
SNAT --to-source của ip6tables
- Bật forwarding cho IPv4/IPv6
- Peer được chia thành ví dụ
foo dùng trực tiếp IPv6 Global Unicast Address và bar dùng IPv6 ULA đã NAT
- Khác với cấu hình kiểu
.ini, wg-quick cho phép chỉ định PostUp và PostDown nhiều lần, rồi thực thi từng lệnh theo thứ tự
NAT IPv6, SNAT và cấu hình client
- IPv6 không nhất thiết phải NAT; nếu VPS có khối IPv6
/64 như Hetzner, có thể cấp trực tiếp Global Unicast Address(GUA) cho peer
- Để dùng cách cấp địa chỉ trực tiếp, hãy thay Unique Local Address(ULA) của peer và interface bằng địa chỉ IPv6 công khai, đồng thời bỏ quy tắc
ip6tables MASQUERADE
- Mỗi peer có thể được định địa chỉ trực tiếp từ Internet bằng địa chỉ IPv6 đã cấp
- Cách này phù hợp nếu muốn forward dịch vụ riêng từ nhiều thiết bị
- Tường lửa của VPS cần xử lý đúng lưu lượng đi vào
- Nếu chắc chắn địa chỉ IP của VPS là tĩnh và không thay đổi, có thể dùng SNAT thay cho
MASQUERADE
MASQUERADE tra cứu IP của interface lúc chạySNAT chỉ định địa chỉ trực tiếp nên hiệu quả hơn một chút
- Trong cấu hình client, địa chỉ IPv6 của máy chủ phải được đặt trong ngoặc vuông, như
Endpoint = [2001:db8:abcd:1234::1]:51820
AllowedIPs = 0.0.0.0/0, ::/0 để gửi toàn bộ lưu lượng IPv4/IPv6 qua đường hầm- Sau khi chạy ở cả hai phía, việc duyệt web thông thường trở lại bình thường, và cũng có thể SSH trực tiếp vào máy chủ bằng địa chỉ IPv4 và IPv6 cục bộ của đường hầm
- Trên Linux, tác giả cũng có thể cài client WireGuard dễ dàng cho máy của vợ
Tách VPN công việc bằng network namespace
- Nếu kết nối trực tiếp VPN công việc trên kết nối WireGuard thì phát sinh xung đột và không thể sử dụng
- Tác giả dùng vopono để chạy VPN công việc và các ứng dụng cần thiết trong network namespace
- Điểm mấu chốt là làm cho quy tắc MASQUERADE chuyển lưu lượng tới interface WireGuard đang chạy (
foo hoặc bar), thay vì interface mạng vật lý
- Lưu lượng bên trong namespace không trực tiếp nhận biết các quy tắc
nftables của WireGuard trên host, nhưng thực tế vẫn được định tuyến qua đường hầm WireGuard
- Khi có thể,
wg-quick ưu tiên nftables hơn iptables, nhưng điều này tránh xung đột với các quy tắc iptables chuẩn của Docker
- Ví dụ chạy vopono như sau
$ vopono -v exec --create-netns-only --provider None --protocol None -i bar bash
$ sudo ip netns exec vo_none_none bash
$ (inside netns) ./vpn.sh
/etc/netns/vo_none_none/ được ip netns exec mount thành /etc, nên có thể đặt resolv.conf riêng cho namespace đó- Nếu muốn ưu tiên phân giải DNS IPv4, cũng có thể điều chỉnh
gai.conf theo cách tương tự
- Sau khi kết nối VPN công việc, nếu đưa máy chủ DNS nội bộ vào
/etc/netns/vo_none_none/resolv.conf, các ứng dụng chạy trong namespace đó về sau sẽ hoạt động bình thường
- Có thể chạy các ứng dụng như Chrome bên trong namespace với quyền người dùng thông thường
$ vopono -v exec -i bar --provider None --protocol None google-chrome-stable
Chạy Docker trong cùng namespace
- Docker không hoạt động nếu chỉ chạy trong network namespace như một ứng dụng khác
- Lý do là Docker socket được kích hoạt bằng systemd đã được tạo bên ngoài namespace
- Kết nối bên trong không được đảm bảo
- Ngay cả khi dừng Docker bên ngoài rồi thử tạo mới
dockerd và socket bên trong namespace, vấn đề cũng không được giải quyết ngay
ip netns exec tạo mount namespace và mount lại /sys- Vì vậy
/sys/fs/cgroup của host không thấy được
- Khi đó có thể gặp lỗi sau
Error: OCI runtime error: runc: runc create failed: no cgroup mount found in mountinfo
- Cách vòng là dùng
unshare để biến /sys thành bind mount, rồi unmount mount /sys bên trong do ip netns exec tạo
- Ví dụ lệnh như sau
$ sudo systemctl stop docker && sudo systemctl stop docker.socket
$ sudo -E unshare -m sh -c 'mount --bind /sys /sys; exec ip netns exec vo_none_none sudo --user youruser --preserve-env bash'
$ sudo umount /sys
$ sudo dockerd --host=unix:///var/run/docker-netns.sock --data-root=/var/lib/docker-netns
$ DOCKER_OPTS="--dns=YOURDNSHERE" DOCKER_HOST=unix:///var/run/docker-netns.sock sudo --user youruser --preserve-env docker ...
- Nếu chạy
dockerd và lệnh Docker trong cùng phiên, chúng sẽ chia sẻ cùng network namespace và mount namespace
- Cấu hình DNS của Docker cũng có thể đặt trong
/etc/netns/vo_none_none/docker/daemon.json
- Cách này đủ cho các tác vụ cần container phụ và container kết nối qua mạng Docker, nhưng có thể không hoạt động nguyên trạng với các cấu hình Docker phức tạp hơn cần bridge, v.v.
Debug vấn đề MTU của WireGuard
- Sau khi khởi động lại, kết nối WireGuard trông vẫn còn hoạt động nhưng chỉ một số trang tải được, còn các trang như GitHub thì không mở được
ping, ping -6, wg show đều bình thường nên khó tìm nguyên nhân- Kiểm tra bằng ping với các kích thước khác nhau cho thấy các gói lớn bị lỗi
$ ping6 -s 1400 fd42:42:42::1
$ ping6 -s 1200 fd42:42:42::1
$ ping6 -s 800 fd42:42:42::1
- Kích thước
1400 thất bại còn 1200, 800 thành công, xác nhận nguyên nhân là thiết lập MTU
- Khi hạ MTU của interface WireGuard cục bộ, IP stack của kernel sẽ không tạo các gói lớn hơn mức này
- Gói UDP cuối cùng, sau khi cộng thêm overhead đóng gói của WireGuard, cũng không bị drop trên các liên kết có MTU nhỏ trên đường truyền
- Mỗi router trên đường truyền có MTU riêng, và các gói lớn hơn MTU nhỏ nhất có thể bị drop
- Lưu lượng đường hầm có thêm khoảng 32 byte overhead do đóng gói WireGuard, khiến vấn đề MTU dễ nghiêm trọng hơn
- Thông điệp Path MTU Discovery có thể được các router trung gian gửi qua ICMP, nhưng tường lửa thường drop ICMP nên có thể không tự động điều chỉnh được
- MTU tối thiểu theo đặc tả IPv6 là 1280, vì vậy với đường hầm WireGuard chạy trên IPv6, giá trị này luôn phải hoạt động
Các lựa chọn vận hành còn lại sau khi khôi phục
- Kết quả cấu hình bao gồm:
- Cấu hình máy chủ WireGuard VPN trên VPS có cả IPv4 và IPv6
- Hỗ trợ cả lưu lượng IPv6 trực tiếp và IPv6 đã NAT
- Chạy VPN công việc trong network namespace
- Dùng cách vòng
unshare để chạy Docker trong cùng network namespace
- Debug vấn đề MTU của WireGuard
- Với làm việc từ xa, sự cố kết nối Internet luôn là yếu tố rủi ro; trong trường hợp này, các công cụ Linux cho phép đi vòng mà không phải chờ ISP khôi phục cấu hình
- VPS Hetzner hỗ trợ đường hầm WireGuard và mục đích sử dụng thông thường hợp pháp; không cho phép quét cổng, giả mạo lưu lượng hay đào tiền mã hóa
- Các VPN hỗ trợ port forwarding như AirVPN, ProtonVPN, AzireVPN cũng có thể là phương án thay thế để forward cổng máy chủ tại nhà mà không phụ thuộc vào ISP
- Nếu dùng router OpenWRT, có thể debug nhiều hơn ở phía router và xử lý trực tiếp bằng WireGuard trên router mà không cần cấu hình cách đi vòng này riêng trên từng thiết bị
1 bình luận
Các ý kiến trên Hacker News
Tiêu đề hơi dễ gây hiểu nhầm. Nói chính xác thì đây là truy cập Internet IPv4 thông qua đường hầm IPv6 qua VPS, thường cũng được gọi là 4in6
Dù vậy vẫn khá thú vị. Nhìn từ phía ISP, tính chất của các vấn đề hỗ trợ khi làm hỏng IPv4 và khi làm hỏng IPv6 khá khác nhau. Sự cố IPv4 nhìn chung là trạng thái “sập” rõ ràng, nên người dùng rất bực nhưng vấn đề đơn giản. Ngược lại, sự cố IPv6 lộ ra dưới những dạng kỳ quặc như lỗi một phần, khởi động chậm do fallback, hoặc gateway tin rằng có IPv6
Tuy nhiên những người chỉ cấu hình máy chủ DNS IPv4 trên router thì gặp sự cố hoàn toàn. Nếu Microsoft dọn bớt mấy tài sản kém cỏi của họ, có lẽ nỗi lo lớn nhất chỉ là nhớ hostname mDNS gắn với router để đăng nhập và kiểm tra xem IPv4 đã quay lại chưa
Đây là một vấn đề kỳ lạ, và tôi không biết có giải pháp nào ổn ngoài việc hy vọng IPv4 một ngày nào đó biến mất. Happy Eyeballs vốn được kỳ vọng giải quyết chuyện này, nhưng vấn đề thường xuất hiện ở tầng cao hơn nhiều so với tầng ứng dụng, và ứng dụng thì có thể làm bất cứ thứ gì, nên khó giải bằng một giao thức chung mà không có abstraction bị rò rỉ. Cá nhân tôi đang thỏa hiệp bằng cách bật IPv6 trên mạng nhưng tắt DNS IPv6 trong mọi trình duyệt, khá là không thỏa mãn
Nếu muốn thử IPv6 mà ISP không cung cấp, Hurricane Electric đã cung cấp dịch vụ tunnel từ nhiều năm nay
https://tunnelbroker.net
https://ipv6.he.net
Cũng có các script để dựng thiết bị
tuntrên hệ thống hoặc router và định tuyến traffic: https://fedoraproject.org/wiki/IPv6_tunnel_via_Hurricane_Ele..., https://brandonrozek.com/blog/obtaining-ipv6-address-hurrica..., https://wiki.dd-wrt.com/wiki/index.php/IPv6_setup_Hurricane_..., https://forum.mikrotik.com/t/auto-update-script-for-hurrican..., https://docs.rockylinux.org/guides/network/hurricane_electri...Dù vậy nó hoạt động tốt. Ngay cả khi router không hỗ trợ tunnel HE, nhờ sức mạnh của RA, bạn vẫn có thể gán địa chỉ IPv6 cho mọi thiết bị trong mạng. Bất kỳ thiết bị nào quảng bá một
/64đều trở thành router IPv6. Tất nhiên cần giả định router không lọc RA vì lý do bảo mật. Việc này rất hữu ích khi host dịch vụ trong mạng gia đình mà không phải động tới quy tắc port forwardingQuá nhiều site dựng rào cản hoặc từ chối hoạt động hoàn toàn, nên tôi đã phải ngừng dùng IPv6 trên phần lớn mạng của mình
Chỉ cấu hình bằng các file giao diện mạng OpenBSD như
/etc/hostname.gif0:tunnel,inet6 128 alias,!route -n add -inet6 default. Kết nối này được dùng để truy cập một cụm VPS trên AWS được cố ý cấu hình không có địa chỉ IPv4 công cộng. Vì những người như Jeff Bezos tích cực kiếm tiền từ không gian địa chỉ IPv4, nếu không thì nó đã chiếm một phần lớn chi phí hằng thángNếu thật sự cần kết nối IPv4 nhanh trong môi trường chỉ có IPv6, có thể dùng cổng DNS64+NAT64 công khai. Danh sách có tại https://nat64.net/public-providers
Với nhu cầu thông thường, chỉ cần đổi máy chủ DNS là được. DNS64 sẽ tổng hợp bản ghi DNS AAAA trỏ tới hộp NAT64 cho các đích không có bản ghi AAAA:
$ dig +short @2a00:1098:2c::1 AAAA github.com→2a01:4f8:c2c:123f:64:5:141a:9cd7. NAT64 sẽ chuyển đổi giao thức và xử lý NAT cho lưu lượng được đưa về phía nó nhờ DNS64:$ curl --resolve github.com:443:[2a01:4f8:c2c:123f:64:5:141a:9cd7] [https://github.com/](<https://github.com/>;)Hóa ra người dùng Internet chỉ dùng IPv6 trong truyền thuyết thật sự tồn tại :) Kỹ thuật mạng xuất sắc đấy
Trước đây tôi từng cần thứ tương tự cho mục đích ngược lại, vốn phổ biến hơn: làm các việc liên quan đến IPv6 trên kết nối chỉ có IPv4. Nếu có toàn quyền kiểm soát máy chủ, một cách giải quyết hạn chế hơn nhưng nhanh là dùng
ssh -D 1080 -N myserverđể tạo proxy SOCKS5 rồi cấu hình trong trình duyệt. Có lẽ cũng có thể cấu hình cho toàn hệ thống, nhưng tôi tự hỏi liệu làm vậy có khiến kết nối ssh gốc bị đứt và kéo sập mọi thứ khôngTôi cũng ở cùng tình cảnh. Đã 2 tuần chỉ nghe nói “ticket đang mở và kỹ thuật viên sẽ sớm kiểm tra”, khá là bực
Không biết có phải vì IPv6 vẫn hoạt động nên họ không xem là sự cố mất kết nối hoàn toàn, nên mức ưu tiên thấp hay không. Ở Đức có luật bảo đảm bồi thường cho người tiêu dùng trong các trường hợp như vậy, và tôi sẽ sớm kiểm tra xem trường hợp này có được áp dụng không. Giải pháp trong bài blog này có vấn đề là nhiều endpoint chặn toàn bộ dải IP của datacenter hoặc yêu cầu nhiều CAPTCHA, và các nhà cung cấp VPN thông thường cũng vậy. Tôi muốn sửa cho toàn bộ mạng gia đình nên phải xử lý trên router; nhờ có thiết bị không chuẩn như Ubiquiti EdgeRouter nên việc cấu hình định tuyến Wireguard và quy tắc NAT thuận lợi hơn. Không biết nếu là thiết bị như FritzBox thì tôi đã làm thế nào. Nhược điểm là hiệu năng router không đủ để xử lý nhiều kết nối, nên phải chuyển sang IPSec có hỗ trợ offload phần cứng
Vấn đề lớn nhất có lẽ là xác định phía bên kia kỳ vọng cấu hình mã hóa IPsec nào. Wireguard có thể dễ hơn nhiều, nhưng khi đó có thể gặp vấn đề tăng tốc phần cứng. Nếu cần, cũng có thể sao lưu file cấu hình FritzBox, chỉnh sửa bản dump để tự thiết lập endpoint VPN, rồi tính lại checksum và nhập lại. AVM có nhiều thiết lập người dùng không truy cập được và có thể chỉnh theo cách này, nhưng họ cố tình làm việc truy cập hơi khó để tránh người dùng vô tình biến router thành cục gạch
Đây cũng có thể là một lựa chọn đáng hỏi ISP
Một điểm tôi thích trong quy định App Store của Apple là yêu cầu mọi app phải hoạt động trên mạng chỉ có IPv6. Quy định này đã có từ nhiều năm trước
Là lập trình viên thì lần đầu gặp sẽ hơi bất ngờ, nhưng với tư cách người dùng thì tôi thấy may là có nó
Nếu gặp cùng tình huống, có thể tạo proxy ssh rất dễ bằng
ssh -D 8080 user@hostnameKhi kết nối đã được tạo, chỉ cần chỉ định trong trình duyệt dùng
localhost:8080làm proxy SOCKSĐể dùng tính năng này,
AllowTcpForwardingphải được bật trongsshd_configCó những điểm vướng khi tắt IPv4: phần lớn các công cụ tìm kiếm thay thế dường như không cung cấp kết nối IPv6, còn Github thì lần kiểm tra cuối cùng hoàn toàn không có IPv6
Vì là Microsoft nên không nên kỳ vọng điều tốt đẹp, mà ngược lại nên chuẩn bị cho điều tệ nhất. Gần đây họ còn làm hỏng cả noscript/basic (x)html trong phần issues. Tôi cũng không biết liệu giờ còn có thể tạo tài khoản bằng trình duyệt noscript/basic (x)html, email tự host, và literal IP(v6) kiểu
mailbox@[ipv6:...]hay không. Steam hay game thì gần đây tôi chưa kiểm tra, nhưng có vẻ nhiều CDN/máy chủ game, hoặc một phần đáng kể trong số đó, vẫn chỉ hỗ trợ IPv4. Nhiều máy chủ email cũng chặn mail server tự host, và thường dùng các danh sách chặn vụng về, không phù hợp do những công ty đáng ngờ ở Thụy Sĩ/Andorra như Spamhaus tạo ra. Ngoài ra, nhiều ứng dụng mạng không tận dụng lợi thế của IPv6. Ví dụ, các ứng dụng client-server như web nên dùng một địa chỉ IPv6 được tạo ngẫu nhiên cho mỗi phiên, nếu ISP không cấp prefix quá nhỏ. ISP IPv6 di động dường như cấp các địa chỉ IPv6/128 tùy ý trong prefix, nhưng họ nên cung cấp một prefix ổn định, có lẽ khoảng 96 bit, để ứng dụng trên thiết bị đầu cuối có thể chọn một địa chỉ IPv6 “cố định” cho cuộc gọi thoại/video trực tiếp mà không cần phân giải tên trực tuyến tập trung. Cũng cần một dịch vụ OS cấp người dùng mới để điều phối địa chỉ IPv6 giữa các ứng dụng người dùng. Tuy nhiên, cần cảnh giác với sự phức tạp ngu ngốc mà một số vendor và nhà phát triển sẽ ép buộc nhằm trói buộc người dùng và nhà phát triển ứng dụngThật sự đáng tiếc khi phải làm như vậy chỉ vì mỗi GitHub. Có lẽ rồi cũng sẽ cần đến nó vì mail server, nhưng việc NAT64 trở nên cần thiết sớm như vậy vì lý do này thì quá tệ. Tôi xem đây là một trong nhiều nhược điểm của việc mọi người dùng GitHub làm phương tiện phân phối phần mềm
Tôi hoàn toàn không biết vì sao. Máy đó không chạy bất cứ thứ gì có khả năng gửi email, và theo tôi biết Digital Ocean cũng chặn SMTP, nên về đúng nghĩa đen là máy này không thể gửi email. Spamhaus chẳng giúp gì trong việc xử lý, và DO cũng vậy
https://gitlab.com/miyurusankalpa/IPv6-dns-server
Thực tế là nhiều khả năng bạn vẫn sẽ có kết nối IPv4 dưới hình thức nào đó, chỉ là khả năng kết nối đó đi qua CGNAT sẽ ngày càng cao. Github đặc biệt gây bực mình. Họ đã thử nghiệm trong vài tuần và mọi thứ có vẻ hoạt động tốt, rồi lại quay về chỉ IPv4. Máy chủ email thì dù sao cũng đang sống trong thế giới của 10–20 năm trước. Ngay cả việc tắt hỗ trợ SSL 3.0 hay TLS 1.0 trên máy chủ email cũng khó làm nếu không chấp nhận vấn đề về khả năng gửi đến nơi. Hỗ trợ và bộ lọc spam của Microsoft Outlook dường như thậm chí không nhận ra mail server có IPv6. Dù nhìn vào header thì có vẻ nội bộ họ đã dùng IPv6 từ lâu. Tôi mong IPv6 được tận dụng nhiều hơn, nhưng nỗi sợ rằng nó có thể hoạt động kém hơn đôi chút với một số ít khách hàng dường như đóng băng mọi nỗ lực đưa công nghệ này vào sử dụng thực tế. Lý do bạn thấy hành vi IP kỳ lạ ở nhà mạng di động rất có thể là do cách IP hoạt động trong mạng di động. Khi đang chạy trên cao tốc và gọi điện, hoặc ngồi trên tàu cao tốc, điện thoại liên tục handover, và địa chỉ IP cần có một mức ổn định nhất định. Ngay cả khi vượt biên và chuyển sang mạng nước ngoài, toàn bộ stack vẫn phải duy trì kết nối liền mạch. Bên trong mạng cellular có các hệ thống định tuyến đặc thù, một số trong đó tận dụng rất tốt các tính năng IPv6, nhưng lại khiến việc cung cấp cho điện thoại một địa chỉ unicast toàn cục tĩnh “bình thường” trở nên khó khăn. Họ cố làm cho nó trông bình thường nhất có thể, nhưng để đạt được mức ổn định như Internet gia đình có dây thì không dễ
Ở nơi làm việc, chúng tôi đang vận hành vài VPN chỉ IPv6 để truy cập hạ tầng nội bộ
Vấn đề lớn nhất cho đến nay là client Windows và macOS cần máy chủ DNS IPv6. Nếu không, chúng thậm chí không thử phân giải
v6onlyhost.vpn.example.com. Vì client có thể đang ở trên mạng hỗ trợ IPv6 hoặc không, chúng tôi phải vận hành DNS server bên trong VPN và đẩy nó xuống client; nhưng nếu sau khi VPN ngắt, ứng dụng Wireguard vì lý do nào đó không khôi phục DNS về trạng thái ban đầu, đủ loại vấn đề có thể xảy raTôi không còn nhớ chi tiết, nhưng vài năm trước khi đào sâu thì macOS hoạt động ổn theo cách đó chỉ cần có địa chỉ IPv6. Chỉ cần gắn địa chỉ ULA cho host. Tất nhiên điều này giả định người dùng biết cách làm. Tùy ứng dụng VPN, có thể thêm script để bổ sung ULA khi đi vào mạng chỉ IPv6. Tuy nhiên, nếu cứ để lại ULA giả, nó có thể gây vấn đề khi người dùng chuyển sang một mạng có IPv6
Dù đã lâu như vậy, tôi vẫn chưa thấy có lý do đủ thuyết phục để phải vò đầu bứt tai suốt vài ngày nhằm chuyển toàn bộ máy móc và homelab của mình sang IPv6
Port forwarding và quy tắc tường lửa vẫn trực quan hơn nhiều so với việc phải khắc phục sự cố mọi thứ trong nhiều tuần, cấu hình lại tường lửa và đánh địa chỉ lại mạng. Tôi đang bỏ lỡ điều gì?
Với mạng của tôi và ISP Comcast, chỉ cần bật IPv6 trên router, nhận prefix từ ISP rồi quảng bá trong mạng nội bộ, sau đó thêm một quy tắc tường lửa cho đối tượng muốn cho phép truy cập từ bên ngoài là xong
Tôi quản lý khoảng 3.500 thiết bị, 7 tòa nhà, 2 đường WAN 10 gigabit và 1 đường WAN 4 gigabit, đang dùng khoảng 26 địa chỉ IPv4 công cộng cùng NAT. Hiện vẫn không có lý do mạnh mẽ để triển khai IPv6. Cấu hình dual-stack chỉ thêm lưu lượng và độ phức tạp không cần thiết mà không đem lại lợi ích đáng kể. Ngay cả bây giờ cũng khó được cấp một block địa chỉ IPv6 tĩnh; tôi đã xin hai lần nhưng đều bị từ chối. Không chỉ ít lợi thế để nâng cấp, bản thân việc nhận được block vẫn còn khó. Điều kiện đủ điều kiện tại https://www.arin.net/resources/guide/ipv6/first_request/ cũng kiểu như đang có phân bổ IPv4, dự kiến multihome IPv6 ngay lập tức, có 13 site đầu cuối trong vòng 1 năm, sử dụng 2.000 địa chỉ IPv6 trong vòng 1 năm, sử dụng 200 subnet
/64trong vòng 1 nămĐã có những động thái ban đầu. Trước đây AWS chỉ tính phí các địa chỉ IPv4 Elastic IP không sử dụng, nhưng giờ thì tính phí bất kể có dùng hay không. Thành thật mà nói, chuẩn bị sẵn khi lần tới nâng cấp gateway hoặc router là đủ, còn ngay bây giờ bạn không bỏ lỡ gì cả. Cũng có thể dùng IPv4 và IPv6 đồng thời. Bật trên router thì các thiết bị chỉ hỗ trợ IPv4 vẫn hoạt động bình thường. Một điểm cần lưu ý là cơ chế tự động phát hiện của IPv6 từng khá lộn xộn. Có cả SLAAC, tự cấu hình địa chỉ IPv6 và DHCPv6, trong đó cơ chế tự cấu hình ban đầu thậm chí không hỗ trợ nhận DNS server. Giờ mọi thứ đang dần quy về SLAAC, nhưng các ISP sẽ còn dùng DHCPv6 trong một thời gian rất dài