1 |
From: "Mick" <michaelkintzios@×××××.com> |
2 |
|
3 |
To: gentoo-user@l.g.o |
4 |
Sent: Wednesday, March 21, 2012 5:37:51 AM |
5 |
Subject: Re: [gentoo-user] PPP Tunnel using iproute2/tun interface |
6 |
|
7 |
On Wednesday 21 Mar 2012 02:05:03 Michael J. Hill wrote: |
8 |
> Hello, |
9 |
> |
10 |
> In testing, I have gotten this setup to work by manually completing the |
11 |
> necessary steps; however, I am now looking to have everything completed |
12 |
> automatically so as to ensure my setup persists over a reboot. |
13 |
> |
14 |
> Firstly, an outline of what I am doing: |
15 |
> * I have a Gentoo VM running at home, functioning as my firewall/router, |
16 |
> which works perfectly fine. * Said VM has established an IPSEC tunnel to a |
17 |
> dedicated server using OpenSWAN. This also works perfectly fine. * A tun0 |
18 |
> interface is created on both devices, setting up an IPIP PPP tunnel that |
19 |
> sits on top of the IPSEC tunnel. * Firewall and Routing rules are in place |
20 |
> to perform policy-based routing over this tun0 interface. This again, |
21 |
> works perfectly fine. |
22 |
> |
23 |
> For the rest, the following configuration is worth noting: |
24 |
> * The dedicated server is running CentOS 6, not that this is of necessary |
25 |
> import for this configuration. * 172.18.0.1 resides on the dedicated |
26 |
> server. |
27 |
> * 10.0.0.1 is the management IP of my Gentoo VM, and serves as its identity |
28 |
> as well. * 172.18.1.0/24 is the network utilized for the tunnel, with |
29 |
> 172.18.1.1 on the dedicated server, and 172.18.1.2 on the Gentoo VM. |
30 |
> |
31 |
> In effect, the first thing I need to do, is automate the IPIP PPP tunnel |
32 |
> setup so that the device can persist over a reboot. I can create it |
33 |
> manually right now, no problem, with the following command strings: # ip |
34 |
> tunnel add tun0 mode ipip remote 172.18.0.1 local 10.0.0.1 |
35 |
> # ip addr add 172.18.1.2/24 dev tun0 |
36 |
> # ip link set tun0 mtu 1500 |
37 |
> # i p link set tun0 up |
38 |
> |
39 |
> This all works perfectly fine, and tun0 is created after running the first |
40 |
> command. Now I need this to persist a reboot. I wanted to handle this |
41 |
> through OpenRC, since I can then do dependency resolution, and make sure |
42 |
> the tunnel comes up only if the IPSEC tunnel is up and running. That being |
43 |
> said, I added the following to /etc/conf.d/net: |
44 |
|
45 |
Shouldn't you create the ipip tunnel here first? |
46 |
|
47 |
Something like: |
48 |
|
49 |
iptunnel_tun0="mode ipip remote 172.18.0.1 ttl 255" #not sure if local is |
50 |
required, you can try with & without. |
51 |
|
52 |
|
53 |
> link_tun0="ipsec0" #Not sure this is correct, shouldn't it be an iface? |
54 |
|
55 |
> config_tun0="172.18.1.2 netmask 255.255.255.0 brd 172.18.1.255" |
56 |
> dns_servers_tun0="10.0.1.2" |
57 |
> routes_tun0=( |
58 |
> "64.20.39.38/32 via 172.18.1.1" |
59 |
> "default via 172.18.1.1 table ipsec" |
60 |
> ) |
61 |
> mtu_tun0="1500" |
62 |
> iptunnel_tun0_remote="172.18.0.1" |
63 |
> iptunnel_tun0_local="10.0.0.1" |
64 |
> iptunnel_tun0_mode="ipip remote ${iptunnel_tun0_remote} local |
65 |
> ${iptunnel_tun0_local} dev ${link_tun0}" rc_net_tun0_need="ipsec" |
66 |
> preup() { |
67 |
> # If the link does not exist, return now, it's a tunnel! |
68 |
> ip link show dev ${IFACE} 2>/dev/null || return 0 |
69 |
> } |
70 |
> |
71 |
> Now, the configuration does reflect an additional item not in my original |
72 |
> setup, which links tun0 to the ipsec0 interface. I've tested with and |
73 |
> without this, and it doesn't work. Attempting to bring up the interface |
74 |
> using rc-service results in the following error: Cannot find device "tun0" |
75 |
> * ERROR: interface tun0 does not exist |
76 |
> * Ensure that you have loaded the correct kernel module for your hardware |
77 |
> * ERROR: net.tun0 failed to start |
78 |
> |
79 |
> I could easily script all this out, and probably call it through rc.local, |
80 |
> but I'd rather be able to utilize the dependency resolution to make sure |
81 |
> all the necessary components are up. |
82 |
> |
83 |
> Any insights on getting it to behave? |
84 |
> |
85 |
> Michael Hill |
86 |
|
87 |
-- |
88 |
Regards, |
89 |
Mick |
90 |
|
91 |
----- Original Message ----- |
92 |
Thanks for the help. It did give me some insight on where to look next, and now it works perfectly. The problem was in part the ordering I was using, and more specific, iptunnel_tun0_mode should have been iptunnel_tun0="mode xxxxxx". That would've resulted in the creation of the interface. I've included my final config for anybody else who may be interested in such a setup: |
93 |
|
94 |
link_tun0="ipsec0" |
95 |
iptunnel_tun0_remote="172.18.0.1" |
96 |
iptunnel_tun0_local="10.0.0.1" |
97 |
iptunnel_tun0="mode ipip remote ${iptunnel_tun0_remote} local ${iptunnel_tun0_local} dev ${link_tun0}" |
98 |
mtu_tun0="1500" |
99 |
config_tun0="172.18.1.2 netmask 255.255.255.0 brd 172.18.1.255" |
100 |
dns_servers_tun0="10.0.1.2" |
101 |
routes_tun0="64.20.39.38/32 via 172.18.1.1 |
102 |
default via 172.18.1.1 table 1 " |
103 |
rules_tun0="fwmark 1 table 1" |
104 |
|
105 |
rc_net_tun0_need="ipsec" |
106 |
|
107 |
preup() { |
108 |
ip link show dev ${IFACE} 2>/dev/null || return 0 |
109 |
} |