The OpenNET Project / Index page
BSD, Linux, Cisco, Web, Palm, другие
english version

Хинт: Есть вопросы на которые вы так и не смогли найти ответ ? Обратитесь к другим специалистам в форуме.
SOFT - Обзоры лучших программ
LINKS - Ссылки на unix ресурсы
TOPIC - Тематические статьи
NEWS - Раздел новостей (сводные)

[FreeBSD] трансляция адресов через natd и ограничение трафика (nat freebsd traffic limit shaper)

<< Предыдущая ИНДЕКС Поиск в статьях src,palm Установить закладку Перейти на закладку Следующая >>
Ключевые слова: nat, freebsd, traffic, limit, shaper,  (найти похожие документы)
From: Vladimir Sharun <> Newsgroups: Date: 3 Nov 2000 12:25:00 +0300 Subject: [FreeBSD] трансляция адресов через natd и ограничение трафика >ns# netstat -rn | egrep "UG|UC|UHLWb" >default UGSc 92 1072 ppp0 >192/16 link#1 UC 0 0 ed1 надо 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 размножить на каждый адрес, либо собрать нужных юзеров в маску и засунуть туда вместо "_клиентский_адрес_" --> WBR Vladimir Sharun ------------------------------------------------------------------- PS by mc: мой работающий конфиг для трансляции адресов под FreeBSD natd -use_sockets -same_ports -unregistered_only -dynamic -interface ppp0 ipfw -f flush # Дивертим все пакеты на 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 /sbin/ipfw -f add pipe 1 ip from any to # Если нет других правил для firewall, то раздешаем все. ipfw -f add allow all from any to any ------------------------------------------------------------------------- Более подробно о NAT читайте ниже: Summary. 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 2. Deployment 2.1. Kernel Options 2.2. Enabling Packet Forwarding 2.3. ipfw(8) and divert(4) 2.4. natd(8) arguments 2.4.1. Basic Usage 2.4.2. More Complex Usage Port & Address Redirection 2.4.3. Configuration File 2.5. Starting natd(8) at Boot Time 3. Appendix 1. Background. 1.1. What is NAT? 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: PC #3 | | | | ----------- Gateway A -------- PC #1 --------- PC #2 | | | | PC #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 to, 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, they come to PC #1, where the destination addresses of those packets are changed from to 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 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 it does not know to send any packets to If it does learn 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 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: PC #3 | | | | ----------- Gateway A -------- PC #1 --------- PC #2 | | | | PC #4 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 on PC #2 they will never reach their destination; indeed, tens of thousands of PCs around the may be addressed 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 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 ( 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: (root@box)~># cat /etc/services | grep natd natd 8668/divert #Network Address Translation Socket (root@box)~># 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: . 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: Internet -------- PC #1 --------- PC #2 | | | | | PC #3 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: /usr/sbin/natd -unregistered_only -alias_address Here, all packets from unregistered IP addresses going out will be translated as having originated from 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 ------------------------------------- -alias_address -a -config -f -log -l -interface -n -port -p -unregistered_only -u 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: /usr/sbin/natd -port 8667 -unregistered_only -interface pe0 The -log argument simply specifies to take logs of natd(8) activity. The log file is /var/log/alias.log . Am example of its usage would be: /usr/sbin/natd -log -unregistered_only -interface pe0 Port & Address Redirection 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. Remote PC #1 | | | _/\/\_ / \ 20,21,23 20,21 23 |INTERNET|------- Gateway A ----- FTP Server ------ Telnet -O \_ _/ \/\/ | | | Remote PC #2 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: /usr/sbin/natd -redirect_port tcp 23 -interface 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, - will be forwarded to the internal Telnet server: /usr/sbin/natd -redirect_port tcp -interface pe0 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 and the gateway, unlike in the previous example, has no aliases: /usr/sbin/natd -redirect_port tcp 23 -interface pe0 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: /usr/sbin/natd -redirect_port tcp 23 -interface pe0 In this example, only telnet requests originating from ports 100 through 110 on the remote IP will be forwarded to port 23 on the internal Telnet server 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: /usr/sbin/natd -redirect_port tcp 23 6666 -interface pe0 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: /usr/sbin/natd -redirect_port tcp 20-21 -redirect_port tcp 23 -interface 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 on the gateway to an internal server, the following usage would accomplish this: /usr/sbin/natd -redirect_address -interface pe0 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/ : -unregistered_only -alias_address -log We could do the following: (root@box)~># echo "unregistered_only" > /etc/ (root@box)~># echo "alias_address" >> /etc/ (root@box)~># echo "log" >> /etc/ And our new configuration file /etc/ would contain: (root@box)~># cat /etc/ unregistered_only alias_address log (root@box)~># Now, we would only need to start natd(8) thusly: (root@box)~># /usr/sbin/natd -f /etc/ (root@box)~># And all of the configuration options in /etc/ 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: natd_enable="YES" natd_interface="" natd_flags="-f /etc/" In section 3.4.3 where configuration files were explained, we specified the natd(8) interface inside /etc/ 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/ and instead do the following: natd_enable="YES" natd_interface="pe0" natd_flags="-f /etc/" In addition, if one wishes to specify the alias IP address instead of the interface, one can do the following, presuming the alias IP is natd_enable="YES" natd_interface="" natd_flags="-f /etc/" With FreeBSD 2.2.x, open /etc/rc.local and add the following line: /usr/sbin/natd -f /etc/ && echo -n ' natd' This will initialize natd with all options in /etc/, 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/ 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

<< Предыдущая ИНДЕКС Поиск в статьях src,palm Установить закладку Перейти на закладку Следующая >>

Ваш комментарий

Добавить в закладки
Created 1996-2002 by Maxim Chirkov  
SpyLOG TopList
RB2 Network.
RB2 Network.