Implement IP tunneling using Linux system commands to complete the upstream and downstream separation of packets

Currently there is a scenario where client A to Server B goes to get an HTTP request, in between a firewall, the firewall to monitor the GET request, if the discovery will be truncated.

Here are 2 requirements:

1, client A If the packet caught, found that the server is the IP of b

2, the server side if turn, found that the connection is client a

3, if there is a transit server, can not withstand too much pressure

As a result, a cannot use the normal VPN service to reach B, because after the normal VPN service, Server B sees the IP address of the VPN server instead of the IP address of client A.

Consider the use of IP tunneling here, only the user's upstream request through the IP tunnel to the outside of the firewall, so the pressure on the relay device is not very small, because the general upstream request volume is very low.

Note: This only verifies that the process is going through, so there is no encryption of the IP tunnel.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M00/80/5F/wKiom1c-v8rSOpnmAACEmNajaVc971.jpg "title=" IP tunnel. jpg "alt=" wkiom1c-v8rsopnmaacemnajavc971.jpg "/>

Now 3 servers, 10.0.2.244 (client A, public address 103.250.226.148), 10.0.2.201 (in transit a), 10.0.3.29 (in transit B, public network address does not matter), Server B (one is Baidu server, 61.135.169.121, the other is 10.0.2.26)

Among them, in transit A and transit machine B respectively in the firewall 2 side.

IP Tunnel to Baidu server

We operate on 10.0.2.244.

Route add 61.135.169.121 netmask 0.0.0.0 GW 10.0.2.201

Will Baidu address point to the transfer a

Route add 10.0.2.26 netmask 0.0.0.0 GW 10.0.2.201

Point 10.0.2.26 to Medium transfer a

Do the operation on the 10.0.2.201

IP tunnel Add ethn mode IPIP local 10.0.2.201 remote 10.0.3.29

Ifconfig ethn 40.200.20.70

Build an IP tunnel, where 40.200.20.70 is written in a haphazard way, but it's only used internally.

Route add-host 60.70.100.100 Dev ethn

Route the tunnel, 60.70.100.100 is the false IP on the other side of the tunnel

Route add-host 61.135.169.121 Dev ethn

Point the Baidu address to the tunnel

Route add-host 10.0.2.26 Dev ethn

Point 10.0.2.26 to the tunnel

Do the operation on the 10.0.3.29

IP tunnel Add ethm mode IPIP local 10.0.3.29 remote 10.0.2.201

Ifconfig Ethm 60.70.100.100

Build an IP tunnel, where 60.70.100.100 is written in a haphazard way, but it's only used internally.

Route add-host 40.200.20.70 Dev ethm

Tunnel routing, 40.200.20.70 is the false IP on the other side

Route add-host 103.250.226.148 Dev ethm

Route add-host 10.0.2.244 Dev ethm

It's a bit strange here, if I don't put the IP of client A in, I don't forward it, it's possible that I didn't configure

/etc/sysctl.conf inside Net.ipv4.ip_forward = 1 reason, if not configured, then the source IP point to the route, you can forward the packet, the specific logic I do not understand, the principle of routing also need to learn.

So now let's do a little operation.

Ping 60.70.100.100 on Transit A, received a response, stating that the IP tunnel was established successfully.

Above the client 10.0.2.244

wget http://61.135.169.121/--header= ' Host:www.baidu.com '-o 1.txt--bind-address= ' 103.250.226.148 '

wget http://10.0.2.26/200.php--header= ' Host:www.baidu.com '-o 1.txt--bind-address= ' 10.0.2.244 '

can receive an answer.

By grasping the packet can be found, upstream package, all from the gateway 10.0.2.201 out, while the downlink packet, directly by the network card charge.

Through this configuration, we successfully realized the upstream and downstream separation function.

Here are 2 questions,

Why not just configure client A to be in transit a, because I found that if there are 2 NICs on the machine, When listening to bind 0.0.0.0, theoretically can receive all network card data, but actually found that if the same five-tuple, whether TCP data or UDP data, from the network card a sent to the data, if the answer from the NIC B back, then the protocol stack is not receiving packets. If possible the following data (source IP port, destination IP port, process number, protocol number) are the same, then the first time from which network card out, the future data will be the network card is responsible for. So we had to transfer a in Taichung.

