URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 65814
[ Назад ]

Исходное сообщение
"Помогите правильно настроить форвардинг"

Отправлено AlexGas , 20-Апр-06 19:08 
Есть одна машина которая работает гейтом в инет
На ней работает НАТ и Сквид.
Получил еще одно АДСЛ соединение к тому же провайдеру т.е. дефаулт роут у обоих соединений одинаковый что не дает поднять оба АДСЛ на одной машине
Собрал на четверке (486) еще один гейт в инет
естественно ни о каком сквиде на эту машину не идет речи только НАТ

Нужно весь НТТР трафик слать через вторую машину.
Надо понимать что надо форвардить пакеты с первой на вторую
вот это и не могу никак сделать т.к. на первой машине пакеты сначала форвардятся на сквид
а уже потом НАТятся... вот кусок файрвола на первой машине

fwcmd="/sbin/ipfw -q"
${fwcmd} add pass all from any to any via lo0
${fwcmd} add deny ip from 192.168.0.0/16 to any in via ${LanOut}
${fwcmd} add deny ip from 172.16.0.0/12 to any in via ${LanOut}
${fwcmd} add deny ip from 10.0.0.0/8 to any in via ${LanOut}
${fwcmd} add fwd 127.0.0.1,3128 tcp from ${NetInIP}/${NetInMask} to not 192.168.0.0/16 http,https via ${LanIn}
${fwcmd} add divert natd ip from ${NetInIP}/${NetInMask} to any out via ${LanOut}
${fwcmd} add divert natd ip from any to ${IPOut} in via ${LanOut}

сквид и должен работать на первой машине а вот от сквида пакеты должна передаться на вторую машину а со второй вернутся назад на первую и к клиенту по сети
Нат на второй машине поднял НАТ примерно тот же файрвол только нет форварда на сквид
Вообще подсеть которая ходит в инет 192.168.2.0..255

как правильно зафорвардить пакеты НТТР трафика на вторую машину после обработки в сквиде и правилно вернуть обратно?

Заранее спасибо


Содержание

Сообщения в этом обсуждении
"Помогите правильно настроить форвардинг"
Отправлено Sam , 20-Апр-06 21:24 
http://justhowto.info/home_open/document-432

