Implement a two-way NAT virtual network card, nat virtual network card

Implement a two-way NAT virtual network card, nat virtual network card
Problem description and solution are still old problems. NAT configured through iptables in Linux cannot be used in two-way communication environments, you cannot configure a NAT rule to perform NAT on the traffic actively initiated in both directions. There are several solutions to this problem:
1. the NAT configuration of the two NAT rules iptables is to match and then execute a target. Therefore, a rule can only represent one conversion policy. To achieve "conversion from the source address of x data packets to y, to convert the target address of the data packet destined for y to x, two rules must be used. So why not use the two rules? Because the nat configuration of iptables is based on data streams, it only performs rule searches for the packet that creates the ip_conntrack struct. Therefore, when a stream has been created and data transmission is performed, adding a nat configuration is invalid.
Xtables-addons has a RAWNAT, which is no longer based on ip_conntrack, that is, it is based on data packets rather than data stream NAT. The problem is solved immediately, but because it is still a match-target rule, therefore, to implement bidirectional NAT, you must configure two rules.
2. writing a Netfilter HOOK to compile a Netfilter HOOK module is not difficult. I have written several articles by myself. However, the Netfilter framework intercepts data packets in the processing path of the protocol stack for check-matching/action. It checks each data packet passing through the protocol stack, that is to say, each data packet must be filtered by the HOOK function. When there are too many Netfilter hooks, the efficiency is greatly reduced.
3. Using dedicated virtual devices is a brand new concept. The xmit function of a virtual network card is as follows:

Static netdev_tx_t forward (struct sk_buff * skb, struct net_device * dev) {struct sdnat_struct * sdnat = netdev_priv (dev); unsigned int flags = sdnat-> flags; struct nat_entry * entry; entry = find_sdnat_policy (skb, flags); if (unlikely (! Entry) {goto xmit;} if (flags & SNAT) {do_trans_src (entry, skb);} else if (flags & DNAT) {do_trans_dst (entry, skb );} // at this time, skb dst imports data packets into the dst_entry of the NAT device. // to prevent cyclic routing, drop the data packets. NAT has been completed and skb_dst_drop (skb) has not been used ); // clear the mark, because the packet is generally imported into the NAT device through the mark policy route // This is also to prevent the circular route skb-> mark = 0; xmit: netif_rx_ni (skb); drop: kfree_skb (skb); return NETDEV_TX_ OK ;}

Do_trans_src/dst can be implemented using a function, which is used to make the interface clearer. The specific conversion is not much said. It is very simple. Modify the source address or target address of the IP header, and re-calculate the check code of L3 and L4.
The key is how to organize nat rules. I use a nat_entry to save each rule:

Struct nat_entry {struct hlist_node hash_list; _ be32 key1; // For SNAT, that is, the original IP address, and DNAT, that is, the IP address to be converted to _ be32 key2; // For SNAT, that is, the IP address to be converted, for DNAT, that is, the original IP address _ be32 hash;/The jhash_2words value of the data packet source IP address or the target IP address int flags ;};

The hash calculation is as follows:

static u32 keys_get_hash(__be32 key){    return jhash_2words(key, 0x01, 0x0);}

When the module is loaded, two virtual NICS will be created, one responsible for SNAT, the other responsible for DNAT, and the system will also have two sdnat_struct structures, one responsible for SNAT and the other responsible for DNAT:

struct sdnat_struct {    int flags;    struct net_device   *dev;    struct hlist_head entrys[1024];};

In Linux, You need to configure two policy routes:
A. import data packets sent from the internal network port to the SNAT Nic device for SANT;
B. import data packets from the Internet port to the Intranet port to the DNAT Nic device for DNAT.
In this way, two-way automatic conversion is enabled. No matter from which the data is first initiated, the source address of the data packet from x is converted to y, convert the destination address of the data packet to "x ". Is it similar to Cisco static NAT? Define inbound and outbound devices instead of filtering data packets by iptables match. I prefer to use procfs as a user interface because it facilitates shell operations:
Echo + 192.168.1.1 9.24.100.1>/proc/net/nat
After the preceding command is executed, a nat_entry will be added to the hash table shared by the two NICs, key1 is 192.168.1.1, key2 is 9.24.100.1, and in the SNAT Nic device, the skb iph-> saddr will be used as the hash, and then the table will match its key1, And the key2 will be taken out as the IP address to be converted, in the DNAT Nic device, the skb iph-> daddr will be used as the hash, and then the table will match the key2, And the key1 will be taken out as the IP address to be converted. To delete a rule, run the following command:
Echo-192.168.1.1 9.24.100.1>/proc/net/nat
The rule routing rules are as follows:
Ip rule add iif $ Intranet port table snat
Ip rule add iif $ external port table dnat
Ip route add 0.0.0.0/0 dev snat0 table snat
Ip route add 0.0.0.0/0 dev dnat0 table dnat
Is it more efficient to determine whether to use NAT Based on routing? Instead of matching each packet through the Netfilter module, you do not need to toss the inefficient ip_conntrack! It is worth noting that the xmit function of the sdnat device finally executes a netif_rx_ni, which is equivalent to re-injecting the data packet into itself. At this time, the iif of the data packet will no longer be an intranet or Internet port, but it is a real sdant virtual network card device, so when the packet arrives at the routing module again, it will not enter the sdnat device again.
In addition to the Netfilter framework, we can also use the Linux Nic device model to build another data packet filtering system. Yes, the idea is shown above. I have written several articles about how to save information in a route entry and obtain information by querying the route table. I used my own custom "route table ", the query method is still the longest prefix matching method, but the items saved in the route entry have changed. In this article, I show the idea of using a Linux native route table (not defined by myself) + a custom virtual Nic device to implement packet filtering. According to this idea, each target of iptables is a virtual network card device, and each series of matches is a route. The route entry of this route is to import data packets to the corresponding virtual network card device, the method of routing to match data packets will be more efficient than the Netfilter method, because it uses an efficient data structure such as hash/trie, instead of traversing several layers of linked lists like Netfilter.
In fact, is this idea quite new? No! Does the route entry have unreachable or blackhole? Aren't they exactly the REJECT and DROP of iptables?

Principles of Virtual Machine NAT

If you want to use VMWare to create an independent virtual server in the LAN to provide network services for LAN users, or create a virtual system isolated from other machines in the network, perform special debugging. At this point, the choice of the virtual system working mode is very important. If you choose an incorrect working mode, you will not be able to achieve the above purpose, and you will not be able to make full use of VMWare's role in network management and maintenance. Now let's move closer to three working modes of VMWare.

Understanding three working modes

VMWare provides three working modes: bridged (bridging mode), NAT (network address translation mode), and host-only (host mode ). To apply them properly in network management and maintenance, you should first understand the three working modes.

1. bridged (Bridging Mode)

In this mode, the Virtual Operating System of VMWare is like an independent host in the LAN, which can access any machine in the network. In the bridge mode, you need to manually configure the IP address and subnet mask for the virtual system, and also need to be in the same network segment as the host machine, so that the virtual system can communicate with the host machine. At the same time, because the virtual system is an independent host system in the LAN, You can manually configure its TCP/IP configuration information to access the Internet through the LAN gateway or router.

The relationship between a virtual system in the bridge mode and the host machine is like connecting two computers on the same Hub. If you want them to communicate with each other, You need to configure the IP address and subnet mask for the virtual system. Otherwise, the communication will fail.

If you want to use VMWare to create a virtual server in the LAN to provide network services for LAN users, you should select the bridge mode.

2. host-only (host Mode)

In some special network debugging environments, you must isolate the real environment from the virtual environment. In this case, you can adopt the host-only mode. In host-only mode, all virtual systems can communicate with each other, but the virtual system and the real network are isolated.

Tip: in host-only mode, the virtual system and the host machine system can communicate with each other, equivalent to the two machines connected through twisted pair wires.

In host-only mode, the TCP/IP configuration information of the virtual system (such as the IP address, gateway address, and DNS server) is created by VMnet1 (host-only) DHCP servers in the virtual network are dynamically allocated.

If you want to use VMWare to create a virtual system isolated from other machines in the network and perform some special network debugging, you can select the host-only mode.

3. NAT (network address translation mode)

The NAT mode enables the virtual system to use the NAT (Network Address Translation) function to access the public network through the network of the host machine. That is to say, you can use the NAT mode to access the Internet in a virtual system. In NAT mode, the TCP/IP configuration information of the virtual system is provided by the DHCP server of the VMnet8 (NAT) Virtual Network and cannot be modified manually, therefore, the virtual system cannot communicate with other real hosts in the local area network. The biggest advantage of using the NAT mode is that it is very easy for the virtual system to access the Internet. You do not need to configure any other configurations, but only need the host machine to access the Internet.

If you want to use VMWare to install a new virtual system, you can directly access the Internet without manual configuration in the virtual system. We recommend that you use the NAT mode.

Tip: The VMnet8 virtual network mentioned above in NAT mode, the VMnet1 Virtual Network in host-only mode, and the VMnet0 Virtual Network in bridged mode, they are all generated based on the automatic configuration of the vmwarevm and do not need to be set by the user. VMnet8 and VMnet1 provide DHCP services, while VMnet0 does not (figure 1 ).

Configure the virtual system working mode

In actual work, due to different user requirements and different debugging environment requirements ...... the remaining full text>

A two-way nat configuration problem, Cisco's

You can do it without changing it...
Ip nat outside source static XXX. XXX add-route

Then, how to convert it into your own research .. This command can achieve two-way conversion at the same time