wget http://61.135.169.121/--header= ' Host:www.baidu.com '-o 1.txt--bind-address= ' 103.250.226.148 '

Here in wget, the IP address is bound to the IP of the public network and then routed through the

Route add 61.135.169.121 netmask 0.0.0.0 GW 10.0.2.201

The packet is thrown directly to the in transit A, the future received the original station data, or received to the public network card, so that the 10.0.2.244 network card will not be used to, but also to avoid the return of the text is not on a network card, resulting in the problem of receiving packets.

Second, this IP tunnel is not encrypted, want to encrypt also need to use IPSec to implement, there is no specific research, in addition to the router's L2L function can implement the encrypted IP tunnel, using a router more cost-effective than the server.

Expand

If you do not use a third-party tool, you can consider modifying the Linux kernel and simply encrypt the upstream data to decrypt it.

The specific code inside the NET/IPV4/IPIP.C, the specific function is Ipip_tunnel_xmit, the packet is IPIP_RCV.

can refer to

Http://blog.chinaunix.net/uid-26321024-id-2954317.html

1. Registering a pseudo-device

static const struct Net_device_ops Ipip_netdev_ops = {

. Ndo_uninit = Ipip_tunnel_uninit,

. Ndo_start_xmit = Ipip_tunnel_xmit,

. Ndo_do_ioctl = Ipip_tunnel_ioctl,

. NDO_CHANGE_MTU = Ipip_tunnel_change_mtu,

};

Tunnel peer IP addresses are stored in Ip_tunnel->param (Ip_tunnel_param)

2. Contract

Ipip_tunnel_xmit:

1) packets after tunnel can no longer be routed to this tunnel

2) SKB may be reassigned

3) directly in front of the original IP header with an IP header, the constant is 20 bytes. Move Network_header and Transport_header.

4) Call Ip_local_out after finish, will be nf_reset before. Indicates a two-time IP stack, over two netfilter chain

3. Receiving Package

IP_RCV-Ip_local_deliver_finish will find L4 layer handler, processing RCV

For Ipip, go to IPIP_RCV (Ipip_handler registered in Xfrm_tunnel), Ipip_init will register

1. Move Network_header and Transport_header to the beginning 20 bytes off, IPIP head set to Mac_header, Skb->dev point Tunnel->dev

2. Nf_reset. Skb->protocol (L2 protocol) set to ETH_P_IP

3. Netif_rx-> into the backlog, register soft interrupt Net_rx->net_rx_action->process_backlog

->__NETIF_RECEIVE_SKB->IP_RCV, go back to the IP stack and take all NetFilter chain

4. IP tunnel registration, go to the IOCTL

Create a new Ipip tunnel. Can be given a local IP. Remote IP. Dev

such as IP tunnel add tunnel mode ipip remote xx local yy Dev ZZ

Where remote, local, and Dev are not set, similar to the device created when Ipip itself is initialized tunnel0

Depending on the remote and local settings, only remote is set up, only local is set, and remote and local are set to 4 hash tables.

struct Ipip_net {

struct Ip_tunnel *tunnels_r_l[hash_size];

struct Ip_tunnel *tunnels_r[hash_size];

struct Ip_tunnel *tunnels_l[hash_size];

struct Ip_tunnel *tunnels_wc[1];

struct Ip_tunnel **tunnels[4];

struct Net_device *fb_tunnel_dev;

};

The options set by the User IP tunnel are saved in Ip_tunnel.param, i.e. Ip_tunnel_param

The specified dev device is the specified egress device for the routing table lookup, similar to the socket's bind_output_dev. If not specified, let

Route choice which exit to choose.

This article is from "Flying Justice Blog" blog, please be sure to keep this source http://xzq2000.blog.51cto.com/2487359/1775425

Implement IP tunneling using Linux system commands to complete the upstream and downstream separation of packets