надо man ppp на предмет -nat :))
Либо если не терпится пользоваться natd, то:
sysctl -w net.inet.ip.forwarding=1
natd -n ppp0
а дальше через ipfw добавляешь вот такие правила:
01000 divert 8668 ip from _клиентский_адрес_ to not _адрес_твоей_сети_ out
xmit ppp0
01100 divert 8668 ip from not _адрес_твоей_сети_ to _адрес_ррр_соединения in
recv ppp0
Правило 1000 размножить на каждый адрес, либо собрать нужных юзеров в маску
и засунуть туда вместо "_клиентский_адрес_"
# Дивертим все пакеты на natd
ipfw -f add divert natd all from any to any via ppp0
# Небольшой пример как ограничить трафик до 32 Kbit/s для адресов .10 и .11
/sbin/ipfw -f pipe 1 config bw 32Kbit/s
/sbin/ipfw -f add pipe 1 ip from any to 192.168.10.10
/sbin/ipfw -f add pipe 1 ip from any to 192.168.10.11
# Если нет других правил для firewall, то раздешаем все.
ipfw -f add allow all from any to any
This HowTo describes the theory behind NAT, and the use of natd(8)
to accomplish designing a network with NAT. It covers issues such as
setting up the kernel and ipfw to enable natd(8), specifying alias
addresses, port and address forwarding, setting up a configuration file,
and setting up natd(8) to start at boot time.
1. Background
1.1. What is NAT?
1.2. The Basic Theory
1.3. Internet / Registered & Unregistered IP Addresses
1.4. Overcoming Your Shortage of Internet Addresses
The basic goal of NAT (Network Address Translation), also known as
IP Masquerading, is to allow a private network protected access to an
outer network, such as the internet, such that no node in the private
network can be directly accessed from the outside, but all nodes on the
inside can have clear access to all nodes on the outside. This is
accomplished through the use of addressing private IP addresses to the
private network and then translating them to (masquerading them as) public
IP addresses that the outer network can route. This is accomplished
through the use of natd(8).
1.2. The Basic Theory
To illustrate natd(8) in action, let us take the following sample
network as an example:
Network A -------- PC #1 --------- PC #2
Let us assume that PC #1 has direct access to Network A, that is,
it can send out data packets directly addressed to any PC in Network A and
they will reach their destination, and the other way around as well. Now,
let us assume that PC #2, which is connected to PC #1, also needs access
to Network A, however, you do not wish any PC in Network A to be able to
directly access PC #2, that is, you do not wish any PC in Network A to be
able to send a data packet to PC #2's IP address and have it reach its
destination. Alternatively, wishing to protect PC #2 from being able to be
directly accessed by any PC in Network A, you do wish it to somehow retain
access to any PC in Network A.
The solution is to translate IP addresses as they move between PC
#1, hence the acronym 'Network Address Translation': NAT. As packets move
from PC #2 to PC #1, you can translate them as if they were coming from a
different address, remember which packets were translated, and when
responces to these packets come back from Network A allow them to pass
through to PC #2. In this fasion, packets from the outside when responding
to packets from PC #2 do not aim their destination at PC #2's address, but
at the proxy address that the outgoing packets were masked as. Let us
illustrate this in more concrete terms taking the following enhanced
sample network:
192.168.0.3
PC #3
|
|
|
| 192.168.0.5 192.168.0.1 10.0.0.1
----------- Gateway A -------- PC #1 --------- PC #2
|
|
|
|
PC #4
192.168.0.4
Let us assume that Network A consists of PC #3, PC #4 and Gateway
A. PC #3 attempts to send some data packets to PC #1. The packets pass to
Gateway A who in turn routes them to PC #1 - their destination is reached.
Next PC #1 responds with its own data packets, and they reach PC #3. After
this, you wish to send data packets from PC #2 to PC #3. The data packets
first reach PC #1 who, running natd(8), translates the packets coming from
PC #2 as if they were coming from itself - from PC #1. That is, the source
address of all packets going from PC #2 is changed from 10.0.0.1 to
192.168.0.1, and then they are sent. A table is kept of all packets which
were translated in this fashion, and when later PC #3 responds with his
own packets, thinking his responce packets should be sent to 192.168.0.1,
they come to PC #1, where the destination addresses of those packets are
changed from 192.168.0.1 to 10.0.0.1 and they are sent to PC #2
accordingly. It is clear why this is also termed "IP Masquerading," as one
PC's packets masquerade as that of another.
Clearly, a connexion between PC #2 and PC #3 can be easily
facilitated when PC #2 sends out packets, first which, after being
translated, sit in the NAT table in PC #1 awaiting responces, however,
when PC #3 attempts to send data packets first to PC #2 (but addressing
them to 192.168.0.1 as it had before, thinking this is the address for PC
#2 as well) no corresponding entries in the NAT table exist, so the
packets are not translated and sent to PC #2, but instead remain at PC #1,
clearly missing their intended destination of PC #2.
Because PC #3 never sees packets coming from PC #2 whose source is
addressed as 10.0.0.1 it does not know to send any packets to 10.0.0.1. If
it does learn 10.0.0.1 is the address of PC #2, it can, however, in our
simple network situation, reach its destination unless there is a firewall
at PC #1 blocking all packets that are directly addressed as 10.0.0.1 for
PC #2.
1.3 Internet / Registered & Unregistered IP Addresses
In the real world, however, particularly when Network A is the
internet, there is a facility for private networks that does not have this
added complication. There are three IP address ranges reserved for private
use such that no packet from the internet addressed to them will reach
it's intended destination.
These three private (unregistered) address ranges are:
They are intended solely for private networks and as such are not
assigned as official IP addresses for internet connected computers, and
are termed "unregistered". If data packets are sent to an IP address in
one of these ranges and a computer in the immediate network is not
assigned that number, once they are sent to an ISP or whatever upstream
privider you have, they will either be blocked by a firewall or routed to
a computer on another private network by that address, or perhaps routed
into some other dead end. Simply put, only use them for private networks.
Let us now slightly adjust our sample network:
201.160.20.83
PC #3
|
|
|
| 208.1.56.3 208.1.53.45 10.0.0.1
----------- Gateway A -------- PC #1 --------- PC #2
|
|
|
|
PC #4
30.10.87.132
In this example PC #3 is assigned a legitimate internet IP address
and PC #2 is not. If PC #3 attempts to directly send data packets
addressed to 10.0.0.1 on PC #2 they will never reach their destination;
indeed, tens of thousands of PCs around the may be addressed 10.0.0.1 as
an address on a private network. Data packes from PC #2 can, however, as
illustrated earler, mask their source IP as PC #1's address of 209.1.53.45
and then successfully be routed across the internet and received responces
from any node on the internet through NAT.
1.4 Overcoming Your Shortage of Internet Addresses
This is an excellent solution when one wishes to have more PCs
access the internet than they have internet IP addresses to assign them.
It is also a solution, as was offered earlier, for securely protecting a
PC from being directly accessed by some computer in an outer network, in
this case the Internet. One shortcoming is that no PC behind NAT can act
as a server to the outer network because no node from the outer network
can initiate a connexion to make use of it. Connexions must be initiated
by the PC behind NAT.
2. Deployment
2.1. Kernel Options
To successfully deploy natd(8) on FreeBSD one must be at least
mildly familiar with ipfw(8) AND one must have root privileges. Kernel
options and firewall rules can not be changed by anyone but root. To
enable ipfw(8) the following option must be enabled in the kernel:
options IPFIREWALL
Because natd(8) also uses the divert(4) kernel packet diversion
mechanism the following option must also be enabled in the kernel:
options IPDIVERT
To learn how to compile a custom kernel with these options if they
are not already enabled, please refer to the FreeBSD Handbook
(http://www.freebsd.org/handbook/).
2.2. Enabling Packet Forwarding
Now, one must enable packet forwarding so that the PC can forward
packets coming to it from the private LAN out into the Internet. To ensure
that packet forwarding is automatically enabled when you boot the system,
enable make sure the following line is set properly in /etc/rc.conf :
gateway_enable=YES
Once this is done, one can reboot the system, however, this is
wholly unnecessary as packet forward can now be set during run-time by
issuing the following command:
sysctl -w net.inet.ip.forwarding=1
2.3. ipfw(8) and divert(4)
Once this is accomplished, a rule must be added to your ipfw
filtering rules that diverts packets to natd(8) so they can be translated.
To view your ipfw(8) rules, issue the command: "ipfw list". A possible
simple ipfw(8) rule set may appear thusly:
(root@box)~># ipfw list
01000 allow ip from any to any via lo0
65000 allow ip from any to any
65535 deny ip from any to any
(root@box)~>#
As you may later add addition rules, you want the rule that
diverts packets to natd(8) to be activated as early as possible,
otherwise, if you, for instance, filter ICMP packets destined for the
gateway on which natd(8) is running, and the filter rule comes before the
divert rule to natd(8) those IMCP packets will be filtered out even if
they had actually been destined for a PC on the private network because
natd(8) would not have had an opportunity to translate the destination
address from that of the gateway to that of the other PC. In this
instance, if the PC on the private network were to send ICMP packets
trying to ping a host on the internet, the responces would never return.
As such, packets should first be diverted to natd(8) for translation,
unless there are certain firewall rules that you wish to apply to all
computers on your network.
To divert packets to natd(8) the following rule can be applied:
ipfw add 500 divert natd all from any to any via tun0
This rule assumes that tun0 is your network interface that
connects you to the outside network. This assumption clearly may be wrong.
As you can see, rule number 500 is given this particular rule so that it
is pretty early in the rule set - in the case of the example rule set
suppled earlier, it is the very first rule.
So that ipfw(8) knows on what port to look for natd(8) make sure
that a corresponding entry for natd(8) is found in /etc/services. To
quickly verify that an entry exists for natd(8) in the services file,
issue the following command:
In our case the entry exists. In most cases it should, unless the
/etc/services file has been tampered with. The default socket that natd(8)
binds to is 8668, as such, our ipfw rule can also have been issued thusly:
ipfw add 500 divert 8668 all from any to any via tun0
"natd" is an alias for port "8668" insolong as an entry defining
this relationship is found in /etc/services.
For the divert rule to become enabled during every startup, and to
ensure that the firewall doesn't block ALL traffic, the firewall rules
must be adjusted in /etc/rc.firewall after firewall_enable=YES and
firewall_type=OPEN are set in /etc/rc.conf.
For our example network adding the following line into
/etc/rc.firewall should be sufficient:
/sbin/ipfw add 500 divert 8668 all from any to any via tun0
This will create a very "OPEN" firewall upon reboot. It is
strongly recommended that one learns how to further configure the
firewall.
2.4. natd(8) arguments
Once the divert rule has been issued, all packets coming and going
through tun0 (or the network device by which you are connected to the
outside) will be filtered through natd(8).
2.4.1. Basic Usage
In the simplest situation, we want all packets coming through
natd(8) to be translated into your gateway PC's IP address. To run natd(8)
such that it would supply this basic service we would activate it with the
following arguments:
/usr/sbin/natd -interface tun0
natd(8) would run in the background as a daemon, translating all
packets that are diverted through it to have a source IP address that of
the gateway. In our example network, this would be the IP address of:
208.1.53.45 .
2.4.2. More Complex Usage
However, let us take the following slightly more complex network
example:
Let us now slightly adjust our sample network:
208.1.53.45 10.0.0.1
Internet -------- PC #1 --------- PC #2
|
|
|
|
|
PC #3
208.1.53.46
In this instance, there are two PCs on the private of which only
one has a private IP address and the other an official internet IP
address. If you do not wish natd(8) to translate packets coming from PC #3
but only those of PC #2, running natd(8) with the following arguments
would accomplish this:
/usr/sbin/natd -unregistered_only -interface tun0
Here, only the unregistered addresses would be translated. In this
instance, there is only one, that of PC #2. PC #3 would retain normal
access to the interent, using its own IP address.
Now, instead of supplying the interface which natd(8) should
monitor for incoming and outgoing packets to translate, the actual IP
address to translate the packets to/from can be given. This would be
particularly useful if one does not wish to translate address to the IP
address of the gateway, but of some other PC, which may be needed in more
complex networking scenarios. Giving natd(8) the specific IP to translate
packets to/from can be accomplished with issuing the following:
Here, all packets from unregistered IP addresses going out will be
translated as having originated from 208.1.53.45.
If the arguments given natd(8) seem to be verbose, they are. In
fact, there are shortened version for each argument that can be given. The
list of shorter versions for the three arguments we have seen so far, and
three additional arguments we will cover in a moment, are:
Long Version Short Version
-------------------------------------
The -port argument allows natd(8) to bind to a different port than
its default one of 8668. Once this is used, the ipfw(8) divert(4) rule
will need to be adjusted so that packets are diverted to the correct
"-port"-specified port to which natd(8) has bound. An example of this
argument in action would be:
Port and Address are some of the most complex issues with NAT,
yet, often become a necessity for either lack of registered IPs and the
desire to run servers from behind NAT, or for security reasons, utilizing
NAT as a poor man's firewall.
Let us presume that one has a three box LAN. The gateway is
running ipfw(8) and natd(8), and the first box behind NAT is to be used as
an ftp server and the second is to be used as a telnet server. Because of
the nature of NAT, as described in the first section of this Howto, direct
connexions to either the internal ftp or telnet servers from outside NAT
are not possible. All packets will terminate at the gateway. To circumvent
this, the packets can then, at the gateway, be forwarded to either the ftp
or telnet server. How will the gateway know to do this? All packets
reaching port 20 (data port for FTP) or 21 (control port for FTP) can be
forwarded to the internal FTP server. Likewise, all packets reaching port
23 on the gateway can be forwarded to the internal telnet server. This is
called port forwarding. The primary shortcoming of this setup is that the
gateway itself will be unable to server either telnet or ftp on their
regular ports. In short, the gateway can not offer any services which
require ports that are being forwarded to internal boxes in the LAN. The
following diagram illustrates the above Internal FTP and Telnet network
topology clearly.
201.160.20.83
Remote PC #1
|
|
|
_//_ 208.1.56.3 10.0.0.1 10.0.0.2
/ 20,21,23 20,21 23
|INTERNET|------- Gateway A ----- FTP Server ------ Telnet -O
_ _/
//
|
|
|
Remote PC #2
30.10.87.132
The syntax for the port forwarding option, -redirect_port, in the
natd(8) man page initially looks daunting, but it really isn't. In the
most simple usage, to enable the port forwarding for the Telnet server,
the following will suffice presuming the alias interface is pe0:
If the gateway has numerous alias IPs on the external interface,
then it can be specified packets directed to which of those IPs - in our
example, 208.1.56.4 - will be forwarded to the internal Telnet server:
Finally, if one wishes to specify the remote IPs whose packets
will be allowed to be forwarded to the internal Telnet server, the
following would accomplish this, if the remote IP is 30.10.87.132 and the
gateway, unlike in the previous example, has no aliases:
Finally, if one wishes to specify the remote IPs *and* range of
ports whose packets will be allowed to be forwarded to the internal Telnet
server, the following would accomplish this:
In this example, only telnet requests originating from ports 100
through 110 on the remote IP 30.10.87.132 will be forwarded to port 23 on
the internal Telnet server 10.0.0.2. This is a very peculiar specification
and is only presented here as a hypothetical usage of the controlling the
remote IP and ports with the -redirect_port option.
Keep in mind, that single ports and range of ports can be
specified following any IP and ':'. To specify a range, a '-' is used,
like in the above example. Single ports can be specified by simply
following the ':' on their own. Only the IP of the internal server to whom
the ports are being forwarded is necessary. Remote IPs need not be
specified if it's not required to control what remote IPs packets will
be forwarded from, and the alias IP on the gateway need not be specified
if there is only one registered IP on the external interface. In short,
the first form for port redirection is the one that will suffice for the
vast majority of circumstances.
If an IP is not specified for the internal server to whom to
forward the ports, then natd(8) will assume ports are being forwarded on
the local box, i.e. the gateway. That is the most minimalistic usage of
the -redirect_port option, as shown below:
In this example, all telnet requests to port 6666 on the gateway
will be forwarded to port 23 on the gateway. To complete the initial
example, to forward FTP to the internal FTP server along with Telnet to
the internal Telnet server, the following natd(8) usage would accomplish
this, presuming the external interface on the gateway is pe0:
The parameters to natd(8) can get lengthy and cumbersome such that
using a configuration file instead, as explained in section 2.4.3,
is recommended. In addition, UDP packets are also supported for
forwarding. To do this, simply specify "udp" instead of "tcp" in the
prototype section directly following the option "-redirect_port." Most
services are tcp, such as FTP, Telnet, Finger, SSH, etc.
Address redirection with natd(8) is very similar. In short, it
allows the gateway to redirect all packets destined for one IP to an
internal IP address. This is also called as "Static NAT." It is most
useful where one has multiple registered IPs, such that all packets to one
will get redirected to an internal server behind NAT whilst packets to
another IP would be served by the gateway itself, or another internal
server. This clearly presumes that the external interface on the gateway
has multiple IPs aliased on it.
The syntax for address redirection is simple. Presuming the we
wish to redirect all packets destined for the IP address 208.1.56.4 on the
gateway to an internal server 10.0.0.3, the following usage would
accomplish this:
The usage is far more simple as one needs not specify packet types
(UDP, TCP) or ports to be specifically forwarded.
2.4.3. Configuration File
Finally, if there are too many arguments to pass to natd(8) to
make it deemed practical, the -config argument can be passed to natd(8)
followed by the configuration file that would hold all of the arguments
that would normally be passed in on the command line.
Let us say we wished to store the following list of arguments to
be passed to natd(8) in /etc/natd.cf :
And all of the configuration options in /etc/natd.cf would take hold.
2.5. Starting natd(8) at Boot Time
FreeBSD 3.x offers extra options to simplify starting natd(8) at
boot time, however, it is just as doable with FreeBSD 2.2.x. The process
with both versions is simple.
For the following examples, we will presume the external interface
on your gateway is pe0 and that you are using a configuration file as
described in section 2.4.3.
With FreeBSD 3.x, open /etc/rc.conf and add the following lines:
In section 3.4.3 where configuration files were explained, we
specified the natd(8) interface inside /etc/natd.cf so it would not have
to be specified again here, however, if one wishes, one can remove the
line specifying the alias IP or interface in the /etc/natd.cf and instead
do the following:
With FreeBSD 2.2.x, open /etc/rc.local and add the following
line:
/usr/sbin/natd -f /etc/natd.cf && echo -n ' natd'
This will initialize natd with all options in /etc/natd.cf, and
unlike with FreeBSD 3.x, where the alias IP or address can be specified
separately in /etc/rc.conf, the alias IP or address must be specified in
/etc/natd.cf with FreeBSD 2.2.x.
Note, this FreeBSD 2.2.x method for initializing natd(8) can be
used on a FreeBSD 3.x system instead of the method outlined for FreeBSD
3.x previously.
3. Appendix
Manual Page resources:
8 natd
4 divert
425 Прочтений • [[FreeBSD] трансляция адресов через natd и ограничение трафика (nat freebsd traffic limit shaper)] [08.05.2012] [Комментариев: 0]
Vova
