Tunnels can be used to do some very unusual and very cool stuff. Tunneling increases overhead, because it needs an
extra set of IP headers. Typically this is 20 bytes per packet, so if the normal packet size (MTU) on a network is
1500 bytes, a packet that is sent through a tunnel can only be 1480 bytes big. This is not necessarily a problem,
but be sure to read up on IP packet fragmentation/reassembly when you plan to connect large networks with tunnels.
IP-IN-IP TUNNELING
If both ends are Linux hosts, IP-in-IP tunneling is the simplest tunneling method.
Let's say you have 3 networks: Internal networks A and B, and intermediate network C (or let's say, Internet). So
we have network A:
network 10.0.1.0
netmask 255.255.255.0
router 10.0.1.1
The router has address 172.16.17.18 on network C.
and network B:
network 10.0.2.0
netmask 255.255.255.0
router 10.0.2.1
The router has address 172.19.20.21 on network C. As far as network C is concerned, we assume that it will pass any
packet sent from A to B and vice versa. You might even use the Internet for this. Here's what you do:
insmod ipip.o
insmod new_tunnel.o
Then, on the router of network A, you do the following:
ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0
And on the router of network B:
ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0
Presto, you're done. You can't forward broadcast or IPv6 traffic through an IP-in-IP tunnel, though. You just
connect 2 IPv4 networks that normally wouldn't be able to talk to each other, that's all.
GRE
Generic Routing Encapsulation (GRE) is a tunneling protocol developed by Cisco Systems that can encapsulate a wide
variety of network layer protocols inside virtual point-to-point links over an Internet Protocol internetwork.
GRE tunnels are designed to be completely stateless. This means that each tunnel end-point does not keep any
information about the state or availability of the remote tunnel end-point. A consequence of this is that the local
tunnel end-point router does not have the ability to bring the line protocol of the GRE tunnel interface down if
the remote end-point is unreachable. In such a case, a network administrator can manually bring the interface down
in order to remove any routes (specifically static routes) in the routing table that use that interface as the
outbound interface. This allows for an alternate route with a higher metric (where a higher metric means a lower
priority) or for policy-based routing (PBR) to select an alternate next-hop or interface.
Normally, a GRE tunnel interface comes up as soon as it is configured and it stays up as long as there is a valid
tunnel source address or interface which is up. The tunnel destination IP address must also be routable, which is
true even if the other side of the tunnel has not been configured. This means that a static route or PBR forwarding
of packets via the GRE tunnel interface remains in effect even though the GRE tunnel packets do not reach the other
end of the tunnel.
The GRE tunnel keepalive mechanism is slightly different than for Ethernet or serial interfaces. It gives the
ability for one side to originate and receive keepalive packets to and from a remote router even if the remote
router does not support GRE keepalives. Since GRE is a packet tunneling mechanism for tunneling IP inside IP, a GRE
IP tunnel packet can be built inside another GRE IP tunnel packet. For GRE keepalives, the sender pre-builds the
keepalive response packet inside the original keepalive request packet so that the remote end only needs to do
standard GRE decapsulation of the outer GRE IP header and then forward the inner IP GRE packet. This mechanism
causes the keepalive response to forward out the physical interface rather than the tunnel interface. This means
that the GRE keepalive response packet is not affected by any output features on the tunnel interface.
Another attribute of GRE tunnel keepalives is that the keepalive timers on each side are independent and do not
have to match. The problem with the configuration of keepalives only on one side of the tunnel is that only the
router that has keepalives configured marks its tunnel interface as down if the keepalive timer expires. The GRE
tunnel interface on the other side, where keepalives are not configured, remains up even if the other side of the
tunnel is down. The tunnel can become a black-hole for packets directed into the tunnel from the side that did not
have keepalives configured. In a large hub-and-spoke GRE tunnel network, it might be appropriate to only configure
GRE keepalives on the spoke side and not on the hub side. This is because it is often more important for the spoke
to discover that the hub is unreachable and therefore switch to a backup path (Dial Backup for example).
These three rules (missing route, interface down and mis-routed tunnel destination) are problems local to the
router at the tunnel endpoints and do not cover problems in the intervening network. For example, these rules do
not cover the case in which the GRE tunneled packets are successfully forwarded, but are lost before they reach the
other end of the tunnel. This causes data packets that go through the GRE tunnel to be "black holed", even though
an alternate route that uses PBR or a floating static route via another interface is potentially available.
Keepalives on the GRE tunnel interface are used in order to solve this issue in the same way as keepalives are used
on physical interfaces.
Let's say you have 3 networks: Internal networks A and B, and intermediate network C (or let's say, Internet).
So we have network A:
network 10.0.1.0
netmask 255.255.255.0
router 10.0.1.1
The router has address 172.16.17.18 on network C. Let's call this network neta. And network B:
network 10.0.2.0
netmask 255.255.255.0
router 10.0.2.1
The router has address 172.19.20.21 on network C. Let's call this network netb. As far as network C is concerned,
we assume that it will pass any packet sent from A to B and vice versa. How and why, we do not care. On the router
of network A, you do the following:
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb
Let's discuss this for a bit. In line 1, we added a tunnel device, and called it netb (which is kind of obvious
because that's where we want it to go). Furthermore we told it to use the GRE protocol (mode gre), that the remote
address is 172.19.20.21 (the router at the other end), that our tunneling packets should originate from
172.16.17.18 (which allows your router to have several IP addresses on network C and let you decide which one to
use for tunneling) and that the TTL field of the packet should be set to 255 (ttl 255).
In the second line we gave the newly born interface netb the address 10.0.1.1. This is OK for smaller networks, but
when you're starting up a mining expedition (LOTS of tunnels), you might want to consider using another IP range
for tunneling interfaces (in this example, you could use 10.0.3.0).
In the third line we set the route for network B. Note the different notation for the netmask. If you're not
familiar with this notation, here's how it works: you write out the netmask in binary form, and you count all the
ones. If you don't know how to do that, just remember that 255.0.0.0 is /8, 255.255.0.0 is /16 and 255.255.255.0 is
/24. Oh, and 255.255.254.0 is /23, in case you were wondering.
But enough about this, let's go on with the router of network B.
ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta
And when you want to remove the tunnel on router A:
ip link set netb down
ip tunnel del netb
Of course, you can replace netb with neta for router B.
PPTP
SOCKS PROXIES
|
