我在 CentOS 8 上设置了一个 OpenConnect 服务器 (ocserv)，它非常快。但是，当我通过取消注释以下行来启用 IPv6 时，它变得非常慢，上传几乎为零。
#ipv6 网络 = fda9:4efe:7e3b:03ea::/48
我尝试启用 ipv6 转发和 ipv6 伪装，但没有帮助。
值得一提的是，客户端会显示服务器为其提供的 IPv6 地址，从而知道服务器支持 IPv6。例如，当使用 openconnect 连接到服务器时，日志显示：
Connected as 10.10.10.15 + fda9:4efe:7e3b:6b40:f973:5a56:56a0:b1a8/64, using SSL + LZ4, with DTLS + LZ4 in progress
尝试使用 --no-dtls 标志禁用 dtls，但没有帮助。
我需要 IPv6 支持，因为某些网站需要 IPv6，如果您的 ISP 支持 IPv6，但您的 VPN 服务器不支持，那么您将向服务器暴露您的真实 IP 地址，从而使 VPN 连接变得毫无用处。
有人知道我应该如何在不影响连接速度的情况下为 VPN 服务器启用 Iv6 支持吗？
PS. 以下是 VPN 连接后 test-ipv6.com 的连接详情：
Test with IPv4 DNS record
ok (2.008s) using ipv4
http://ipv4.vm3.test-ipv6.com/ip/?callback=?
Fetches an object that has just an A record in DNS. This is expected to use IPv4. IPv6-only users might still reach this, if their provider has employed a NAT64/DNS64 or proxy solution.
Test with IPv6 DNS record
bad (2.011s)
http://ipv6.vm3.test-ipv6.com/ip/?callback=?
Fetches an object that has just an AAAA record in DNS. This is expected to use IPv6. Users not yet on the IPv6 Internet are likely to see this fail. As long as it fails quickly, it will be OK - for now.
Test with Dual Stack DNS record
ok (2.004s) using ipv4
http://ds.vm3.test-ipv6.com/ip/?callback=?
This is the most important test. This verifies your browser can connect to a site that has both IPv4 and IPv6 records published. IPv4 only hosts should connect fine (using IPv4).
If this test fails or times out, you can expect major problems as publishers start offering their sites on IPv6.
Test for Dual Stack DNS and large packet
ok (2.026s) using ipv4
http://ds.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
Validates that you can connect to a dual-stack server (like the ds test); and that you can send/receive large packets on that connection. If this test times out for any reason, it indicates trouble for World IPv6 Day.
Test IPv4 without DNS
ok (1.583s) using ipv4
http://216.218.228.115/ip/?callback=?
This will try connecting with a literal IPv4 numeric address. This should work for most people, unless they are running IPv6-only. If the first test worked, but this fails, it likely confirms your provider is using NAT64/DNS64; you'll need to only try connecting using hostnames instead of numeric IP addresses.
Test IPv6 without DNS
bad (3.007s)
http://[2001:470:1:18::115]:80/ip/?callback=?
This will try connecting with a literal IPv6 hexadecimal address. The primary purpose of this test is to separate out your connectivity on IPv6 from your ability to fetch DNS for it. A secondary purpose is to see if you have Teredo enabled; some systems may only use Teredo when an IPv6 address is in the URL.
Test IPv6 large packet
timeout (6.014s)
http://mtu1280.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels. Double check to make sure that ICMPv6 Type 2 ("Packet Too Big") messages are not filtered by your firewall.
Test if your ISP's DNS server uses IPv6
ok (2.013s) using ipv4
http://ds.v6ns.vm3.test-ipv6.com/ip/?callback=?
(This is bonus credit)
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.
Find IPv4 Service Provider
ok (1.695s) using ipv4 ASN 51167
http://ipv4.lookup.test-ipv6.com/ip/?callback=?&asn=1
Attempts to identify what Internet Service Provider you use for IPv4. This may be different from the marketing name you see in your local market; or may reflect a previous company name. The name shown reflects how it is known in the network operator community.
Find IPv6 Service Provider
timeout (12.962s)
http://ipv6.lookup.test-ipv6.com/ip/?callback=?&asn=1
Attempts to identify what Internet Service Provider you use for IPv6. When the IPv4 name and the IPv6 name don't match, it may suggest that you're using a tunnel; or some form of third party provider for IPv6.
不使用 VPN 连接进行相同测试：
Test with IPv4 DNS record
ok (0.311s) using ipv4
http://ipv4.vm3.test-ipv6.com/ip/?callback=?
Fetches an object that has just an A record in DNS. This is expected to use IPv4. IPv6-only users might still reach this, if their provider has employed a NAT64/DNS64 or proxy solution.
Test with IPv6 DNS record
ok (0.349s) using ipv6
http://ipv6.vm3.test-ipv6.com/ip/?callback=?
Fetches an object that has just an AAAA record in DNS. This is expected to use IPv6. Users not yet on the IPv6 Internet are likely to see this fail. As long as it fails quickly, it will be OK - for now.
Test with Dual Stack DNS record
ok (0.971s) using ipv6
http://ds.vm3.test-ipv6.com/ip/?callback=?
This is the most important test. This verifies your browser can connect to a site that has both IPv4 and IPv6 records published. IPv4 only hosts should connect fine (using IPv4).
If this test fails or times out, you can expect major problems as publishers start offering their sites on IPv6.
Test for Dual Stack DNS and large packet
ok (1.999s) using ipv6
http://ds.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
Validates that you can connect to a dual-stack server (like the ds test); and that you can send/receive large packets on that connection. If this test times out for any reason, it indicates trouble for World IPv6 Day.
Test IPv4 without DNS
ok (1.428s) using ipv4
http://216.218.228.115/ip/?callback=?
This will try connecting with a literal IPv4 numeric address. This should work for most people, unless they are running IPv6-only. If the first test worked, but this fails, it likely confirms your provider is using NAT64/DNS64; you'll need to only try connecting using hostnames instead of numeric IP addresses.
Test IPv6 without DNS
ok (2.009s) using ipv6
http://[2001:470:1:18::115]:80/ip/?callback=?
This will try connecting with a literal IPv6 hexadecimal address. The primary purpose of this test is to separate out your connectivity on IPv6 from your ability to fetch DNS for it. A secondary purpose is to see if you have Teredo enabled; some systems may only use Teredo when an IPv6 address is in the URL.
Test IPv6 large packet
timeout (16.053s)
http://mtu1280.vm3.test-ipv6.com/ip/?callback=?&size=1600&fill=xxx...xxx
Validates that IPv6 requests with large packets work. If this test times out, but other IPv6 tests work, it suggests that there may be PMTUD issues; possibly involving IP tunnels. Double check to make sure that ICMPv6 Type 2 ("Packet Too Big") messages are not filtered by your firewall.
Test if your ISP's DNS server uses IPv6
ok (3.017s) using ipv6
http://ds.v6ns.vm3.test-ipv6.com/ip/?callback=?
(This is bonus credit)
This is a test of your ISP's resolver (instead of a test of your host). If this test passes, your DNS server (often run by your ISP) is capable of reaching IPV6-only DNS authoritative servers on the Internet. This is not critical (at this time) for you to reach sites via IPv6.
Find IPv4 Service Provider
ok (0.247s) using ipv4 ASN 44244
http://ipv4.lookup.test-ipv6.com/ip/?callback=?&asn=1
Attempts to identify what Internet Service Provider you use for IPv4. This may be different from the marketing name you see in your local market; or may reflect a previous company name. The name shown reflects how it is known in the network operator community.
Find IPv6 Service Provider
ok (0.204s) using ipv6 ASN 44244
http://ipv6.lookup.test-ipv6.com/ip/?callback=?&asn=1
Attempts to identify what Internet Service Provider you use for IPv6. When the IPv4 name and the IPv6 name don't match, it may suggest that you're using a tunnel; or some form of third party provider for IPv6.
ICMP 情况：
为了检查 PMTUD 的情况，我使用这些命令检查了服务器上的 icmptypes，并且“数据包太大”icmptype 似乎没有被阻止。
firewall-cmd --get-icmptypes
#firewall-cmd --info-icmptype=packet-too-big
packet-too-big
destination: ipv6
#firewall-cmd --query-icmp-block=packet-too-big
no
此外，本文正如评论中提到的，我在客户端和服务器上运行了 tcpdump，但没有看到任何包裹太大痕迹。另一方面，我唯一一次看到的错误是数据包太大当我连接到没有--无dtls选项。如下所示：
Failed to read from SSL socket: The transmitted packet is too large (EMSGSIZE).
Failed to recv DPD request (-5)
答案1
ULA 不适用于路由到互联网。它会在离开您的网络之前被丢弃，从而导致糟糕的用户体验。
从 ocserv 配置中删除 ULA 网络，并将其替换为/64 地址计划中的一个或多个。这些子网仅适用于 VPN。例如：
ipv6-network = 2001:db8:3025:1407::/64
在具有 Web 浏览器的 VPN 客户端上，使用双栈测试进行验证，例如 http://test-ipv6.com/
您对实施 IPv6 的想法是正确的。IPv6 感知对于保护您的网络是必不可少的。有些网络需要 IPv6。没有 NAT 的 IPv6 堆栈是一种更简单的设计。