Ключевые слова:nat, freebsd, redirect, (найти похожие документы)
From: Ruslan Ermilov <[email protected]>
Subject: [FreeBSD] переброс соединения для обработки во внутреннюю сеть NAT
On Sat, Jul 17, 1999 at 08:03:32AM -0400, Tim Walker wrote:
> I am running FreeBSD as my network's gateway to the Internet and am
> trying to pass Web traffic through to a server on my internal network
> (FreeBSD machine has a routable IP address and the internal web server
> has a non-routable address).
>
> It is working fine from the outside world, but from machines on my
> internal network they always end up on the FreeBSD webserver.
>
> In the natd.conf file I have:
>
> use_sockets yes
> same_ports yes
> interface ed1
> redirect_port tcp 192.168.1.2:80 80
> redirect_port tcp 192.168.1.2:21 21
> redirect_port tcp 192.168.1.2:20 20
>
Looks good.
>
> and in the rc.firewalls file I have:
>
> ipfw add 10 divert natd tcp from 192.168.1.2 80 to any
> ipfw add 11 divert natd tcp from any to 192.168.1.2 80
> ipfw add 12 divert natd tcp from any to 192.168.1.100 80
>
> (192.168.1.2 is the webserver, and 192.168.1.100 is the inside interface of
> the FreeBSD machine).
>
> Does anyone have any suggestions?
>
The following should do the trick:
ipfw add 10 divert natd tcp from any 80 to any
ipfw add 11 divert natd tcp from any to any 80
See the attached message for a more detailed explanation.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA of the
[email protected] United Commercial Bank,
[email protected] FreeBSD committer,
+380.652.247.647 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
From: Ruslan Ermilov
To: Ludwig Pummer
> >> Modified files:
> >> sbin/natd natd.8
> >> Log:
> >> Mention that data going from one internal address to another will
> >> not be processed by natd.
> >> Requested by: Ludwig Pummer
>
> I don't think that's how I worded it...
>
> >> Revision Changes Path
> >> 1.19 +11 -4 src/sbin/natd/natd.8
> >>
> >
> >The text of this change was:
> >} It should be noted that only incoming packets are affected.
> >} ^^^^^^^^
> >} Data going from one internal network to another will not be
> >} ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >} processed by natd.
>
> This also isn't quite what I meant...
>
> >I don't understand. Look at my example:
> >
> ># ipfw add 1 divert 6666 tcp from 192.168.1.1 1234 to any
> ># nc -s 192.168.1.1 -p 1234 192.168.1.2 5678
> ># natd -v -p 6666 -a 1.2.3.4 -redirect_port tcp 192.168.1.1:1234 2345
> >Out [TCP] [TCP] 192.168.1.1:1234 -> 192.168.1.2:5678 aliased to
> > [TCP] 1.2.3.4:1234 -> 192.168.1.2:5678
> >
> >It is outgoing packet following from one internal host to another,
> >and it _is_ affected. What did you mean?
>
> I'm not understanding the example very well (what's 'nc' and what is it doing?)
>
/usr/ports/net/netcat - simple utility which reads and writes data across
network connections, very handy.
> Let me restate what I originally said/meant to say:
> I have a machine doing natd. It has an internal network address
> 172.16.1.5/24 and an external network address of 24.2.21.36/24. If I do
> 'redirect_port tcp 172.16.1.30:80 80' and then try to point my web browser
> (from a machine in the 172.16.1.5/24 network) at http://24.2.21.36:80, it
> will not reach 172.16.1.30:80. If, however, I point my web browser (from a
> machine on the internet) at http://24.2.21.36:80, it _will_ reach
> 172.16.1.30:80.
>
Ah, I see now what did you mean, but you're wrong anyway.
It works(!) even in such configuration, look what I did:
Host running natd:
(internal interface 192.168.1.1/24)
fxp0: flags=8843 mtu 1500
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
ether 00:a0:c9:55:13:22
media: autoselect (10baseT/UTP) status: active
supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP
(external interface 212.110.138.1/28)
fxp2: flags=8843 mtu 1500
inet 212.110.138.1 netmask 0xfffffff0 broadcast 212.110.138.15
ether 00:a0:c9:5a:51:f9
media: manual
supported media: manual
# ipfw list 1
00001 divert 6666 tcp from any to any 80
00001 divert 6666 tcp from any 80 to any
** Note that there are no "via" keywords, otherwise it will not work.
# natd -v -p 6666 -n fxp2 -u -redirect_port tcp 192.168.1.13:80 80
(telnet from 192.168.1.3 to 212.110.138.1:80)
In [TCP] [TCP] 192.168.1.3:4138 -> 212.110.138.1:80 aliased to
[TCP] 192.168.1.3:4138 -> 192.168.1.13:80
Out [TCP] [TCP] 192.168.1.3:4138 -> 192.168.1.13:80 aliased to
[TCP] 212.110.138.1:4138 -> 192.168.1.13:80
(reply from 192.168.1.13:80)
In [TCP] [TCP] 192.168.1.13:80 -> 212.110.138.1:4138 aliased to
[TCP] 192.168.1.13:80 -> 192.168.1.3:4138
Out [TCP] [TCP] 192.168.1.13:80 -> 192.168.1.3:4138 aliased to
[TCP] 212.110.138.1:80 -> 192.168.1.3:4138
(telnet from 212.110.138.4 to 212.110.138.1:80)
In [TCP] [TCP] 212.110.138.4:49247 -> 212.110.138.1:80 aliased to
[TCP] 212.110.138.4:49247 -> 192.168.1.13:80
Out [TCP] [TCP] 212.110.138.4:49247 -> 192.168.1.13:80 aliased to
[TCP] 212.110.138.4:49247 -> 192.168.1.13:80
(reply from 192.168.1.13:80)
In [TCP] [TCP] 192.168.1.13:80 -> 212.110.138.4:49247 aliased to
[TCP] 192.168.1.13:80 -> 212.110.138.4:49247
Out [TCP] [TCP] 192.168.1.13:80 -> 212.110.138.4:49247 aliased to
[TCP] 212.110.138.1:80 -> 212.110.138.4:49247
> I felt that despite this being logical according to routing and the way the
> ipfw rule is written**, this was worth pointing out. Otherwise, many
> newbies setting up natd for the first time would do something very similar
> to my example above, and become disappointed/discouraged/confused when they
> can't connect to http://24.2.21.36:80 from their inside machine. I came to
> this conclusion after helping someone with natd over ICQ, and then
> recalling that I had similar problems when I was first playing with natd.
>
I hope you're ready to do it now!
> ** This is my thinking: Packets addressed to 24.2.21.36:80 from an inside
> machine are not actually sent out via the external network interface and
> then back, because the address is recognized as belonging to the computer
> running natd. Instead, the packets are just routed over the loopback
> network interface. Because the packets are never sent in and out via the
> interface listed in the ipfw rule, they are never sent through natd and
> therefore are not redirected to 172.16.1.30:80.
>
No, you misunderstood the concept. It is very simple, in fact:
There are two kinds of packets, "incoming" and "outgoing".
Outgoing packets are "aliased", i.e. their source IP address is replaced
by the "aliasing" address.
And vice versa, incoming packets are "de-aliased", i.e. their destination
IP address (which is equal to one of the "aliasing" addresses, yes, there
can be more than one) is looked for in the internal natd's mapping table,
which is created "on the fly" and by "redirect" rules.
Whether the packet is considered an "incoming" or "outgoing", depends on
how the natd has been run.
If run with ``-p port'', then the rules described in divert(4) take place.
You can override this by running natd with "-i inport" and "-o outport".
This will instruct natd to treat all packets from "inport" as being
"incoming", and permorm "de-aliasing" for them, and all packets from
"outport" as "outgoing", and perform "aliasing" for them.
It gives you more flexibility, but unneeded in most cases.
Another option that changes this behaviour is "-reverse" option.
One important thing that should be taken into the account is the ipfw's
configuration. You should make sure to configure it properly, I think
you understood this from my example.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA of the
[email protected] United Commercial Bank,
[email protected] FreeBSD committer,
+380.652.247.647 Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
