The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Port mapping и открытие портов наружу во FreeBSD 7.1 (ipfw + kernel nat)
Для начала надо пересобрать ядро со следующими опциями

   options         IPFIREWALL              #firewall
   options         IPFIREWALL_VERBOSE      #enable logging to syslogd(8)
   options         IPFIREWALL_DEFAULT_TO_ACCEPT    #allow everything by default
   options         IPDIVERT
   options         IPFIREWALL_FORWARD
   options         DUMMYNET
   options         IPFIREWALL_NAT          #ipfw kernel nat support
   options         LIBALIAS

Далее пересобираем ядро:

   cd /usr/src/
   make buildkernel KERNCONF=Yourkernel && make installkernel KERNCONF=Yourkernel 

   shutdown -r now

Далее кусок файла конфигурации с примером.
192.168.1.132 - ip адрес сетевой карты смотрящей наружу
останое внутренние адреса

   #!/bin/sh
   # здесь просто удаляю старые правила 
   ipfw -f flush
   ipfw nat 122 delete

   # разрещаю все через loopback
   ipfw add allow all from any to any via lo0

   # делаю нат на ip смотрящем наружу, same_ports - для попытки сохранить номера портов при нате
   ipfw nat 123 config ip 192.168.1.132 log same_ports \

   # пробрасываю все что приходит на порт 9999 на тот же порт внутренней машины 
   # как вариант можно указать -redirect_port tcp 192.168.4.86:9999 192.168.1.132:9999
    redirect_port tcp 192.168.4.86:9999 9999

   # этот кусок нужен что бы у машины был не полный нат а только порт который я разрешил, 
   # потому что вообще в интернет буду пускать через проксю.
   ipfw add 100 nat 123 tcp from 192.168.4.86 9999 to any
   ipfw add 100 nat 123 tcp from any to 192.168.4.86 9999

   # здесь я разрешаю клиенту с ip 192.168.4.86 коннектится к любым серверам по 25 порту, 
   # но только по нему.
   ipfw add 100 nat 123 tcp from 192.168.4.86 to any 25

   # это что бы был нат, иначе ничего не будет работать, правило для выпуска клиентов наружу
   ipfw add 100 nat 123 ip from any to 192.168.1.132


Основанно на http://www.opennet.me/tips/info/1618.shtml
 
