The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: sect2/para
English
For networks that have large numbers of internal systems or multiple subnets, the process of funneling every private <acronym>IP</acronym> address into a single public <acronym>IP</acronym> address becomes a resource problem. Two methods are available to relieve this issue.
0/2740 · 274
Context English Turkish (tr_TR) State
# interface facing Internet (inbound)
# Block all inbound traffic from non-routable or reserved address spaces
block in quick on dc0 from 192.168.0.0/16 to any #RFC 1918 private IP
block in quick on dc0 from 172.16.0.0/12 to any #RFC 1918 private IP
block in quick on dc0 from 10.0.0.0/8 to any #RFC 1918 private IP
block in quick on dc0 from 127.0.0.0/8 to any #loopback
block in quick on dc0 from 0.0.0.0/8 to any #loopback
block in quick on dc0 from 169.254.0.0/16 to any #DHCP auto-config
block in quick on dc0 from 192.0.2.0/24 to any #reserved for docs
block in quick on dc0 from 204.152.64.0/23 to any #Sun cluster interconnect
block in quick on dc0 from 224.0.0.0/3 to any #Class D &amp; E multicast

# Block fragments and too short tcp packets
block in quick on dc0 all with frags
block in quick on dc0 proto tcp all with short

# block source routed packets
block in quick on dc0 all with opt lsrr
block in quick on dc0 all with opt ssrr

# Block OS fingerprint attempts and log first occurrence
block in log first quick on dc0 proto tcp from any to any flags FUP

# Block anything with special options
block in quick on dc0 all with ipopts

# Block public pings and ident
block in quick on dc0 proto icmp all icmp-type 8
block in quick on dc0 proto tcp from any to any port = 113

# Block incoming Netbios services
block in log first quick on dc0 proto tcp/udp from any to any port = 137
block in log first quick on dc0 proto tcp/udp from any to any port = 138
block in log first quick on dc0 proto tcp/udp from any to any port = 139
block in log first quick on dc0 proto tcp/udp from any to any port = 81
Any time there are logged messages on a rule with the <literal>log first</literal> option, run <command>ipfstat -hio</command> to evaluate how many times the rule has been matched. A large number of matches may indicate that the system is under attack.
The rest of the rules in the inbound section define which connections are allowed to be initiated from the Internet. The last rule denies all connections which were not explicitly allowed by previous rules in this section.
# Allow traffic in from ISP's DHCP server. Replace z.z.z.z with
# the same IP address used in the outbound section.
pass in quick on dc0 proto udp from z.z.z.z to any port = 68 keep state

# Allow public connections to specified internal web server
pass in quick on dc0 proto tcp from any to x.x.x.x port = 80 flags S keep state

# Block and log only first occurrence of all remaining traffic.
block in log first quick on dc0 all
Configuring <acronym>NAT</acronym>
<primary>IP masquerading</primary> <see>NAT</see>
<primary>network address translation</primary> <see>NAT</see>
<primary><command>ipnat</command></primary>
To enable <acronym>NAT</acronym>, add these statements to <filename>/etc/rc.conf</filename> and specify the name of the file containing the <acronym>NAT</acronym> rules:
gateway_enable="YES"
ipnat_enable="YES"
ipnat_rules="/etc/ipnat.rules"
<acronym>NAT</acronym> rules are flexible and can accomplish many different things to fit the needs of both commercial and home users. The rule syntax presented here has been simplified to demonstrate common usage. For a complete rule syntax description, refer to <citerefentry><refentrytitle>ipnat</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
The basic syntax for a <acronym>NAT</acronym> rule is as follows, where <literal>map</literal> starts the rule and <replaceable>IF</replaceable> should be replaced with the name of the external interface:
map <replaceable>IF</replaceable> <replaceable>LAN_IP_RANGE</replaceable> -&gt; <replaceable>PUBLIC_ADDRESS</replaceable>
The <replaceable>LAN_IP_RANGE</replaceable> is the range of <acronym>IP</acronym> addresses used by internal clients. Usually, it is a private address range such as <systemitem class="ipaddress">192.168.1.0/24</systemitem>. The <replaceable>PUBLIC_ADDRESS</replaceable> can either be the static external <acronym>IP</acronym> address or the keyword <literal>0/32</literal> which represents the <acronym>IP</acronym> address assigned to <replaceable>IF</replaceable>.
In <application>IPF</application>, when a packet arrives at the firewall from the <acronym>LAN</acronym> with a public destination, it first passes through the outbound rules of the firewall ruleset. Then, the packet is passed to the <acronym>NAT</acronym> ruleset which is read from the top down, where the first matching rule wins. <application>IPF</application> tests each <acronym>NAT</acronym> rule against the packet's interface name and source <acronym>IP</acronym> address. When a packet's interface name matches a <acronym>NAT</acronym> rule, the packet's source <acronym>IP</acronym> address in the private <acronym>LAN</acronym> is checked to see if it falls within the <acronym>IP</acronym> address range specified in <replaceable>LAN_IP_RANGE</replaceable>. On a match, the packet has its source <acronym>IP</acronym> address rewritten with the public <acronym>IP</acronym> address specified by <replaceable>PUBLIC_ADDRESS</replaceable>. <application>IPF</application> posts an entry in its internal <acronym>NAT</acronym> table so that when the packet returns from the Internet, it can be mapped back to its original private <acronym>IP</acronym> address before being passed to the firewall rules for further processing.
For networks that have large numbers of internal systems or multiple subnets, the process of funneling every private <acronym>IP</acronym> address into a single public <acronym>IP</acronym> address becomes a resource problem. Two methods are available to relieve this issue.
The first method is to assign a range of ports to use as source ports. By adding the <literal>portmap</literal> keyword, <acronym>NAT</acronym> can be directed to only use source ports in the specified range:
map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp 20000:60000
Alternately, use the <literal>auto</literal> keyword which tells <acronym>NAT</acronym> to determine the ports that are available for use:
map dc0 192.168.1.0/24 -&gt; 0/32 portmap tcp/udp auto
The second method is to use a pool of public addresses. This is useful when there are too many <acronym>LAN</acronym> addresses to fit into a single public address and a block of public <acronym>IP</acronym> addresses is available. These public addresses can be used as a pool from which <acronym>NAT</acronym> selects an <acronym>IP</acronym> address as a packet's address is mapped on its way out.
The range of public <acronym>IP</acronym> addresses can be specified using a netmask or <acronym>CIDR</acronym> notation. These two rules are equivalent:
map dc0 192.168.1.0/24 -&gt; 204.134.75.0/255.255.255.0
map dc0 192.168.1.0/24 -&gt; 204.134.75.0/24
A common practice is to have a publically accessible web server or mail server segregated to an internal network segment. The traffic from these servers still has to undergo <acronym>NAT</acronym>, but port redirection is needed to direct inbound traffic to the correct server. For example, to map a web server using the internal address <systemitem class="ipaddress">10.0.10.25</systemitem> to its public <acronym>IP</acronym> address of <systemitem class="ipaddress">20.20.20.5</systemitem>, use this rule:
rdr dc0 20.20.20.5/32 port 80 -&gt; 10.0.10.25 port 80
If it is the only web server, this rule would also work as it redirects all external <acronym>HTTP</acronym> requests to <literal>10.0.10.25</literal>:
rdr dc0 0.0.0.0/0 port 80 -&gt; 10.0.10.25 port 80
<application>IPF</application> has a built in <acronym>FTP</acronym> proxy which can be used with <acronym>NAT</acronym>. It monitors all outbound traffic for active or passive <acronym>FTP</acronym> connection requests and dynamically creates temporary filter rules containing the port number used by the <acronym>FTP</acronym> data channel. This eliminates the need to open large ranges of high order ports for <acronym>FTP</acronym> connections.
In this example, the first rule calls the proxy for outbound <acronym>FTP</acronym> traffic from the internal <acronym>LAN</acronym>. The second rule passes the <acronym>FTP</acronym> traffic from the firewall to the Internet, and the third rule handles all non-<acronym>FTP</acronym> traffic from the internal <acronym>LAN</acronym>:
map dc0 10.0.10.0/29 -&gt; 0/32 proxy port 21 ftp/tcp
map dc0 0.0.0.0/0 -&gt; 0/32 proxy port 21 ftp/tcp
map dc0 10.0.10.0/29 -&gt; 0/32
The <acronym>FTP</acronym> <literal>map</literal> rules go before the <acronym>NAT</acronym> rule so that when a packet matches an <acronym>FTP</acronym> rule, the <acronym>FTP</acronym> proxy creates temporary filter rules to let the <acronym>FTP</acronym> session packets pass and undergo <acronym>NAT</acronym>. All LAN packets that are not <acronym>FTP</acronym> will not match the <acronym>FTP</acronym> rules but will undergo <acronym>NAT</acronym> if they match the third rule.

Loading…

No matching activity found.

Browse all component changes

Glossary

English Turkish (tr_TR)
multiple çoklu FreeBSD Doc
process işlem FreeBSD Doc

Source information

Source string comment
(itstool) path: sect2/para
Source string location
book.translate.xml:63257
String age
9 months ago
Source string age
a year ago
Translation file
books/tr_TR/handbook.po, string 10373