قاعدة المعرفة

How does the C-Servers ExtraNAT service work?

So far, all C-Servers offers had been split in three families:
- a family of NAT IPv4 servers and products, called MultiNAT, with a single IPv4 NAT guaranteed, IPv6 possible (not guaranteed, upstream-dependant) and a free-range of 150 opened ports;
- a family of hybrid IPv6 and transitional 6-to-4 servers and products, called MultiVPS, which is our core offer, comprising a single IPv6 guaranteed and a dynamic IPv4 address serving HTTP/HTTPS access to the Internet where IPv6 is not supported;
- a family of previously-used servers and products, called VPS Outlet, similar to MultiVPS, more performance-limited, but with competitive pricing, perfect for undemanding users.

Effective from September 29th, and especially after some uptime and other technical difficulties in August with the port forwarding services at the Zeta2 Finland server, C-Servers will transfer all MultiNAT customers to the MultiVPS service, and in turn, the MultiVPS service will have an entire new network access available: the C-Servers ExtraNAT, included in the MultiVPS core service for all current customers at Zeta3 Finland (65.108.71.165) and Zeta1 Germany (116.202.80.221), and free of any extra charge for existing customers.

This is being improved and optimized on the next 1-2 days, meaning that it's recommended for you to wait up until October 2nd to start NAT deployments, as we are finalizing some procedures. As of September 30th, 2024, 19h05, this is the current status of this new implementation:

DNS64, NAT64, NAT46: All fully implemented and working on the Zeta3 Finland and the Zeta1 Germany.

What are the advantages of the ExtraNAT service?

Actually, several of them. It's a service that makes IPv4 easier, faster, and seamless:

• All DNS queries have started to be done on the same server. This is possible through Bind9. Lower latency, therefore, to use the service.
• All TCP/UDP queries, above port 10000, are now done via Tayga and Nginx. Tayga acts as a regular NAT64; Nginx acts as a reverse proxy, or NAT46. Outbound ports are unlimited in scope and request and directly mapped one-to-one with the external, fixed IP, since they are processed at the Network layer 3; inbound ports, executed by Nginx and recieved from the fixed IP, are simple and easy to calculate, pre-allowed up to 10 without any intervention necessary on your end, and allocated on a per-IPv6-address basis. Traffic bandwidth is exactly the same one that you already had on your VPS, since it's the very same server, no extra latency or traffic consumption are added.
• In the event some component is not working as it should (DNS64 or NAT64), the regular fallback via the NAT64 public service is still implemented. It's hard to occur, but it may happen. However, Nginx will always stay unaffected, ensuring inbound port forwarding principles to the VPS are executed as expected for a reverse proxy. Previously, we employed HAProxy - we've chosen a different, resilient solution, this time.
• The external IPv4 for this NAT service is exactly the same as the dedicated server's IPv4. No more, no less. 

Therefore, this is a NAT in full right, and the first dual-stack offer C-Servers brings, actually a technical first on the SolusVM 2 platform, contouring around the lack of NAT IPv4 on the platform, and also a technical first for NAT46 on any hosting provider, worldwide. This is the result of a complex configuration process, including automatic scripting of Nginx, optimization of bind9 and Tayga, and their respective implementations.

How is HTTP/HTTPS handled on this configuration?

This is the only area that remains as before on the MultiVPS, although with some changes: if you wish to use ports 80/443 for web hosting or other HTTP/HTTPS traffic, this is still handled from your VPS with both IPv6 and the NAT64/DNS64, the sole difference being you'll have a fixed IPv4 now (on the main resolver).

You shall use any dual-stack CDN, for example Cloudflare Tunnels or BunnyCDN, in order to have a hosting panel included, and should also be ready to have a backup solution if and when the fixed IPv4 of the main resolver is down and prevents you from accessing your panel - usually accessing via VNC at localhost:your-panel-port through a GUI fixes this difficulty. Needless to say, having an IPv6-preferred panel is preferential, but not mandatory. 

I heard right? TCP and UDP supported?

Exactly. Tayga and Nginx are configured to support both. When you know the sender/reciever IPs, it's easy to allow it. This is a direct advantage compared to other providers.

How do I calculate my ports?

IPv6 is a hexadecimal system, meaning that, past the usual allocation 0-9 on a given IP, you also have A-F.  Our IPv6s are usually given sequentially, but, due to the Nginx implementation being made later, port allocation is organized slightly differently to the IPv6 allocation. We'll now explain.

An IPv6 address can range at its end, e.g. f800-f899, and then go f80a, f80b, etc. The "Decimal Range" shows the IP order you are located at from a normal standpoint, from 1 to 255, and it's used in combination with hexadecimal values. Check this explanatory table:

An address ending on, for example, f80e::1, for example, is the 14th address on the decimal range;
Our ports allocation starts at 10000, meaning that each block has ports 10000-10009, 10010-10019, etc;
Therefore, you multiply to have your port allowance:

14 x 10 = 140
Port Start: 10000
Your Block of Ports: 10000+140 = 10140-10149

Let's assume a harder example, one earlier on the table, for example an address ending on f8d1::1.

Per the previous table, this is the 209th address on the list (Decimal Range says "d0-df" does the range 208-223, therefore d1 is one address later than d0, making it the 209th address);
Remember the port allocation starts at 10000;
Therefore, you multiply to have your port allowance:

209 x 10 = 2090
Port Start: 10000
Your Block of Ports: 10000+2090 = 12090-12099.

You always locate the address on the hexadecimal scale first, and then count to the equivalent on the decimal scale. This way, you'll always know in which order your IP address is, and therefore, which ports you have available. The rule is the same regardless of the end having numbers only, numbers+letters or letters only.

Inbound and outbound ports usage

For outbound purposes, you don't need to worry on which ports you'd hit, since they're all unlimited, start from port 10000, and the request is routed by Jool, mapped directly to the very same port on your VPS unless it's entirely impossible at the server level (because someone else occupied that port). It's the same exact system as the previous MultiNAT's port distribution, but you don't need to notify us of the ports nor anyone else, by default they're available.

Solely on inbound ports will you have any technical, NAT-like limit (check above your port range), but still with no need to configure anything. This is why we call this solution ExtraNAT: it's simple, effective, automatic and direct.

Naturally, should you have any question on which port you're allowed, you can always send us a ticket and we'll answer your port range. This also means more purchased IPv6s allow you extra port range, at 10 extra ports per IPv6 (but also mean you need to do more routing/internal VPS work to include all of those IPv6s on your VPS, of course).

Can I have additional ports?

For organization purposes and to avoid stressing Nginx too much, each IPv6 address has a maximum of 10 ports allowed at the port interval with the reasoning described above. Purchasing extra IPv6s gives additional ports on a per /64 basis.

How will I know if the NAT64 is down?

Inbound port forwarding will always work, because it's managed by a separate application altogether, but outbound port forwarding to IPv4 services may not work especially if the IP address on the other end is fixed to the dedicated server IPv4. If it's defined as dynamic/changeable, depending on the application and the TCP allowance for the NAT64 public service, you may not even notice. We'll periodically monitor that service on Tayga and ensure the service is up and correctly configured, as it should.

What will happen to the Zeta2 Finland server?

Due to our lack of management tools at the upstream, which have caused extra downtime, and the fragility of the solution with Virtualizor under some very particular questions (of which HAProxy and iptables are the biggest examples), the server will be discontinued, starting from October 1st, 2024.