6.  Transparent Proxy to a Remote Box

  Now, the question naturally arises, if we can do all this nifty stuff
  redirecting HTTP connections to local ports, could we do the same
  thing but to a  remote box (e.g., the machine with squid running is
  not the same machine as iptables is running on).  The answer is yes,
  but it takes a little different magic words. If you only want to
  redirect to the local box (the normal case), skip this section.

  For the purposes of example commands, let's assume we have two boxes
  called squid-box and iptables-box, and that they are on the network
  local-network.  In the commands below, replace these strings with the
  actual IP addresses or name of your machines and network.

  I will present two different approaches here.

  6.1.  First method (simpler, but does not work for some esoteric
  cases)


  First, we need to machine that squid will be running on, squid-box.
  You do not need iptables or any special kernel options on this
  machine, just squid.  You *will*, however, need the 'http_accel'
  options as described above.  (Previous version of this HOWTO suggested
  that you did not need those options.  That was a mistake. Sorry to
  have confused people...)

  Now, the machine that iptables will be running on, iptables-box You
  will need to configure the kernel as described in section 3 above,
  except that you don't need the REDIRECT target support).  Now, for the
  iptables commands. You need three:


  ·  iptables -t nat -A PREROUTING -i eth0 -s ! squid-box -p tcp --dport
     80 -j DNAT --to squid-box:3128

  ·  iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-
     box -j SNAT --to iptables-box

  ·  iptables -A FORWARD -s local-network -d squid-box -i eth0 -o eth0
     -p tcp --dport 3128 -j ACCEPT

  The first one sends the packets to squid-box from iptables-box.  The
  second makes sure that the reply gets sent back through iptables-box,
  instead of directly to the client (this is very important!).  The last
  one makes sure the iptables-box will forward the appropriate packets
  to squid-box. It may not be needed. YMMV.  Note that we specified '-i
  eth0' and then '-o eth0', which stands for input interface eth0 and
  output interface eth0.  If your packets are entering and leaving on
  different interfaces, you will need to adjust the commands
  accordingly.


  Add these commands to your appropriate startup scripts under
  /etc/rc.d/

  (Thanks to Giles Coochey for help writing this section).

  6.2.  Second method (more complicated, but more general)

  Our first shot at this works good, but there is a minor drawback in
  that HTTP/1.0 connections without the Host header do not get handled
  properly.  Connections that are fully or partially HTTP/1.1 compliant
  work fine.  As most modern web browsers send the Host header, this is
  not a problem for most people.  However, some small programs or
  embedded devices may send only very simple HTTP/1.0 requests.  If you
  want to support these, we'll need to do a little more work.  Namely,
  on iptables-box we'll need the following options enabled in the kernel
  in addition to what was specified above:


  ·  IP: advanced router

  ·  IP: policy routing

  ·  IP: use netfilter MARK value as routing key

  ·  IP: Netfilter Configuration ->  Packet mangling

  ·  IP: Netfilter Configuration ->  MARK target support

  You'll also need the iproute2 tools.  Your distribution probably
  already has them installed, but if not, look at
  ftp://ftp.inr.ac.ru/ip-routing/

  You'll want to use the following set of commands on iptables-box:

  ·  iptables -t mangle -A PREROUTING -j ACCEPT -p tcp --dport 80 -s
     squid-box

  ·  iptables -t mangle -A PREROUTING -j MARK --set-mark 3 -p tcp
     --dport 80

  ·  ip rule add fwmark 3 table 2

  ·  ip route add default via squid-box dev eth1 table 2

     Note that the choice of firewall mark (3) and routing table (2) was
     fairly arbitrary.  If you are already using policy routing or
     firewall marking for some other purpose, make sure you choose
     unique numbers here. Otherwise, don't worry about it.


  Next, squid-box.  Use this command, which should look remarkably
  similar to a command we've seen previously.

  ·  iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT
     --to-port 3128

     As before, add all of these commands to the appropriate startup
     scripts.

  Here is a brief explanation of how this works: in method one, we used
  Network Address Translation to get the packets to the other box.  The
  result of this is that the packet gets altered.  This alteration is
  what causes some kinds of clients mentioned above to fail. In method
  two, we use a magic thing called policy routing.  The first thing we
  do is to select the packets we want.  Thus, all packets on port 80,
  except those coming from squid-box itself, are MARKed.  Then, when the
  kernel goes to make a routing decision, the MARKed packets aren't
  routing using the normal routing table that you access with the
  ``route'' command but with a special table.  This special table has
  only one entry, a default gateway to squid-box.  Thus, the packet is
  sent merrily on it's way without every having been altered.  So, even
  HTTP/1.0 connections can be handled perfectly.  (Thanks to Michal
  Svoboda for suggesting and helping to write this section)

  6.3.  Method One: What if iptables-box is on a dynamic IP?

  If the iptables-box is on a dynamic IP address (e.g. a dialup PPP
  connection, or a DHCP assigned IP address from a cable modem, etc.),
  then you will want to make a slight change to the above commands.
  Replace the second command with this one:


  ·  iptables -t nat -A POSTROUTING -o eth0 -s local-network -d squid-
     box -j MASQUERADE

  This change avoids having to specify the IP address of iptables-box in
  the command.  Since it will change often, you'd have to change your
  commands to reflect it.  This will save you a lot of hassle.

  7.  Transparent Proxy With Bridging

  Warning, this is really esoteric stuff.  If you need it, you'll know.
  If not, skip this section.  Thanks to Lewis Shobbrook
  (lshobbrook@fasttrack.net.au) for contributing to this section.

  If you are trying to setup a transparent proxy on a Linux machine that
  has been configured as a bridge, you will need to add one additional
  iptables command to what we had in section 5.  Specifically, you need
  to explicitly allow connections to the machine on port 3128 (or any
  other port squid is listening on), otherwise the machine will just
  forward them over to the other interface like a good little bridge.
  Here's the magic words:

  ·  iptables -A INPUT -i interface -p tcp -d your_bridge_ip -s local-
     network --dport 3128 -m state --state NEW,ESTABLISHED -j ACCEPT

     Replacing interface with the interface that corresponds to
     your_bridge_ip (typically eth0 or eth1).  First time bridge users
     should also note that you'll probably want to repeat the same
     command with ``3128'' replaced by ``telnet'' if you want to
     administer your bridge remotely.


"Помогите правильно настроить форвардинг"
Отправлено AlexGas , 21-Апр-06 09:29 
>http://justhowto.info/home_open/document-432
>
>6.  Transparent Proxy to a Remote Box

Забыл написать (хотя по правилам файрвола видно и по теме тоже)
что работаем в FreeBSD 4.9

И второе мне не надо форвардить пакеты на вторую машину со сквидом.
Мне нужно чтоб запросы все принимала машина №1 с установленным сквидом
а вот после обработки сквидом пакеты форвардились на вторую машину и там обрабатывались НАТом .... вот