Documentation update
This commit is contained in:
parent
a4c14149f2
commit
60589c977c
2 changed files with 407 additions and 304 deletions
565
Docs/manual.html
565
Docs/manual.html
|
|
@ -1,7 +1,10 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
|
||||
"http://www.w3.org/TR/html4/loose.dtd">
|
||||
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>L2TPNS Manual</TITLE>
|
||||
<STYLE>
|
||||
<STYLE TYPE="text/css">
|
||||
H1 {
|
||||
text-align: center;
|
||||
}
|
||||
|
|
@ -21,34 +24,55 @@ H3 {
|
|||
<BODY>
|
||||
<H1>L2TPNS Manual</H1>
|
||||
<OL>
|
||||
<LI>Overview</LI>
|
||||
<LI>Installation</LI>
|
||||
<LI>Configuration</LI>
|
||||
<LI>Controlling the process</LI>
|
||||
<LI>Command-Line Interface</LI>
|
||||
<LI>Throttling</LI>
|
||||
<LI>Interception</LI>
|
||||
<LI>Authentication</LI>
|
||||
<LI>Plugins</LI>
|
||||
<LI>Walled Garden</LI>
|
||||
<LI>Clustering</LI>
|
||||
<LI>Performance</LI>
|
||||
<LI><A HREF="#Overview">Overview</A></LI>
|
||||
<LI><A HREF="#Installation">Installation</A>
|
||||
<OL>
|
||||
<LI><A HREF="#Requirements">Requirements</A></LI>
|
||||
<LI><A HREF="#Compile">Compile</A></LI>
|
||||
<LI><A HREF="#Install">Install</A></LI>
|
||||
<LI><A HREF="#Running">Running</A></LI>
|
||||
</OL>
|
||||
<H2>Overview</H2>
|
||||
L2TPNS is half of a complete L2TP implementation. It supports only the
|
||||
</LI>
|
||||
<LI><A HREF="#Configuration">Configuration</A>
|
||||
<OL>
|
||||
<LI><A HREF="#startup-config">startup-config</A></LI>
|
||||
<LI><A HREF="#users">users</A></LI>
|
||||
<LI><A HREF="#ip-pool">ip_pool</A></LI>
|
||||
<LI><A HREF="#build-garden">build-garden</A></LI>
|
||||
</OL>
|
||||
</LI>
|
||||
<LI><A HREF="#ControllingtheProcess">Controlling the Process</A>
|
||||
<OL>
|
||||
<LI><A HREF="#Command-LineInterface">Command-Line Interface</A></LI>
|
||||
<LI><A HREF="#nsctl">nsctl</A></LI>
|
||||
<LI><A HREF="#Signals">Signals</A></LI>
|
||||
</OL>
|
||||
</LI>
|
||||
<LI><A HREF="#Throttling">Throttling</A></LI>
|
||||
<LI><A HREF="#Interception">Interception</A></LI>
|
||||
<LI><A HREF="#Authentication">Authentication</A></LI>
|
||||
<LI><A HREF="#Plugins">Plugins</A></LI>
|
||||
<LI><A HREF="#Walled Garden">Walled Garden</A></LI>
|
||||
<LI><A HREF="#Clustering">Clustering</A></LI>
|
||||
<LI><A HREF="#Routing">Routing</A></LI>
|
||||
<LI><A HREF="#Performance">Performance</A></LI>
|
||||
</OL>
|
||||
|
||||
<H2 ID="Overview">Overview</H2>
|
||||
l2tpns is half of a complete L2TP implementation. It supports only the
|
||||
LNS side of the connection.<P>
|
||||
|
||||
L2TP (Layer 2 Tunneling Protocol) is designed to allow any layer 2
|
||||
protocol (e.g. Ethernet, PPP) to be tunneled over an IP connection. L2TPNS
|
||||
protocol (e.g. Ethernet, PPP) to be tunneled over an IP connection. l2tpns
|
||||
implements PPP over L2TP only.<P>
|
||||
|
||||
There are a couple of other L2TP imlementations, of which <A
|
||||
HREF="http://sourceforge.net/projects/l2tpd">l2tpd</A> is probably the
|
||||
most popular. l2tpd also will handle being either end of a tunnel, and
|
||||
is a lot more configurable than L2TPNS. However, due to the way it works,
|
||||
is a lot more configurable than l2tpns. However, due to the way it works,
|
||||
it is nowhere near as scalable.<P>
|
||||
|
||||
L2TPNS uses the TUN/TAP interface provided by the Linux kernel to receive
|
||||
l2tpns uses the TUN/TAP interface provided by the Linux kernel to receive
|
||||
and send packets. Using some packet manipulation it doesn't require a
|
||||
single interface per connection, as l2tpd does.<P>
|
||||
|
||||
|
|
@ -64,58 +88,35 @@ included.<P>
|
|||
with this document, or if you wish to contribute, please email <A
|
||||
HREF="mailto:david@dparrish.com?subject=L2TPNS+Documentation">david@dparrish.com</A>.</EM><P>
|
||||
|
||||
<H2>Installation</H2>
|
||||
<H3>Requirements</H3>
|
||||
<H2 ID="Installation">Installation</H2>
|
||||
<H3 ID="Requirements">Requirements</H3>
|
||||
|
||||
<OL>
|
||||
<LI>Linux kernel version 2.4 or above, with the Tun/Tap interface either
|
||||
compiled in, or as a module.</LI>
|
||||
|
||||
<LI>libcli 1.5 or greater.<BR>You can get this from <A
|
||||
<LI>libcli 1.8.0 or greater.<BR>You can get this from <A
|
||||
HREF="http://sourceforge.net/projects/libcli">http://sourceforge.net/projects/libcli</A></LI>
|
||||
|
||||
<LI>The iproute2 user-space tools. These are used for throttling,
|
||||
so if you don't want to throttle then this is not required.<BR>You
|
||||
may also need to patch tc and the kernel to include HTB
|
||||
support. You can find the relevant patches and instructions at <A
|
||||
HREF="http://luxik.cdi.cz/~devik/qos/htb/">http://luxik.cdi.cz/~devik/qos/htb/</A>.</LI>
|
||||
|
||||
</OL>
|
||||
|
||||
<H3>Compile</H3>
|
||||
<H3 ID="Compile">Compile</H3>
|
||||
|
||||
You can generally get away with just running <B>make</B> from the source
|
||||
directory. This will compile the daemon, associated tools and any modules
|
||||
shipped with the distribution.<P>
|
||||
|
||||
<H3>Install</H3>
|
||||
<H3 ID="Install">Install</H3>
|
||||
|
||||
After you have successfully compiled everything, run <B>make
|
||||
install</B> to install it. By default, the binaries are installed into
|
||||
<EM>/usr/sbin</EM>, the configuration into <EM>/etc/l2tpns</EM>, and the
|
||||
modules into <EM>/usr/lib/l2tpns</EM>.<P>
|
||||
|
||||
You will definately need to edit the configuration file before you start.
|
||||
See the Configuration section for more information.<P>
|
||||
You will definately need to edit the configuration files before you
|
||||
start. See the <A HREF="#Configuration">Configuration</A> section for
|
||||
more information.<P>
|
||||
|
||||
You should also create the appropriate iptables chains if you want to use
|
||||
throttling or walled garden.
|
||||
<PRE>
|
||||
# Create the walled garden stuff
|
||||
iptables -t nat -N l2tpns
|
||||
iptables -t nat -F l2tpns
|
||||
iptables -t nat -A PREROUTING -j l2tpns
|
||||
iptables -t nat -A l2tpns -j garden_users
|
||||
# Create the throttling stuff
|
||||
iptables -t mangle -N l2tpns
|
||||
iptables -t mangle -F l2tpns
|
||||
iptables -t mangle -N throttle
|
||||
iptables -t mangle -F throttle
|
||||
iptables -t mangle -A PREROUTING -j l2tpns
|
||||
iptables -t mangle -A l2tpns -j throttle
|
||||
</PRE>
|
||||
|
||||
<H3>Running it</H3>
|
||||
<H3 ID="Running">Running</H3>
|
||||
|
||||
You only need to run <B>/usr/sbin/l2tpns</B> as root to start it. It does
|
||||
not detach to a daemon process, so you should perhaps run it from init.<P>
|
||||
|
|
@ -123,19 +124,19 @@ not detach to a daemon process, so you should perhaps run it from init.<P>
|
|||
By default there is no log destination set, so all log messages will go to
|
||||
stdout.<P>
|
||||
|
||||
<H2>Configuration</H2>
|
||||
<H2 ID="Configuration">Configuration</H2>
|
||||
|
||||
All configuration of the software is done from the files installed into
|
||||
/etc/l2tpns.
|
||||
|
||||
<H3>l2tpns.cfg</H3>
|
||||
<H3 ID="startup-config">startup-config</H3>
|
||||
|
||||
This is the main configuration file for L2TPNS. The format of the file is a
|
||||
This is the main configuration file for l2tpns. The format of the file is a
|
||||
list of commands that can be run through the command-line interface. This
|
||||
file can also be written directly by the L2TPNS process if a user runs the
|
||||
file can also be written directly by the l2tpns process if a user runs the
|
||||
<EM>write memory</EM> command, so any comments will be lost. However if your
|
||||
policy is not to write the config by the program, then feel free to comment
|
||||
the file with a # at the beginning of the line.<P>
|
||||
the file with a # or ! at the beginning of the line.<P>
|
||||
|
||||
A list of the possible configuration directives follows. Each of these
|
||||
should be set by a line like:<P>
|
||||
|
|
@ -157,7 +158,7 @@ highest. A rough description of the levels is:
|
|||
<LI>Information - Parameters of control packets</LI>
|
||||
<LI>Calls - For tracing the execution of the code</LI>
|
||||
<LI>Packets - Everything, including a hex dump of all packets processed... probably twice</LI>
|
||||
</OL>
|
||||
</OL><P>
|
||||
Note that the higher you set the debugging level, the slower the program
|
||||
will run. Also, at level 5 a LOT of information will be logged. This should
|
||||
only ever be used for working out why it doesn't work at all.
|
||||
|
|
@ -173,53 +174,42 @@ is any one of the syslog logging facilities, such as local5.
|
|||
</LI>
|
||||
|
||||
<LI><B>l2tp_secret</B> (string)<BR>
|
||||
This sets the string that L2TPNS will use for authenticating tunnel request.
|
||||
This sets the string that l2tpns will use for authenticating tunnel request.
|
||||
This must be the same as the LAC, or authentication will fail. This will
|
||||
only actually be used if the LAC requests authentication.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>primary_dns</B> (ip address)<BR>
|
||||
<LI><B>primary_dns</B> (ip address)
|
||||
<LI><B>secondary_dns</B> (ip address)<BR>
|
||||
Whenever a PPP connection is established, DNS servers will be sent to the
|
||||
user, both a primary and a secondary. If either is set to 0.0.0.0, then that
|
||||
one will not be sent.<BR>
|
||||
This sets the first DNS entry that will be sent.
|
||||
one will not be sent.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>secondary_dns</B> (ip address)<BR>
|
||||
See <EM>primary_dns</EM>.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>snoop_host</B> (ip address)<BR>
|
||||
Whenever a user is intercepted, a copy of their traffic will be sent to this
|
||||
IP address, using the port specified by <EM>snoop_port</EM>. Each packet
|
||||
will be sent as UDP.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>snoop_port</B> (int)<BR>
|
||||
See <EM>snoop_host</EM>.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>primary_radius</B> (ip address)<BR>
|
||||
This sets the primary radius server used for both authentication and
|
||||
accounting. If this server does not respond, then the secondary radius
|
||||
server will be used.
|
||||
<LI><B>save_state</B> (boolean)<BR>
|
||||
When l2tpns receives a STGTERM it will write out its current
|
||||
ip_address_pool, session and tunnel tables to disk prior to exiting to
|
||||
be re-loaded at startup. The validity of this data is obviously quite
|
||||
short and the intent is to allow an sessions to be retained over a
|
||||
software upgrade.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>primary_radius</B> (ip address)
|
||||
<LI><B>secondary_radius</B> (ip address)<BR>
|
||||
See <EM>primary_radius</EM>.
|
||||
This sets the radius servers used for both authentication and
|
||||
accounting. If the primary server does not respond, then the
|
||||
secondary radius server will be tried.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>radius_accounting</B> (boolean)<BR>
|
||||
If set to true, then radius accounting packets will be sent. This means that
|
||||
a Start record will be sent when the session is successfully authenticated,
|
||||
and a Stop record will be sent when the session is closed.
|
||||
If set to true, then radius accounting packets will be sent. This
|
||||
means that a Start record will be sent when the session is
|
||||
successfully authenticated, and a Stop record will be sent when the
|
||||
session is closed.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
|
|
@ -230,18 +220,18 @@ radius queries will fail.
|
|||
</LI>
|
||||
|
||||
<LI><B>bind_address</B> (ip address)<BR>
|
||||
When the tun interface is created, it is assigned the address specified
|
||||
here. If no address is given, 1.1.1.1 is used.<BR>
|
||||
If an address is given here, then packets containing user traffic should be
|
||||
routed via this address, otherwise the primary address of the machine.<BR>
|
||||
This is set automatically by the cluster master when taking over a failed
|
||||
machine.
|
||||
When the tun interface is created, it is assigned the address
|
||||
specified here. If no address is given, 1.1.1.1 is used. Packets
|
||||
containing user traffic should be routed via this address if given,
|
||||
otherwise the primary address of the machine.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>cluster_master</B> (ip address)<BR>
|
||||
This sets the address of the cluster master. See the <EM>Clustering</EM>
|
||||
section for more information on configuring a cluster.
|
||||
<LI><B>send_garp</B> (boolean)<BR>
|
||||
Determines whether or not to send a gratuitous ARP for the
|
||||
bind_address when the server is ready to handle traffic (default:
|
||||
true).<BR>
|
||||
This value is ignored if BGP is configured.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
|
|
@ -252,10 +242,14 @@ the CLI, but changes will not affect currently connected users.
|
|||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>dump_speed</B> (boolean)<BR>
|
||||
If set to true, then the current bandwidth utilization will be logged every
|
||||
second. Even if this is disabled, you can see this information by running
|
||||
the <EM>uptime</EM> command on the CLI.
|
||||
<LI><B>accounting_dir</B> (string)<BR>
|
||||
If set to a directory, then every 5 minutes the current usage for
|
||||
every connected use will be dumped to a file in this directory. Each
|
||||
file dumped begins with a header, where each line is prefixed by #.
|
||||
Following the header is a single line for every connected user, fields
|
||||
separated by a space.<BR> The fields are username, ip, qos,
|
||||
uptxoctets, downrxoctets. The qos field is 1 if a standard user, and
|
||||
2 if the user is throttled.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
|
|
@ -265,49 +259,99 @@ doesn't work properly.
|
|||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>accounting_dir</B> (string)<BR>
|
||||
If set to a directory, then every 5 minutes the current usage for every
|
||||
connected use will be dumped to a file. Each file dumped begins with a
|
||||
header, where each line is prefixed by #. Following the header is a single
|
||||
line for every connected user, fields separated by a space.<BR>
|
||||
The fields are username, ip, qos, uptxoctets, downrxoctets. The qos
|
||||
field is 1 if a standard user, and 2 if the user is throttled.
|
||||
|
||||
<LI><B>dump_speed</B> (boolean)<BR>
|
||||
If set to true, then the current bandwidth utilization will be logged every
|
||||
second. Even if this is disabled, you can see this information by running
|
||||
the <EM>uptime</EM> command on the CLI.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>save_state</B> (boolean)<BR>
|
||||
If set to true, a state file will be dumped to disk when the process dies.
|
||||
This will be restored on startup, loading all active tunnels and sessions.
|
||||
<LI><B>cleanup_interval</B> (int)<BR>
|
||||
Interval between regular cleanups (in seconds).
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>multi_read_count</B> (int)<BR>
|
||||
Number of packets to read off each of the UDP and TUN fds when
|
||||
returned as readable by select (default: 10). Avoids incurring the
|
||||
unnecessary system call overhead of select on busy servers.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>scheduler_fifo</B> (boolean)<BR>
|
||||
Sets the scheduling policy for the l2tpns process to SCHED_FIFO. This
|
||||
causes the kernel to immediately preempt any currently SCHED_OTHER
|
||||
(normal) process in favour of l2tpns when it becomes runnable.
|
||||
Ignored on uniprocessor systems.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>lock_pages</B> (boolean)<BR>
|
||||
Keep all pages mapped by the l2tpns process in memory.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>icmp_rate</B> (int)<BR>
|
||||
Maximum number of host unreachable icmp packets to send per second.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>cluster_address</B> (ip address)<BR>
|
||||
Multicast cluster address (default: 239.192.13.13). See the section
|
||||
on <A HREF="#Clustering">Clustering</A> for more information.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>cluster_interface</B> (string)<BR>
|
||||
Interface for cluster packets (default: eth0).
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>cluster_hb_interval</B> (int)<BR>
|
||||
Interval in tenths of a second between cluster heartbeat/pings.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>cluster_hb_timeout</B> (int)<BR>
|
||||
Cluster heartbeat timeout in tenths of a second. A new master will be
|
||||
elected when this interval has been passed without seeing a heartbeat
|
||||
from the master.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>as_number</B> (int)<BR>
|
||||
Defines the local AS number for BGP (see <A HREF="#Routing">Routing</A>).
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>bgp_peer1</B> (string)
|
||||
<LI><B>bgp_peer1_as</B> (int)
|
||||
<LI><B>bgp_peer2</B> (string)
|
||||
<LI><B>bgp_peer2_as</B> (int)<BR>
|
||||
<P>
|
||||
DNS name (or IP) and AS number of BGP peers.
|
||||
</LI>
|
||||
</UL>
|
||||
|
||||
<H3>l2tpns.users</H3>
|
||||
<H3 ID="users">users</H3>
|
||||
|
||||
This file's sole purpose is to manage access to the command-line
|
||||
interface. If this file doesn't exist, then anyone who can get to port
|
||||
23 will be allowed access without a username / password.<P>
|
||||
Usernames and passwords for the command-line interface are stored in
|
||||
this file. The format is <I>username</I><B>:</B><I>password</I> where
|
||||
<I>password</I> may either by plain text, an MD5 digest (prefixed by
|
||||
<B>$1</B><I>salt</I><B>$</B>) or a DES password, distinguished from
|
||||
plain text by the prefix <B>{crypt}</B>.<P>
|
||||
|
||||
If this is not what you want, then create this file and put in it a list of
|
||||
username / password pairs, separated by a <B>:</B>. e.g.:<P>
|
||||
The username <B>enable</B> has a special meaning and is used to set
|
||||
the enable password.<P>
|
||||
|
||||
<PRE>
|
||||
user.1:randompassword
|
||||
fred:bhPe4rD1ME8.s
|
||||
bob:SP2RHKl3Q3qo6
|
||||
</PRE>
|
||||
<B>Note:</B> If this file doesn't exist, then anyone who can get to
|
||||
port 23 will be allowed access without a username / password.<P>
|
||||
|
||||
Keep in mind that the password should be in clear-text. There is no user
|
||||
privilege distinction, so anyone on this list will have full control of the
|
||||
system.<P>
|
||||
<H3 ID="ip-pool">ip_pool</H3>
|
||||
|
||||
<H3>l2tpns.ip_pool</H3>
|
||||
|
||||
This file is used to configure the IP address pool which user addresses are
|
||||
assigned from. This file should contain either an IP address or a IP mask
|
||||
per line. e.g.:<P>
|
||||
This file is used to configure the IP address pool which user
|
||||
addresses are assigned from. This file should contain either an IP
|
||||
address or a CIDR network per line. e.g.:<P>
|
||||
|
||||
<PRE>
|
||||
192.168.1.1
|
||||
|
|
@ -318,49 +362,70 @@ per line. e.g.:<P>
|
|||
10.0.0.0/8
|
||||
</PRE>
|
||||
|
||||
Keep in mind that L2TPNS can only handle 65535 connections per process, so
|
||||
don't put more than 65535 IP addresses in the configuration file. They will
|
||||
be wasted.
|
||||
Keep in mind that l2tpns can only handle 65535 connections per
|
||||
process, so don't put more than 65535 IP addresses in the
|
||||
configuration file. They will be wasted.
|
||||
|
||||
<H2>Controlling the process</H2>
|
||||
<H3 ID="build-garden">build-garden</H3>
|
||||
|
||||
A running L2TPNS process can be controlled in a number of ways. The primary
|
||||
The garden plugin on startup creates a NAT table called "garden" then
|
||||
sources the <B>build-garden</B> script to populate that table. All
|
||||
packets from gardened users will be sent through this table. Example:
|
||||
|
||||
<PRE>
|
||||
iptables -t nat -A garden -p tcp -m tcp --dport 25 -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p udp -m udp --dport 53 -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p tcp -m tcp --dport 53 -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p tcp -m tcp --dport 80 -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p tcp -m tcp --dport 110 -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p tcp -m tcp --dport 443 -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p icmp -m icmp --icmp-type echo-request -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p icmp -j ACCEPT
|
||||
iptables -t nat -A garden -j DROP
|
||||
</PRE>
|
||||
|
||||
<H2 ID="ControllingtheProcess">Controlling the Process</H2>
|
||||
|
||||
A running l2tpns process can be controlled in a number of ways. The primary
|
||||
method of control is by the Command-Line Interface (CLI).<P>
|
||||
|
||||
You can also remotely send commands to modules via the nsctl client
|
||||
provided. This currently only works with the walled garden module, but
|
||||
modification is trivial to support other modules.<P>
|
||||
|
||||
Also, there are a number of signals that L2TPNS understands and takes action
|
||||
Also, there are a number of signals that l2tpns understands and takes action
|
||||
when it receives them.
|
||||
|
||||
<H3>Command-Line Interface</H3>
|
||||
<H3 ID="Command-LineInterface">Command-Line Interface</H3>
|
||||
|
||||
You can access the command line interface by telnet'ing to port 23. There is
|
||||
no IP address restriction, so it's a good idea to firewall this port off
|
||||
from anyone who doesn't need access to it. See l2tpns.users for information
|
||||
on restricting access based on a username and password.<P>
|
||||
You can access the command line interface by telnet'ing to port 23.
|
||||
There is no IP address restriction, so it's a good idea to firewall
|
||||
this port off from anyone who doesn't need access to it. See
|
||||
<A HREF="#users">users</A> for information on restricting access based
|
||||
on a username and password.<P>
|
||||
|
||||
The CLI gives you real-time control over almost everything in
|
||||
the process. The interface is designed to look like a CISCO
|
||||
the process. The interface is designed to look like a Cisco
|
||||
device, and supports things like command history, line editing and
|
||||
context sensitive help. This is provided by linking with the <A
|
||||
HREF="http://sourceforge.net/projects/libcli">libcli</A> library.<P>
|
||||
context sensitive help. This is provided by linking with the
|
||||
<A HREF="http://sourceforge.net/projects/libcli">libcli</A>
|
||||
library. Some general documentation of the interface is
|
||||
<A HREF="http://sourceforge.net/docman/display_doc.php?docid=20501&group_id=79019">
|
||||
here</A>.<P>
|
||||
|
||||
After you have connected to the telnet port (and perhaps logged in), you
|
||||
will be presented with a prompt <PRE>l2tpns></PRE><P>
|
||||
will be presented with a <I>hostname</I><B>></B> prompt.<P>
|
||||
|
||||
You can type <EM>help</EM> to get a list of all possible commands, but this
|
||||
list could be quite long. A brief overview of the more important commands
|
||||
follows:
|
||||
Enter <EM>help</EM> to get a list of possible commands. A brief
|
||||
overview of the more important commands follows:
|
||||
|
||||
<UL>
|
||||
<LI><B>show session</B><BR>
|
||||
Without specifying a session ID, this will list all tunnels currently
|
||||
connected. If you specify a session ID, you will be given all information on
|
||||
a single tunnel. Note that the full session list can be around 185 columns
|
||||
wide, so you should probably use a wide terminal to see the list
|
||||
properly.<P>
|
||||
connected. If you specify a session ID, you will be given all
|
||||
information on a single tunnel. Note that the full session list can
|
||||
be around 185 columns wide, so you should probably use a wide terminal
|
||||
to see the list properly.<P>
|
||||
The columns listed in the overview are:
|
||||
<TABLE>
|
||||
<TR><TD><B>SID</B></TD><TD>Session ID</TD></TR>
|
||||
|
|
@ -392,6 +457,12 @@ The columns listed in the overview are:
|
|||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>show users</B><BR>
|
||||
With no arguments, display a list of currently connected users. If an
|
||||
argument is given, the session details for the given username are
|
||||
displayed.
|
||||
</LI>
|
||||
|
||||
<LI><B>show tunnel</B><BR>
|
||||
This will show all the open tunnels in a summary, or detail on a single
|
||||
tunnel if you give a tunnel id.<P>
|
||||
|
|
@ -458,27 +529,38 @@ You can reset these counters by running <EM>clear counters</EM>.
|
|||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>show cluster</B><BR>
|
||||
Show cluster status. Shows the cluster state for this server
|
||||
(Master/Slave), information about known peers and (for slaves) the
|
||||
master IP address, last packet seen and up-to-date status.<P>
|
||||
See <A HREF="#Clustering">Clustering</A> for more information.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>write memory</B><BR>
|
||||
This will write the current running configuration to the config file
|
||||
l2tpns.cfg, which will be run on a restart.
|
||||
<B>startup-config</B>, which will be run on a restart.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>snoop</B><BR>
|
||||
You must specify a username, which will be intercepted for the current
|
||||
session. Specify <EM>no snoop username</EM> to disable interception for the
|
||||
current session.<P>
|
||||
You must specify a username, IP address and port. All packets for the
|
||||
current session for that username will be forwarded to the given
|
||||
host/port. Specify <EM>no snoop username</EM> to disable interception
|
||||
for the session.<P>
|
||||
|
||||
If you want interception to be permanent, you will have to modify the radius
|
||||
response for the user. See <EM>Interception</EM>.
|
||||
response for the user. See <A HREF="#Interception">Interception</A>.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>throttle</B><BR>
|
||||
You must specify a username, which will be throttled for the current
|
||||
session. Specify <EM>no throttle username</EM> to disable throttling for the
|
||||
current session.<P>
|
||||
If you want throttling to be permanent, you will have to modify the radius
|
||||
response for the user. See <EM>Throttling</EM>.
|
||||
session. Specify <EM>no throttle username</EM> to disable throttling
|
||||
for the current session.<P>
|
||||
|
||||
If you want throttling to be permanent, you will have to modify the
|
||||
radius response for the user. See <A HREF="#THrottling">Throttling</A>.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
|
|
@ -496,22 +578,8 @@ after 10 seconds it will send a tunnel disconnect message.
|
|||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>load plugin</B><BR>
|
||||
Load a plugin. You must specify the plugin name, and it will search in
|
||||
/usr/lib/l2tpns for <EM>plugin</EM>.so. You can unload a loaded plugin with
|
||||
<EM>remove plugin</EM>.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>set</B><BR>
|
||||
Set a configuration variable. You must specify the variable name, and the
|
||||
value. If the value contains any spaces, you should quote the value with
|
||||
double quotes (").
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>uptime</B><BR>
|
||||
This will show how long the L2TPNS process has been running, and the current
|
||||
This will show how long the l2tpns process has been running, and the current
|
||||
bandwidth utilization:
|
||||
<PRE>
|
||||
17:10:35 up 8 days, 2212 users, load average: 0.21, 0.17, 0.16
|
||||
|
|
@ -528,21 +596,43 @@ IN and OUT are packets/per-second going between UDP-ETH and ETH-UDP.
|
|||
These counters are updated every second.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>configure terminal</B><BR>
|
||||
Enter configuration mode. Use <EM>exit</EM> or ^Z to exit this mode.
|
||||
The following commands are valid in this mode:<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>load plugin</B><BR>
|
||||
Load a plugin. You must specify the plugin name, and it will search in
|
||||
/usr/lib/l2tpns for <EM>plugin</EM>.so. You can unload a loaded plugin with
|
||||
<EM>remove plugin</EM>.
|
||||
<P>
|
||||
</LI>
|
||||
|
||||
<LI><B>set</B><BR>
|
||||
Set a configuration variable. You must specify the variable name, and
|
||||
the value. If the value contains any spaces, you should quote the
|
||||
value with double (") or single (') quotes.<P>
|
||||
|
||||
You can set any <A HREF="#startup-config">startup-config</A> value in
|
||||
this way, although some may require a restart to take effect.<P>
|
||||
</LI>
|
||||
</UL>
|
||||
|
||||
<H3>nsctl</H3>
|
||||
<H3 ID="nsctl">nsctl</H3>
|
||||
|
||||
nsctl was implemented (badly) to allow messages to be passed to modules.<P>
|
||||
|
||||
You must pass at least 2 parameters: <EM>host</EM> and <EM>command</EM>. The
|
||||
host is the address of the L2TPNS server which you want to send the message
|
||||
to.<BR>
|
||||
host is the address of the l2tpns server which you want to send the message
|
||||
to.<P>
|
||||
|
||||
Command can currently be either <EM>garden</EM> or <EM>ungarden</EM>. With
|
||||
both of these commands, you must give a session ID as the 3rd parameter.
|
||||
This will activate or deactivate the walled garden for a session
|
||||
temporarily.
|
||||
|
||||
<H3>Signals</H3>
|
||||
<H3 ID="Signals">Signals</H3>
|
||||
|
||||
While the process is running, you can send it a few different signals, using
|
||||
the kill command.
|
||||
|
|
@ -552,25 +642,19 @@ killall -HUP l2tpns
|
|||
|
||||
The signals understood are:
|
||||
<UL>
|
||||
<LI>SIGHUP - Reload the config from disk<P></LI>
|
||||
<LI>SIGHUP - Reload the config from disk and re-open log file<P></LI>
|
||||
<LI>SIGTERM / SIGINT - Shut down for a restart. This will dump the current
|
||||
state to disk (if <EM>save_state</EM> is set to true). Upon restart, the
|
||||
process will read this saved state to resume active sessions.<P>
|
||||
This is really useful when doing an upgrade, as the code can change without
|
||||
dropping any users. However, if the internal structures such as
|
||||
<EM>sessiont</EM> or <EM>tunnelt</EM> change, then this saved state file
|
||||
will not reload, and none of the sessions will be recreated. This is bad.<P>
|
||||
If these structures do change, you should kill the server with SIGQUIT,
|
||||
which won't dump the state.</LI>
|
||||
<LI>SIGQUIT - Shut down cleanly. This will send a disconnect message for
|
||||
every active session and tunnel before shutting down. This is a good idea
|
||||
when upgrading the code, as no sessions will be left with the remote end
|
||||
thinking they are open.</LI>
|
||||
</UL>
|
||||
|
||||
<H2>Throttling</H2>
|
||||
<H2 ID="Throttling">Throttling</H2>
|
||||
|
||||
L2TPNS contains support for slowing down user sessions to whatever speed you
|
||||
l2tpns contains support for slowing down user sessions to whatever speed you
|
||||
desire. You must first enable the global setting <EM>throttle_speed</EM>
|
||||
before this will be activated.<P>
|
||||
|
||||
|
|
@ -581,28 +665,10 @@ will be handled by the <EM>autothrottle</EM> module.<P>
|
|||
Otherwise, you can enable and disable throttling an active session using
|
||||
the <EM>throttle</EM> CLI command.<P>
|
||||
|
||||
Throttling is actually performed using a combination of iptables and tc.<BR>
|
||||
First, a HTB bucket is created using tc (unless one is already created and
|
||||
unused).<BR>
|
||||
Secondly, an iptables rule is inserted into the throttle chanin in the
|
||||
mangle table so all packets destined for the user's IP address go into the
|
||||
HTB.<P>
|
||||
|
||||
You can check the packets being throttled using the tc command. Find the HTB
|
||||
handle by doing <EM>show session id</EM> in the CLI, next to the Filter
|
||||
Bucket tag. Then at the shell prompt, you can run:
|
||||
<PRE>
|
||||
tc -s class ls dev tun0 | grep -A3 <EM>1:870</EM>
|
||||
class htb 1:870 root prio 0 rate 28Kbit ceil 28Kbit burst 15Kb cburst 1634b
|
||||
Sent 27042557 bytes 41464 pkts (dropped 1876, overlimits 0)
|
||||
lended: 41471 borrowed: 0 giants: 0
|
||||
tokens: 3490743 ctokens: 353601
|
||||
</PRE>
|
||||
|
||||
<H2>Interception</H2>
|
||||
<H2 ID="Interception">Interception</H2>
|
||||
|
||||
You may have to deal with legal requirements to be able to intercept a
|
||||
user's traffic at any time. L2TPNS allows you to begin and end interception
|
||||
user's traffic at any time. l2tpns allows you to begin and end interception
|
||||
on the fly, as well as at authentication time.<P>
|
||||
|
||||
When a user is being intercepted, a copy of every packet they send and
|
||||
|
|
@ -621,11 +687,11 @@ need to modify the radius response to include the Vendor-Specific value
|
|||
<B>Cisco-Avpair="intercept=yes"</B>. For this feature to be enabled,
|
||||
you need to have the <EM>autosnoop</EM> module loaded.<P>
|
||||
|
||||
<H2>Authentication</H2>
|
||||
<H2 ID="Authentication">Authentication</H2>
|
||||
|
||||
Whenever a session connects, it is not fully set up until authentication is
|
||||
completed. The remote end must send a PPP CHAP or PPP PAP authentication
|
||||
request to L2TPNS.<P>
|
||||
request to l2tpns.<P>
|
||||
|
||||
This request is sent to the radius server, which will hopefully respond with
|
||||
Auth-Accept or Auth-Reject.<P>
|
||||
|
|
@ -642,9 +708,9 @@ PPP AUTHACK, but their session is flagged as being a garden'd user, and they
|
|||
should not receive any service.<P>
|
||||
|
||||
The radius reply can also contain a Vendor-Specific attribute called
|
||||
Cisco-Avpair. This field is a freeform text field that most CISCO
|
||||
Cisco-Avpair. This field is a freeform text field that most Cisco
|
||||
devices understand to contain configuration instructions for the session. In
|
||||
the case of L2TPNS it is expected to be of the form
|
||||
the case of l2tpns it is expected to be of the form
|
||||
<PRE>
|
||||
key=value,key2=value2,key3=value3,key<EM>n</EM>=<EM>value</EM>
|
||||
</PRE>
|
||||
|
|
@ -658,16 +724,16 @@ contain:
|
|||
intercept=yes,throttle=yes
|
||||
</PRE>
|
||||
|
||||
<H2>Plugins</H2>
|
||||
<H2 ID="Plugins">Plugins</H2>
|
||||
|
||||
So as to make L2TPNS as flexible as possible (I know the core code is pretty
|
||||
So as to make l2tpns as flexible as possible (I know the core code is pretty
|
||||
difficult to understand), it includes a plugin API, which you can use to
|
||||
hook into certain events.<P>
|
||||
|
||||
There are a few example modules included - autosnoop, autothrottle and
|
||||
garden.<P>
|
||||
|
||||
When an event happens that has a hook, L2TPNS looks for a predefined
|
||||
When an event happens that has a hook, l2tpns looks for a predefined
|
||||
function name in every loaded module, and runs them in the order the modules
|
||||
were loaded.<P>
|
||||
|
||||
|
|
@ -828,7 +894,7 @@ supplied structure:
|
|||
</TABLE>
|
||||
</TD></TR></TABLE>
|
||||
|
||||
<H2>Walled Garden</H2>
|
||||
<H2 ID="WalledGarden">Walled Garden</H2>
|
||||
|
||||
Walled Garden is implemented so that you can provide perhaps limited service
|
||||
to sessions that incorrectly authenticate.<P>
|
||||
|
|
@ -840,24 +906,18 @@ radius server responds with Auth-Reject, the walled garden module
|
|||
the <B>garden_users</B> chain to force all packets for the session's IP
|
||||
address to traverse the <B>garden</B> chain.<P>
|
||||
|
||||
This doesn't <EM>just work</EM>. To set this all up, you will need to create
|
||||
2 iptables chains on the nat table - <B>garden</B> and <B>garden_users</B>.
|
||||
<PRE>
|
||||
iptables -t nat -N garden
|
||||
iptables -t nat -F garden
|
||||
iptables -t nat -N garden_users
|
||||
iptables -t nat -F garden_users
|
||||
</PRE>
|
||||
|
||||
You should add rules to the <B>garden</B> chain to limit user's traffic. For
|
||||
example, to force all traffic except DNS to be forwarded to 192.168.1.1, add
|
||||
these entries to your firewall startup script:
|
||||
This doesn't <EM>just work</EM>. To set this all up, you will to
|
||||
setup the <B>garden</B> nat table with the
|
||||
<A HREF="#build-garden">build-garden</A> script with rules to limit
|
||||
user's traffic. For example, to force all traffic except DNS to be
|
||||
forwarded to 192.168.1.1, add these entries to your
|
||||
<EM>build-garden</EM>:
|
||||
<PRE>
|
||||
iptables -t nat -A garden -p tcp --dport ! 53 -j DNAT --to 192.168.1.1
|
||||
iptables -t nat -A garden -p udp --dport ! 53 -j DNAT --to 192.168.1.1
|
||||
</PRE>
|
||||
|
||||
L2TPNS will add entries to the garden_users chain as appropriate.<P>
|
||||
l2tpns will add entries to the garden_users chain as appropriate.<P>
|
||||
|
||||
You can check the amount of traffic being captured using the following
|
||||
command:
|
||||
|
|
@ -865,11 +925,54 @@ command:
|
|||
iptables -t nat -L garden -nvx
|
||||
</PRE>
|
||||
|
||||
<H2>Clustering</H2>
|
||||
<H2 ID="Clustering">Clustering</H2>
|
||||
|
||||
Clustering is currently broken. But here's how it's supposed to work.<P>
|
||||
An l2tpns cluster consists of of one* or more servers configured with
|
||||
the same configuration, notably the multicast <B>cluster_address</B>.<P>
|
||||
|
||||
<H2>Performance</H2>
|
||||
*A stand-alone server is simply a degraded cluster.<P>
|
||||
|
||||
Initially servers come up as cluster slaves, and periodically (every
|
||||
<B>cluster_hb_interval</B>/10 seconds) send out ping packets
|
||||
containing the start time of the process to the multicast
|
||||
<B>cluster_address</B>.<P>
|
||||
|
||||
A cluster master sends heartbeat rather than ping packets, which
|
||||
contain those session and tunnel changes since the last heartbeat.<P>
|
||||
|
||||
When a slave has not seen a heartbeat within
|
||||
<B>cluster_hb_timeout</B>/10 seconds it "elects" a new master by
|
||||
examining the list of peers it has seen pings from and determines
|
||||
which of these and itself is the "best" candidate to be master.
|
||||
"Best" in this context means the server with the highest uptime (the
|
||||
highest IP address is used as a tie-breaker in the case of equal
|
||||
uptimes).<P>
|
||||
|
||||
After discovering a master, and determining that it is up-to-date (has
|
||||
seen an update for all in-use sessions and tunnels from heartbeat
|
||||
packets) will raise a route (see <A HREF="#Routing">Routing</A>) for
|
||||
the <B>bind_address</B> and for all addresses/networks in
|
||||
<B>ip_pool</B>. Any packets recieved by the slave which would alter
|
||||
the session state, as well as packets for throttled or gardened
|
||||
sessions are forwarded to the master for handling. In addition, byte
|
||||
counters for session traffic are periodically forwarded.<P>
|
||||
|
||||
A master, when determining that it has at least one up-to-date slave
|
||||
will drop all routes (raising them again if all slaves disappear) and
|
||||
subsequently handle only packets forwarded to it by the slaves.<P>
|
||||
|
||||
<H2 ID="Routing">Routing</H2>
|
||||
If you are running a single instance, you may simply statically route
|
||||
the IP pools to the <B>bind_address</B> (l2tpns will send a gratuitous
|
||||
arp).<P>
|
||||
|
||||
For a cluster, configure the members as BGP neighbours on your router
|
||||
and configure multi-path load-balancing. Cisco uses "maximum-paths
|
||||
ibgp" for IBGP. If this is not supported by your IOS revision, you
|
||||
can use "maximum-paths" (which works for EBGP) and set
|
||||
<B>as_number</B> to a private value such as 64512.<P>
|
||||
|
||||
<H2 ID="Performance">Performance</H2>
|
||||
|
||||
Performance is great.<P>
|
||||
|
||||
|
|
|
|||
2
INSTALL
2
INSTALL
|
|
@ -2,7 +2,7 @@ Brief Installation guide for L2TPNS
|
|||
|
||||
1. Requirements
|
||||
|
||||
* libcli 1.7.0 or greater
|
||||
* libcli 1.8.0 or greater
|
||||
You can get it from http://sourceforge.net/projects/libcli.
|
||||
|
||||
* A kernel with iptables support.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue