If you want to replace the original network with the ziti network in the existing network connection, in order not to affect the data transmission of the original business, you can add Linux Tunneller to control the access, but the access domain name and port are fixed and cannot be modified, so you need to write the same address to hostv1 and interceptv1. I have tried ipv4 success, and the ipv6 address is not available.Unable to access the service through the set ipv6 address
I'm not sure I understand what you mean. It sounds like you'd like to intercept an IPv6 address?
For example, if the previous service is an ipv6 access service, and I want to access it through the ziti network, but still use the original ipv6 access service method, then the name of interceptv1 needs to be set to the ipv6 address
It can be after intercepting the ipv6 address, it reaches the ipv6 service through the ziti network
Hello,
There is an issue to support intercepting ipv6 addresses, but we haven't gotten to it yet. Once intercepting ipv6 is possible, the intercepted ipv6 address would be forwarded to the hosting tunneler if the service enables address forwarding.
Does the issue I mentioned here describe the capability that you're looking for?
Hi scarething,
You mentioned not handling AAAA requests, but I can access the service through the Ziti network using the domain name. When I attempted to access the service using the IPv6 address mentioned by McGonagall666, it failed. Is this a problem with the DNS server? How can I resolve this?
Intercepting by hostname is actually just a layer on top of ipv4 intercept. The tunneler’s dns server resolves any hostnames in the intercept.v1 address list to ipv4 addresses in the dns ip range (100.64/10 by default). Those ipv4 addresses are internally mapped to the associated services as they are assigned, and the routing table is set up to send those ips to the tunneler’s tun device.
DEBUG tunnel-sdk:ziti_tunnel.c:320 ziti_tunneler_intercept() intercepting address [tcp:2768:8631:c02:ffc9::1308/128:9000] service [svc] shows successful interception, followed by a 'File exists' error and update failure. Finally, accessing via the IPv6 domain name works fine, but accessing through http://[2768:8631:c02:ffc9::1308]:9000/ results in a timeout, while using the IPv4 domain name and address works normally. What could be the reason? Is there a failure in storing the IPv6 address in the tunneler’s tun device？
The tunnelers do not currently support intercepting ipv6 addresses. Parts of the code path are able to understand and handle ipv6 addresses, but other parts are not.
What are the errors that you mention (file exists and update)? Can you share more complete logs and your service configurations?
Thank you for your insights. Is "parts of the code path are able to handle IPv6 addresses" the reason why I can access the service via domain names? If I directly access using the IP address to bypass the DNS resolver, the logs above mention successfully intercepting the IPv6 address. Was the interception really successful? If I want to access the service using http://[2768:8631:c02:ffc9::1308]:9000/ , where in the code should I make changes to enable IPv6 address interception?
No, as I described above the hostnames in the intercept.v1 address list are resolved to ipv4 addresses by the tunneler's DNS server. You can see this for yourself if you ping the hostname. The tunneler then intercepts the ipv4 connection that the client application initiates after it resolves the hostname.
There are many places that are subtly affected by ip6, I think it would be too hard to explain everything in a discourse post. I'm guessing you'd need to start with lookup_intercept_by_address in intercept.c to get it working for ipv6 addresses.
I took a quick look at the ipv6 comparison logic and noticed an issue with the function that converts ipv6 addresses from the format that the lwip TCP/IP stack provides and the format that we use to store intercept addresses. This fix might be enough to get you going with ipv6 intercepts if you're using ziti-edge-tunnel.
By the way, the above mentioned fix is in ziti-edge-tunnel v1.0.2.
I noticed the conversion of IPv6 addresses retrieved from lwIP TCP/IP to ziti_addr in instance.c 's to_address function, and then further conversion of ziti_addr to tunnel_addr in the logs. However, when I tried accessing http://[2768:8631:c02:ffc9::1308]:9000/ , it timed out.route: bad address: 2768:8631:c02:ffc9::1308/128Before that, the domain name was resolved and assigned an IPv4 address stored in cache.
I'm guessing you are running on macOS from the "bad address" error message. I thought you were running on Linux. ipv6 intercept on macOS will require at least a few more changes:
- route command is not called correctly for ipv6 routes on macOS.
- utun device does not have an ipv6 address assigned on macOS.
I'll update the GitHub issue accordingly
Yes, I tried it with linux lastday. Can version 1.0.2 intercept ipv6 address in linux? And I failed to use ipv6 address to visit svc,is it still an interception problem?
Yes, you should be able to intercept ipv6 with ziti-edge-tunnel v1.0.2 on Linux. Here's an excerpt of a successful intercept:
[ 0.776] TRACE tunnel-sdk:tunnel_tcp.c:366 recv_tcp() received segment src[tcp:FDDE:3A82:F7EB:2329:F130:720E:B6DF:5656:39394] dst[tcp:2768:8631:C02:FFC9::1308:22] flags[SYN]
[ 0.776] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 22 to range 22
[ 0.776] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 22 matches range 22 with score 0
[ 0.776] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 22 is best match so far
[ 0.776] DEBUG tunnel-sdk:tunnel_tcp.c:116 new_tcp_pcb() snd_wnd: 8445, snd_snd_max: 8445, mss: 1440
[ 0.776] DEBUG tunnel-sdk:tunnel_tcp.c:429 recv_tcp() intercepted address[tcp:2768:8631:C02:FFC9::1308:22] client[tcp:FDDE:3A82:F7EB:2329:F130:720E:B6DF:5656:39394] service[ssh]
[ 0.776] VERBOSE tunnel-cbs:ziti_tunnel_cbs.c:284 ziti_sdk_c_dial() ziti_dial(name=ssh)
[ 0.776] DEBUG tunnel-cbs:ziti_tunnel_cbs.c:349 ziti_sdk_c_dial() service[ssh] app_data_json[181]='{"connType":null,"dst_protocol":"tcp","dst_ip":"2768:8631:C02:FFC9::1308","dst_port":"22","src_protocol":"tcp","src_ip":"FDDE:3A82:F7EB:2329:F130:720E:B6DF:5656","src_port":"39394"}'
If you're using 1.0.2 on Linux and not able to intercept ipv6, I'll need to see your (trace) logs and service configurations to get an idea of what's going wrong.
(3661)[2024-06-17T08:46:29.417Z] TRACE tunnel-sdk:tunnel_udp.c:194 recv_udp() received datagram src[100.64.0.1:49520] dst[100.64.0.2:53]
(10834)[2024-06-17T02:24:26.866Z] VERBOSE tunnel-sdk:intercept.c:130 port_match() matching port 53 to range 53
(10834)[2024-06-17T02:24:26.866Z] VERBOSE tunnel-sdk:intercept.c:133 port_match() port 53 matches range 53 with score 0
(10834)[2024-06-17T02:24:26.866Z] VERBOSE tunnel-sdk:intercept.c:135 port_match() port 53 is best match so far
(10834)[2024-06-17T02:24:26.866Z] DEBUG tunnel-sdk:tunnel_udp.c:269 recv_udp() intercepted address[udp:100.64.0.2:53] client[udp:100.64.0.1:49520] service[ziti:dns-resolver]
(10834)[2024-06-17T02:24:26.866Z] DEBUG tunnel-cbs:ziti_dns.c:234 on_dns_client() new DNS client
(10834)[2024-06-17T02:24:26.866Z] DEBUG tunnel-sdk:ziti_tunnel.c:221 ziti_tunneler_dial_completed() ziti dial succeeded: client[udp:100.64.0.1:49520] service[ziti:dns-resolver]
(21180)[2024-06-17T05:31:14.316Z] INFO tunnel-cbs:ziti_tunnel_cbs.c:409 new_ziti_intercept() creating intercept for service[svc] with intercept.v1 = {"addresses":["2768:8631:c02:ffc9::1308","192.162.6.3"],"dialOptions":{"connectTimeoutSeconds":0},"portRanges":[{"high":80,"low":80},{"high":9000,"low":9000}],"protocols":["tcp"],"sourceIp":""}
Here is the linux logs.
Thanks. The logs you shared show that the tunneler has received the service configuration from the controller and is ready to intercept connections. Can you share the messages that are logged when you attempt a connection? They will look similar to the ones I posted above, starting with:
received segment src[tcp:FDDE:3A82:F7EB:2329:F130:720E:B6DF:5656:39394] dst[tcp:2768:8631:C02:FFC9::1308:22] flags[SYN]
Also what does the associated host.v1 configuration look like?
Thanks
(3351)[2024-06-18T06:07:43.159Z] DEBUG ziti-edge-tunnel:utils.c:33 run_command_va() system(ip -6 link set ziti1 up) returned 0
Error: inet6 prefix is expected rather than "100.64.0.1".
(3351)[2024-06-18T06:07:43.159Z] ERROR ziti-edge-tunnel:utils.c:31 run_command_va() cmd{ip -6 addr add 100.64.0.1 dev ziti1} failed: 256/0/Success
(3351)[2024-06-18T06:07:43.159Z] DEBUG ziti-edge-tunnel:utils.c:33 run_command_va() system(ip -6 addr add 100.64.0.1 dev ziti1) returned 256
(10551)[2024-06-17T02:23:13.623Z] DEBUG tunnel-sdk:ziti_tunnel.c:320 ziti_tunneler_intercept() intercepting address[tcp:2768:8631:c02:ffc9::1308/128:80] service[svc]
(10551)[2024-06-17T02:23:13.623Z] DEBUG tunnel-sdk:ziti_tunnel.c:320 ziti_tunneler_intercept() intercepting address[tcp:2768:8631:c02:ffc9::1308/128:9000] service[svc]
(10551)[2024-06-17T02:23:13.623Z] INFO tunnel-cbs:ziti_tunnel_ctrl.c:727 on_service() starting intercepting for service[svc]
(10551)[2024-06-17T02:23:13.623Z] VERBOSE ziti-edge-tunnel:ziti-edge-tunnel.c:1235 on_event() =============== ztx[/home/bean/run/sszg12.json] service event ===============
(10551)[2024-06-17T02:23:13.623Z] TRACE ziti-edge-tunnel:instance.c:272 to_address() IP address: 2768:8631:c02:ffc9::1308
(10551)[2024-06-17T02:23:13.623Z] INFO ziti-edge-tunnel:ziti-edge-tunnel.c:1291 on_event() =============== service event (added) - svc:5Av8PBOp0hdXWnyLwQPhW8 ===============
(2491)[2024-06-18T01:31:34.787Z] DEBUG ziti-sdk:ziti_ctrl.c:726 ctrl_paging_req() ctrl[www.ipv6test-ctrl.com] starting paging request GET[/current-identity/edge-routers]
(2491)[2024-06-18T01:31:34.787Z] VERBOSE ziti-sdk:ziti_ctrl.c:731 ctrl_paging_req() ctrl[www.ipv6test-ctrl.com] requesting /current-identity/edge-routers?limit=25&offset=0
(2491)[2024-06-18T01:31:34.787Z] VERBOSE ziti-sdk:ziti_ctrl.c:143 start_request() ctrl[www.ipv6test-ctrl.com] starting GET[/current-identity/edge-routers?limit=25&offset=0]
(2491)[2024-06-18T01:31:34.787Z] VERBOSE ziti-sdk:ziti_ctrl.c:143 start_request() ctrl[www.ipv6test-ctrl.com] starting GET[/current-api-session/service-updates]
(2491)[2024-06-18T01:31:34.999Z] VERBOSE ziti-sdk:ziti_ctrl.c:178 ctrl_resp_cb() ctrl[www.ipv6test-ctrl.com] received headers GET[/current-identity/edge-routers?limit=25&offset=0]
(2491)[2024-06-18T01:31:34.999Z] DEBUG ziti-sdk:ziti_ctrl.c:334 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] completed GET[/current-identity/edge-routers?limit=25&offset=0] in 0.211 s
(2491)[2024-06-18T01:31:34.999Z] DEBUG ziti-sdk:ziti_ctrl.c:351 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] received 1/1 for paging request GET[/current-identity/edge-routers]
(2491)[2024-06-18T01:31:34.999Z] DEBUG ziti-sdk:ziti_ctrl.c:363 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] completed paging request GET[/current-identity/edge-routers] in 0.211 s
(2491)[2024-06-18T01:31:35.000Z] VERBOSE ziti-sdk:ziti_ctrl.c:178 ctrl_resp_cb() ctrl[www.ipv6test-ctrl.com] received headers GET[/current-api-session/service-updates]
(2491)[2024-06-18T01:31:35.000Z] DEBUG ziti-sdk:ziti_ctrl.c:334 ctrl_body_cb() ctrl[www.ipv6test-ctrl.com] completed GET[/current-api-session/service-updates] in 0.212 s
(2491)[2024-06-18T01:31:35.000Z] VERBOSE ziti-sdk:ziti.c:1272 check_service_update() ztx[0] not updating: last_update is same previous (2024-06-18T00:42:42.610Z == 2024-06-18T00:42:42.610Z)
(2491)[2024-06-18T01:31:35.000Z] VERBOSE ziti-sdk:ziti.c:1302 ziti_services_refresh() ztx[0] scheduling service refresh 10 seconds from now
received segment src[tcp:FDDE:3A82:F7EB:2329:F130:720E:B6DF:5656:39394] dst[tcp:2768:8631:C02:FFC9::1308:22] flags[SYN]I see that you are using an IPv6 address with the TCP protocol.
(3378)[2024-06-18T09:21:26.713Z] DEBUG tunnel-sdk:tunnel_udp.c:270 recv_udp() intercepted address[udp:100.64.0.2:53] client[udp:100.64.0.1:34960] service[ziti:dns-resolver]
I default to using 53/udp. My DNS server IP is intercepted, not the IP address in intercept.v1. After accessing the service via IP address, only the DNS server IP is intercepted. Is this because I have enabled UDP? How should I modify this?
Are you modifying the source? I don't think the committed source ever uses ip with the "-6" option.