Base de conhecimento

IPv4 NAT via NAT46 - Technical specifics

The IPv4 NAT46-like solution we are implementing on MultiVPS forwards the packets directly at Unix/Linux socket level, between IPv4 and IPv6. It's actually one of the simplest solutions around. There are some known incompatibilities with this technical solution:

• telnet, ssh and similar tools won't work. The socat tool - or the way your tool executes - does not support them in a transitional IPv4-to-6 state. Any CLI-level access must be done via the C-Servers Remote service, or directly accessed from any IPv6 access, or used via VNC/RDP. No other ways are supported.
• UDP forwarding may occasionally fail. While we separate ports in order to allow for UDP usage, these are packets that are routed within the same server. In moments of peak usage, packet loss could theoretically occur. Also, for this reason, ensure only non-critical usage is executed via UDP.
• VPN usage will probably not work adequately. The socat tool forks a TCP4 connection to insert it as a TCP6 connection. Continuous streams may work, but less used streams may found themselves occasionaly closing. Either way, VPN usage was already solely supported over IPv6-to-IPv6 (with IPv4 added connectivity).
• In order to access web hosting panels (if those or your access solely supports IPv4), you will need to use localhost:port (for the port of your correspondent web hosting panel) and write it using a browser running locally, on your VPS. Directly accessing from the default port won't work with all panels, and changing the default port to one within the port range may or may not work. Wildcard certificates may also not be supported over IPv4-relayed streams - if you find that error, either use separate certificates, or issue those solely over IPv6. Either way, this type of usage was already recommended to be executed with Cloudflare reverse-proxying for HTTP/HTTPS with an endpoint IP as IPv6.
• Other types of usage that do not form either a continuous stream of packets, nor a sent-and-stop stream of packets, and instead rely on a periodically-sent keep-alive packet will surely not be supported. 

The conundrum of 4-to-6 and returning via 6-to-4: things to keep in mind

Bidirectional communication, while now supported, will have several specifics in mind:

- to communicate from IPv6 to IPv4 successfully, your application must not only communicate at the specific port range, but also be IP version-agnostic (it must work with 4 and 6, and send unaltered packets that do not expect solely one of the two versions);

- your application may also need to be able to point an intermediary (your external IPv4 NAT) and the final IP, if it is fixed, because otherwise it may default to the IPv6 or entirely refuse to work;

- using an internal socat to map to an internal IPv4 will not create a major issue with IP version-agnostic applications, because both the implementations are socket-to-socket according to this:

Internal IPv4 » socat VPS-fork to IPv6 » Hybrid IPv6 »» socat global-listen IPv6-port »» catches traffic on IP+port »» socat forwards/forks to external public IPv4 »» routing via external IPv4.