|[ << ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
Here are some tips, examples and additional information on how to design a network structure with CIPE and configure the devices accordingly.
5.1 General tips General useful tips on CIPE configuration. 5.2 Example 1 The classic VPN setups. 5.3 Example 2 A PKCIPE setup. 5.4 Connection modes Overview on different carrier network situations.
route add -host $5 dev $1in `ip-up' is required. Without it the link won't work. This also means the `ip-up' script itself is mandatory.
$5if you have several CIPE links. Use
route add ... gw $5, not
route add ... dev $1. Remember that Linux deletes any routes through a device when this device goes down.
gated, gated is the only thing responsible for setting any routes and the routes through the CIPE device routes belong in `gated.conf' as static routes, or are to be set via a routing protocol. To gated, a CIPE link looks and behaves exactly like a dial-up link. It is strongly recommended to put
gdc interfacein `ip-up' as well as `ip-down' to tell gated about status changes.
ipaddris the other's
ptpaddr, and one side's
meis the other's
peer. Since CIPE 0.5,
peeris picked up dynamically and the real peer may be different from that set in the config file (but this config item must still be present, it should specify the other end's reverse as a reasonable default).
cipedrun, and that an explicit
deviceoption should be used if the device name is used in firewall rules.
ip-upsample scripts is mandatory as they are used as lock files. Omitting these can cause confusion when several instances of
pkciperun at the same time.
This basic example shows how to connect hosts and networks with unofficial network numbers through the Internet. Uses for this are classic VPN setups:
Internet Internet ^ ^ | | hostz |ppp0 |eth1 18.104.22.168 |22.214.171.124 |126.96.36.199 | +---------routera routerb eth0 188.8.131.52 | | eth0 \_ _ _ _ _ _ _ _/ \---------------+-------+---+ | 10.0.1.1 cipcb0 cipcb0 eth0 | | hosta 10.0.1.1 10.0.2.1 10.0.2.1 | | 10.0.1.88 hostx hosty 10.0.2.5 10.0.2.6
As can be seen from the picture, a CIPE device and another network device can have the same IP address if there are no overlapping routes between them.
The CIPE devices are configured like this:
|static routes||10.0.1.0/24 dev eth0||10.0.2.0/24 dev eth0|
|default dev ppp0||184.108.40.206/26 dev eth0|
|default dev eth1|
|routes in ip-up||10.0.2.0/24 gw 10.0.2.1||10.0.1.0/24 gw 10.0.1.1|
For case 3, assume
routera to be the mobile host, think of
eth0 missing and
ppp0 having a dynamic address. The
routerb config remains unchanged. For
routera simply omit
eth0 stuff, add the
dynip flag for ciped.
picks up its peer dynamically. This even works when
plugged behind a firewall and has to rely on a SOCKS5 server for outside
access. (Yes, this can be used to punch holes into firewalls. No, it's
not my intention to do anything about it. Local policy issues have to be
dealt with locally.)
This example shows how to set up PKCIPE. The overall setup is symmetric, there are no designated servers and clients. However, one end has to accept incoming TCP connections on a chosen port (server mode) and the other one has to connect to it (client mode).
The basic configuration of a link is like this: assuming
has the address (of the CIPE device)
has the address
10.0.2.1 like in Example 1. Each
`/etc/cipe/pk/host' file contains the public key of that host
together with options applying to that host:
routera, `/etc/cipe/pk/routerb' looks like this:
-----BEGIN PUBLIC KEY----- (here is the public key of routerb) -----END PUBLIC KEY----- ipaddr 10.0.1.1 ptpaddr 10.0.2.1
routerb, `/etc/cipe/pk/routera' looks like this:
-----BEGIN PUBLIC KEY----- (here is the public key of routera) -----END PUBLIC KEY----- ipaddr 10.0.2.1 ptpaddr 10.0.1.1
This is all of the minimum configuration. Note that no
peer options are necessary. These are determined by
pkcipe. It does not matter which side runs
server and which one in client mode.
In server mode,
pkcipe has to be started via
requires the following steps:
pkcipe stream tcp nowait root /usr/local/sbin/pkcipe pkcipe
pkcipe stream tcp nowait root /usr/sbin/tcpd /usr/local/sbin/pkcipe
inetdafter any change.
The other end then initiates the connection simply via
pkcipe -c server.machine:pkcipe
runsocksscript). In the latter case it may be necessary to repeat the peer address in a
Here is in detail how it is possible to build CIPE links between different classes of carriers. Those classes are, based on how they are able to reach the carrier network (usually the Internet):
This produces ten different combinations:
pkcipegets the right IP addresses at both ends, later changes are handled automatically. (6)
ip-upat the `3' end. The `3' end does not know its effective (as seen by the other end) carrier address, so the PKCIPE exchange produces a wrong
peerparameter at the `1' end. The
pingcorrects that by sending packets with the right address. (7)
ip-upscript, but transmitting it to the other end would need some means outside of CIPE. It is planned that future versions will be able to handle this via extended capabilities of PKCIPE; this will also require an external service like dynamic DNS with a special setup.
See section 3.5 Dynamic carrier addresses, for a more detailed explanation of some of these configurations.
|[ << ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|