1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
|
# $FreeBSD$
# This advanced ppp configuration file explains how to implement
# the following:
#
# ------------- ------------- -------------
# | host1 | | host2 | | host3 |
# ------------- ------------- -------------
# | | |
# |---------------------- LAN ----------------------|
# |
# -------------
# | Gateway |
# -------------
# |
# -----------------------------------
# | | | |
# isp1 isp2 isp3 ispN
# | | | |
# -----------------------------------
# |
# ------------
# | Receiver |
# ------------
# |
# Internet
#
# The connection is implemented so that any ISP connection can go down
# without loss of connectivity between the LAN and the Internet. It is
# of course also possible to shut down any link manually.
#
# There is a working example in ppp.*.span-isp.working that can be tested
# on a single machine !
#
#
# Prerequisites:
#
# o The Receiver machine must be in the outside world and must be willing
# to accept a multilink ppp connection over UDP, assigning a routable IP
# number to the Gateway machine. This probably means that it must be
# a *BSD box as I know of no other ppp implementations that can use UDP
# as a transport.
#
# o The Receiver machine must be multi-homed with at least N+1 addresses
# where N is the maximun number of ISPs that you wish to use
# simultaneously. We assume the IP numbers to be RIP1, RIP2 ... RIPN.
# REAL-LOCAL-IP is the real IP number of the Receiver machine (and must
# not be the same as any of the RIP* numbers).
#
# o Both the Gateway and the Receiver machines must have several tun
# interfaces configured into the kernel (see below).
#
# o Both the Gateway and the Receiver machines must have the following
# entry in /etc/services:
#
# ppp 6671/udp
#
# The port number isn't important, but it must be consistent across
# machines.
#
# o The Receiver machine must have the following entry in
# /etc/inetd.conf:
#
# ppp dgram udp wait root /usr/sbin/ppp ppp -direct vpn-in
#
# Note: Because inetd ``wait''s for ppp to finish, a single ppp
# invocation receives all incoming packets. This creates
# havoc with LQR magic number checks, so LQR *must not* be
# enabled.
# Also, -direct invocations of ppp do sendto()s using the
# address that was last recvfrom()d. This means that the
# returning traffic is a bit unbalanced. Perhaps ppp should
# be smart enough to automatically clone an existing link
# when it detects a new incoming address.... tricky !
#
# If you use ppp to connect to your ISPs, the isp* profiles shold be used,
# resulting in the vpn* profiles being called from ppp.linkup.span-isp.
# These invocations will bond together into a MP ppp invocation.
#
# If the link to your ISP is via another type of interface (cable modem
# etc), simply configure the interface with a netmask of 0xffffffff and
# add a route to RIPN via the interface address (no default). You can
# then start ppp using the vpn-nic label.
#
# The Receiver machine should have N tun interfaces (where N is the maximum
# number of ISPs that you wish to use simultaneously). The Gateway machine
# requires N interfaces plus an additional N interfaces (total 2 * N) if
# you're using ppp to talk to the ISPs.
# Using ppp to connect to your ISPs (PPP over UDP over PPP):
#
# When we connect to our ISPs using ppp, we start the MP ppp invocation
# from ppp.linkup (see ppp.linkup.span-isp) for each link. We also remove
# the link from ppp.linkdown (see ppp.linkdown.span-isp). This is necessary
# because relying on our LQR strategy (dropping the link after 5 missing
# replies) is just too slow to be practical in this environment.
#
# This works because the MP invocations are smart enough to recognise that
# another process is already running and to pass the link over to that
# running version.
#
# Only the ISP links should be started manually. When they come up, they'll
# start the MP invocation.
default:
set speed 115200
set device /dev/cuaa0 /dev/cuaa1 /dev/cuaa2 /dev/cuaa3
set dial "ABORT BUSY ABORT NO\\sCARRIER ABORT NO\\sDIAL\\sTONE TIMEOUT 4 \
\"\" ATZ OK-ATZ-OK ATDT\\T TIMEOUT 60 CONNECT \\c \\n"
set login
set redial 3 5
set timeout 0
enable lqr
set lqrperiod 15
isp1:
set phone "1234567"
set authname isp1name
set authkey isp1key
add! RIP1/32 HISADDR
isp2:
set phone "2345678"
set authname isp2name
set authkey isp2key
add! RIP2/32 HISADDR
ispN:
set phone "3456789"
set authname ispNname
set authkey ispNkey
add! RIPN/32 HISADDR
# Our MP version of ppp. vpn is a generic label used by each of the
# other vpn invocations by envoking ppp with both labels (see
# ppp.linkup.span-isp).
# Each ``set device'' command tells ppp to use UDP packets destined for
# the given IP/port as the link (transport). The routing table will
# ensure that these UDP packets use the correct ISP connection.
vpn:
set enddisc LABEL
set speed sync
set mrru 1500
alias enable yes
set authname vpnname
set authkey vpnkey
add! default HISADDR
disable deflate pred1 lqr
deny deflate pred1
vpn1:
rename 1
set device RIP1:ppp/udp
vpn2:
rename 2
set device RIP2:ppp/udp
vpnN:
rename N
set device RIPN:ppp/udp
vpn-nic:
load vpn
clone 1 2 N
link deflink rm
link 1 set device RIP1:ppp/udp
link 2 set device RIP2:ppp/udp
link N set device RIPN:ppp/udp
# The Receiver profile is a bit more straight forward, as it doesn't need
# to get bogged down with sublinks. Replace REAL-ASSIGNED-IP with the
# IP number to be assigned to the Gateway machine. Replace REAL-LOCAL-IP
# with the real IP number of the Receiver machine.
#
# No other entries are required on the Receiver machine, and this entry
# is not required on the Gateway machine. The Receiver machine also
# requires the contents of ppp.secret.span-isp.
#
# Of course it's simple to assign an IP block to the client with a simple
# ``add'' command, and then have the client use those IP numbers on its
# LAN rather than using ``alias enable yes''.
vpn-in:
set enddisc label
set speed sync
set mrru 1500
enable chap
disable lqr
set ifaddr REAL-LOCAL-IP REAL-ASSIGNED-IP
|
