How to get IPv4 connectivity on an IPv6 only VPS

readme.md

Some hosting providers like scaleway allows to remove the IPv4 from the VPS in order to save 1€/month but doing this will result in losing connectivity to the "IPv4 world".
Or you may have ordered a VPS that only has IPv6 connectivity and you want to access to a resource only accessible from the "IPv4 world".
Here is how to gain your access back to the "IPv4 world".

Change your name servers(s) to DNS64 name servers(s)

Note: You may deploy your own DNS64 & NAT64 server on a separate server by following this tutorial (untested): https://packetpushers.net/nat64-setup-using-tayga/.
Note²: You may find a explanation of what is NAT64 and DNS64 on Wikipedia.

1. Choose a/multiple DNS64 public server(s) that has/have its own NAT64 public service from this list:

Nameserver	Provider	Location	Quality of internet connectivity
2001:67c:2b0::4	trex.fi	Finland (Europe)	Good
2001:67c:2b0::6	trex.fi	Finland (Europe)	Good
2001:67c:27e4::64	go6lab.si	Slovenia (Europe)	Good
2001:67c:27e4::60	go6lab.si	Slovenia (Europe)	Medium

You may find another good list of NAT64/DNS64 servers: https://nat64.xyz/

2. Replace the current name servers(s) of your /etc/resolv.conf file (old way) or in the configuration file of your network manager with the DNS64 name servers(s) that you chosen earlier.
   If you don't know how to change the name servers then search on your prefered search engine a tutorial on how to change the DNS servers of your Linux distribution.
   If you don't want to bother with configuring your network manager then you may deny any access to the /etc/resolv.conf file by using chattr +i /etc/resolv.conf after modifying the file.

Add real IPv4 connectivity for applications that works only in IPv4 (optional)

Note: This part of the tutorial only works on Linux distributions that has systemd or Upstart as a service manager (Debian, Ubuntu, CentOS and so on). If you are experienced enough you may "translate" the systemd service file to your service manager.
Note²: If you are using ArchLinux you don't need to follow this part of tutorial because there is a clatd package available on AUR: https://aur.archlinux.org/packages/clatd-git/.

1. Install make, git, cpan/perl, gcc and tayga from your package manager (Debian/Ubuntu : sudo apt-get install -y make git gcc tayga perl).
2. Clone the clatd Github repository using: git clone https://github.com/toreanderson/clatd.git
3. Change your current directory to the new directory called clatd: cd clatd.
4. Install clatd using sudo make install.
5. Install the required perl dependencies for clatd: cpan Net::IP Socket6 IO::Socket::INET6 Net::DNS.
6. Start clatd with sudo systemctl start clatd (systemd) or initctl start clatd (upstart).
7. Wait around 30 seconds then check if you have IPv4 connectivity using curl: curl -4 google.com.

Troubleshooting if case the curl command doesn't work

1. Execute systemctl status clatd and check if it say: This system already has IPv4 connectivity; no need for a CLAT.
2. If that's the case then add ExecStartPre=/bin/sh -c "sleep 30s && ip route del 0/0" after [Service] in the /etc/systemd/system/clatd.service file (this only works on systemd).
   If that's not the case then try to change the DNS64 nameserver with another one from the list above then restart clatd (sudo systemctl restart clatd) and if it still doesn't work then you are out of luck because your hosting provider doesn't support the NAT64 protocol.
3. Reload systemd and restart clatd: sudo systemctl daemon-reload && sudo systemctl restart clatd.
4. Check if you have IPv4 connectivity: curl -4 google.com.

Here there,

Thanks for your great tutorial first. I did what you said above, but still failed to the ip4 connectivity. Any ideas how to debug it? Thanks !
A startdust instance from scaleway

[root@v6instance ~]# systemctl status clatd
● clatd.service - 464XLAT CLAT daemon
     Loaded: loaded (/usr/lib/systemd/system/clatd.service; enabled; preset: disabled)
     Active: active (running) since Fri 2023-02-24 12:36:14 UTC; 1min 39s ago
       Docs: man:clatd(8)
    Process: 474 ExecStartPre=/bin/sh -c sleep 30s && ip route del 0/0 (code=exited, status=0/SUCCESS)
   Main PID: 568 (clatd)
      Tasks: 2 (limit: 1138)
     Memory: 24.8M
        CPU: 306ms
     CGroup: /system.slice/clatd.service
             ├─568 /usr/bin/perl -w /usr/sbin/clatd
             └─588 tayga --config /tmp/dTaM6rZ2Rd --nodetach

Feb 24 12:36:25 v6instance clatd[568]: Enabling Proxy-ND for 2001:bc8:1820:92:acfc:3c60:6378:0 on eth0
Feb 24 12:36:25 v6instance clatd[568]: Creating and configuring up CLAT device 'clat'
Feb 24 12:36:25 v6instance clatd[579]: Created persistent tun device clat
Feb 24 12:36:25 v6instance clatd[568]: Adding IPv4 default route via the CLAT
Feb 24 12:36:25 v6instance clatd[568]: Starting up TAYGA, using config file '/tmp/dTaM6rZ2Rd'
Feb 24 12:36:25 v6instance tayga[588]: starting TAYGA 0.9.2
Feb 24 12:36:25 v6instance tayga[588]: Using tun device clat with MTU 1500
Feb 24 12:36:25 v6instance tayga[588]: TAYGA's IPv4 address: 192.0.0.2
Feb 24 12:36:25 v6instance tayga[588]: TAYGA's IPv6 address: 2001:67c:2b0:db32:0:1:c000:2
Feb 24 12:36:25 v6instance tayga[588]: NAT64 prefix: 2001:67c:2b0:db32:0:1::/96
[root@v6instance ~]# curl -v -4 google.com
*   Trying 142.251.39.110:80...
^C
[root@v6instance ~]# curl -v google.com
*   Trying [2a00:1450:400e:802::200e]:80...
* Connected to google.com (2a00:1450:400e:802::200e) port 80 (#0)
> GET / HTTP/1.1
> Host: google.com
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.com/
< Content-Type: text/html; charset=UTF-8
< Date: Fri, 24 Feb 2023 12:38:16 GMT
< Expires: Sun, 26 Mar 2023 12:38:16 GMT
< Cache-Control: public, max-age=2592000
< Server: gws
< Content-Length: 219
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
< 
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host google.com left intact
[root@v6instance ~]# cat /etc/resolv.conf
nameserver 2001:67c:2b0::4
nameserver 2001:67c:2b0::6
nameserver 2001:67c:27e4::64
nameserver 2001:67c:27e4::60
[root@v6instance ~]# 

May I ask Why Google Public DNS64 is not on the list? https://developers.google.com/speed/public-dns/docs/dns64

May I ask Why Google Public DNS64 is not on the list? https://developers.google.com/speed/public-dns/docs/dns64

Because it doesn't provide NAT64 connectivity, only the DNS resolution: https://en.wikipedia.org/wiki/NAT64

Thanks i was looking for something like this!

@tonywangcn - Do you figured it out?
I have the same issue ⌛