10.02.2009 , Автор: reZon
Ключи: ipfw, freebsd, kernel, nat / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / NAT, трансляция адресов

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Умник (?), 10:21, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    PF проще!
     
  • 1.2, stasav (??), 10:35, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И быстрее ;)
     
     
  • 2.5, mc_ (?), 10:39, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Как производили замеры, насколько быстрее.
    Нигде не встречал упоминаний что nat на pf более быстрый чем в ipfw
     

  • 1.3, RapteR (ok), 10:38, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    http://www.opennet.me/openforum/vsluhforumID3/2106.html#14 еще проще.
     
  • 1.4, cvsup (ok), 10:39, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    непонятно, для кого предназначена эта статья с уже легендарными ошибками, кочующими от автора к автору; и чем это лучше оригинала в man ipfw(8)
     
  • 1.6, stasav (??), 10:57, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    2 mc_ Делал замеры в своё время.

    Насчет упоминаний - Посмотри как работает нат в ifpw и нат в pf, вопросы отпадут.

     
  • 1.7, grayich (ok), 11:12, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
       CFLAGS+= -DIPFIREWALL_NAT
    это нужно было только в глубокой бетте
     
  • 1.8, reZon (?), 11:49, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    И какие ошибки ну кроме CFLAGS+= -DIPFIREWALL_NAT?

    Как раз так все работает и сделанно по ману ipfw.

     
     
  • 2.9, grayich (ok), 12:17, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >ipfw nat 123 config ip 192.168.1.132 log same_ports \
    >
    ># пробрасываю все что приходит на порт 9999 на тот же порт внутренней машины
    ># как вариант можно указать -redirect_port tcp 192.168.4.86:9999 192.168.1.132:9999
    >redirect_port tcp 192.168.4.86:9999 9999

    помоему это дело не обработается верно, если есть возможность лучше присать в 1 строчку без переносов с помощью " \"  и уж темболее не вставляя комментариев после переноса

    и еще из примера можно исключить удаление nat 122 так как он не используется.

    з.ы.
    можно ли удалить все наты одной командой?

     
     
  • 3.11, reZon (?), 12:29, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Да и согласен с комментом после переноса конечно я лопухнулся =(

    А вообще написал все это по той причине что по этому делу много вопросов но нет практически никаких ответов...
    Поэтому курил часть мана ipfw по нат... очень долго... И решил что может это хоть кому-то облегчит жизнь... то это гуд.

     

  • 1.10, reZon (?), 12:24, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Удалить все наты одной командой нельзя, по крайней мере у меня не получилось.

    Отрабатывает все верно, с переносами легче просматривать если пробросок много.

    Комменты это я конечно погорячился, писал только для заметки их.

     
  • 1.12, stasav (??), 13:18, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ipfw nat flush
     
     
  • 2.13, grayich (ok), 13:26, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    сами то пробовали? =)

     
  • 2.14, reZon (?), 13:39, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >ipfw nat flush

    Неа, не работает.

     
     
  • 3.15, grayich (ok), 13:56, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >>ipfw nat flush
    >
    >Неа, не работает.

    вообщето работает и очень хорошо работает, особенно для тех кто удаленно сидит... сносит все правила, тоже что и ipfw flush

     
     
  • 4.16, reZon (?), 14:01, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Ню =) Я же имел ввиду что для ната не работает =)
    Все правила ната на месте =)
     

  • 1.17, stasav (??), 16:32, 10/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ipfw default_to_accept и никаких проблем.
     
     
  • 2.18, reZon (?), 16:34, 10/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >ipfw default_to_accept и никаких проблем.

    А теперь поясни пожалуйста свою мысль...

     

  • 1.19, stasav (??), 05:52, 11/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ipfw default_to_accept, опция ядра. Смотри man или в examples, как это работает.
     
  • 1.20, stasav (??), 05:54, 11/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    #options        IPFIREWALL_DEFAULT_TO_ACCEPT
    К предъидущему сообщению =)
     
     
  • 2.22, reZon (?), 11:03, 11/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    Я просил пояснить каких таких проблем не будет?

    Мне не нужно все разрешать всё, последнее правило у меня всегда deny from any to any.

    Отрытый файрвол не лишает необходимости прописывать то что я написал в заметке.

     

  • 1.21, BoOgatti (?), 09:58, 11/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Зачем для кернель ната опция ipdivert? Зачем флаг в мэйк.конфе?

    По поводу удаления всех правил ната: такой команды я не нашёл (ipfw nat del all и прочие похожие комбинации не канают =/ )

    Пробовал юзать кернель нат, однако столкнулся с рядом проблем (сейчас уже не помню каких) и в итоге вернулся к натд. Для шлюза не обслуживающего несколько тыщ клинтосов его хватает за глаза и за уши.

     
  • 1.23, Гзкр (?), 14:03, 11/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ядро можно не пересобирать
    kldload ipfw
    kldload ipfw_nat
    kldload ipdivert
     
     
  • 2.25, reZon (?), 15:05, 11/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >ядро можно не пересобирать
    >kldload ipfw
    >kldload ipfw_nat
    >kldload ipdivert

    Замечательно! Конечно можно ничего не пересобирать, только вот надежнее все же вкомпилить в ядро и быстрее...
    Кроме того пересборка ядра замечательная возможность избавится от всего лишнего....

     
     
  • 3.26, Добрый Дохтур (?), 15:42, 11/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >только вот надежнее все же вкомпилить в ядро и быстрее...

    1)и как это связано с надежностью?
    2)не быстрее.

     

  • 1.24, anon (?), 14:41, 11/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    свои 20 копеек внесу
    make kernel KERNCONF=Yourkernel
    так было бы проще :)
     
  • 1.27, Стас (??), 17:35, 11/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    легче  rinetd  использовать
     
     
  • 2.28, vec135 (??), 05:45, 12/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >легче  rinetd  использовать

    +1

     
  • 2.29, grayich (ok), 12:12, 12/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    >легче  rinetd  использовать

    какой смысл усложнять систему, если НАТ всеравно используется..  Другое дело если НАТ нет.

     

  • 1.30, doorsfan (?), 12:28, 12/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а как организовать доступ внутренних клиентов к внешний_ИП:проброшенный_порт, например, проброшен 80й порт на хостерную машину, пользователь набирает http://firm.domain и открывает сайт фирмы. Я кроме решения в виде фейковой зоны для локальных пользователей ничего не придумал
     
     
  • 2.31, Alexander Yakimenko (?), 23:42, 13/02/2009 [^] [^^] [^^^] [ответить]  
  • +/
    ipfw fwd - и будет тебе счастье. Можно прозрачный прокси и редиректор (squid+squidGuard).
     

  • 1.32, stasav (??), 11:53, 14/02/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ребята уже и забыли что статья про портмаппинг а не nat для чайникофф =)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру