FreeBSD router kernel NAT ipfw GRE vpn server ok working

добавлено l2tp psk — еще чуть побыстрее работает  12-2017

связанная статья http://santosha.pro/wordpress/tunnel-vpn-site-to-site-link/

еще pfsense

ipfw freebsd #FreeBSD настройка примеры Unix Linux развести интернет по всем компьютерам и связать магазин склад и офис !
пример рабочего конфига для маршрутизатора роутера на FreeBSD для выхода в Интернет в малом офисе а также соединения с точкой продаж магазином где 3 терминала в сети и сервер

(напоминаю что если сервер настраивается удаленный то убедитесь что скрипт ipfw правильный и выполнится без ошибок иначе на сервер больше не соединитесь никак — firewall заблокирует всю сеть вообще — после его загрузки или команды flush включается только последнее по списку правило 65535 запрещающее прохождение всех пакетов по сети. И что загрузка системы дойдет до rc.local без вопросов перед этими изменениями например не монтируются недоступные диски или сетевые накопители через etc fstab ).

 

server vpn with two connections — merge two LAN’s inbound port 1723 addr 192.168.3.2 outbound from 192.168.3.2 to 1723 port (2-nd LAN server at remote shop), GRE (encapsulated into IP) pass
to/from igb1 — internet interface.
(vpn PPTP site-to-site connect), port 4899 remote control Radmin for Windows — redirect to 4900 because many connections from Hacker.
handbook not ignore

а так более правильно бо сервер выделяет протокол gre 47 из ip и его пакеты подсчитываются (в примере выше нули)

вот вся отладка (правило 105 убрать — пакеты gre не проходят куда нужно — достаточно 100 правила — т.к. пакет GRE
находится внутри TCP -но ipfw умеет их различать и считает если выводить ipfw show)
правило 600 нужно — иначе входящий трафик на 1723 проходит но не получает ответ! но его надо уточнять!
как — пробую сейчас.

# читаем внимательно — как получается электронщики продавали схемы и платы да у нас на рынке который потом в Митино переехал — парочку дорожек замкнуто на питание и землю а в описании надо убрать 2 перемычки и одну добавить и тогда работает!

 

 





  • на 2012 сервере если он не раздает интернет — убрать из nat все интерфейсы кроме внутреннего.. а то может не пустить никого по сети 50 на 50! (bfe не настраивается и рубит все входящие соединения)
  • 2012 2012R2 server — use as VPN, not Intermet router — Nat interface only Internal ! remove all LAN from NAT section (NAT combine with Firewall — may random block any network traffic)

 

исправлено в декабре 2017

небольшой тест занявший 3 часа (много букав).

вообще у этой конфигурации есть исходник т. е. откуда она взятаforums.freebsd.org/threads/34520/
FreeBSD Donate to FreeBSD
Home
About
Get FreeBSD
Documentation
Community
Developers
Support
FoundationForums > Server and Networking > Firewalls Significant network latency when using ipfw and in-kernel NAT

>

Discussion in ‘Firewalls‘ started by dreijer, Sep 13, 2012.

dreijer

dreijer New Member

3

Hi there,

We’re running FreeBSD 9.0-RELEASE on a box whose primary purpose is to act as a firewall and a gateway. Up until today, we’ve been using ipfw(4) in conjunction with natd(8) and the divert action in ipfw(4) to forward packets between the FreeBSD box (i.e. the public Internet) and our private servers.

Unfortunately, natd(8) appears to be quite the CPU hog and we therefore decided to switch to the in-kernel NAT support in ipfw(4). The issue we’re running in to is that the network latency appears to be skyrocketing when ipfw(4) contains nat rules. Basically all TCP traffic
originating from the box times out and pinging google.com on the box gives an average of ~10 SECONDS — and that’s even if I explicitly allow all ICMP traffic before the packets even get to the nat rules in ipfw.

The really odd part, however, is that I can ping the FreeBSD box just fine externally. For instance, pinging the server from my home connection gives an average of 45 ms. I’m also able to communicate just fine with the internal servers through the FreeBSD box.

Does anybody have any idea what’s going on? I assume I must’ve misconfigured something big here…

dreijer, Sep 13, 2012
#

AnonymousAnonymous Guest

I have a working setup with ipfw(8)() and in-kernel NAT on FreeBSD 8.3. I do not see the described latency, and pinging google.com from the NAT machine gives almost the same round-trip time as from a client behind the NAT. Actually, the ping from the client expectedly takes a little bit longer.

You might want to post your NAT and IPFW rules.

I hope that it is not an 9.0 issue, since I am going to upgrade my server soon.

 

dreijer New Member

Messages:
3
Thanks Received:
0

Definitely. Since this is a server in production, I’ve obfuscated some of the IPs, etc.

First off, here’s the ifconfig. Our setup consists of a private (ix0) and a public nic (ix1) and an ip tunnel (gif0), which is what we use in ipfw to forward incoming packets to our internal boxes:

Code:

The basic ruleset looks like this. One-pass is off so that packets are reinjected after going through NAT’ing and pipes:

Code:

‘ipfw nat show config’ yields:

Code:

And finally, here are the horrifying ping times (furthermore, all outgoing TCP traffic originating from this box, such as wget or pkg_add, time out. I’ve managed to get an outgoing telnet working, but it’s horrible slow and takes a while to establish):

Code:

It’s worth mentioning that when I switch back to using natd and divert in the ruleset (which really only changes the nat portions and everything else stays the same), the ping time drops to ~300ms, which is a big difference for simply «using» natd even when the ICMP packets aren’t supposed to be going through NAT’ing whatsoever. The ~300ms ping time is still way too high, though, since our other boxes have a ping time to Google of ~0.300ms…

Any ideas?

 Soren

 
Anonymous

Anonymous Guest

It looks to me as if TSO is enabled on your adapter ix0.The manual of ipfw(8)() states in the section BUGS: 

 

 

Some observations about the firewall rules:

Your ipfw rule 0003 refers to gif1, however, gif1 is not present in your ifconfig(8)() listing. You mentioned explicitly gif0 in your message, and you might want to check your actual rule set.

Also in my case, the check-state rule does always show package/byte counts of zero. So, I assume this is normal.

In my opinion, your rule 200 should become a lower index and go before rule 100, and I would append setup keep-state to it, so most probably rule 201 could be omitted.

I don’t think that rule 100 can be for testing only. In my setup a similar rule lets all the clients connecting to the internet, and with out that, my clients would be effectively offline. In this respect, I am missing a corresponding udp rule. On the other hand, I do have nothing like your icmp rule 110, and pinging from behind the NAT does work anyway.

 
 

dreijer New Member

Messages:
3
Thanks Received:
0

Yeah, I already got rid of that, which fixed some intermittent TCP connection issues I had when routing traffic through the FreeBSD box to our internal boxes. It had no effect whatsoever on the ping times or TCP traffic originating from the FreeBSD box itself.

That’s because I obfuscated the ruleset and removed rules that weren’t relevant to illustrate the setup. The tunnels are very much working, so ignore any typos like that. :)

I’ve explicitly avoided using dynamic rules for the allowed incoming traffic because I don’t want DDoS attacks (which we’ve been hit by recently) to take up gobs of system memory.

Sure, it’s «necessary», but I could lock it down even more and only allow certain protocols, like pkg_add, ssh, etc.

 
Anonymous

Anonymous Guest

Perhaps, I cannot be of more help here than posting a working ruleset, which is structurally similar to yours, but of course must be somehow different. By replacing the 1723 redirection by a 443 one, and by removing the L2TP/IPsec stuff, this would almost match your setup.bridge0 is my internal and ue0 my external interface. 

 

 

Code:

One final observation, your rule 400 corresponds more AND less to my rules 9998/9999. Your rule takes LESS space, but is MORE restrictive, and I am not sure whether your rule 110 which takes care only for the out direction would fix this.

 
 

 

теперь результат проверки  —

несколько картинок

 

 

пинги с 2-х сторон только без флуда — поставить если винда -w 500 -s 15

это нужно чтобы соединения не сбрасывались по неактивности — если правильно прописаны маршруты то соединения сами устанавливаются.

.. я показываю только инструмент — вот топор им надо рубить дрова или строить дом, а не вскрывать дверь соседу.

 

можно не настраивать на виндоуз сервер если он не нужен еще для чего — например склад на mssql .
диски можно расшарить с помощью Samba а MPD ище добавлю и Racoon ipsec router — ipsec tools
весь маршрутизатор можно сделать на FreeBSD и оно надежнее — мыши с видюхами не дохнут.

что то сломалось и больше не работает ? читать только заново а может что и поменялось еще

исправлено 1 сентября 2017
Фряха 11 stable ядро на роутере собирал но из за oss virtualbox а для роутера не нужно пересобирать. kldload ipfw ipfw_nat libalias а divert не надо.
Винда 2012R2 и 2016 сборка сервера и с обновлениями и без работает.
Работает как на картинках L2TP PPTP в любой комбинации, с сертификатами не настраивал — там надо dns полные доменные имена прописать хотя бы фирма.локалка англ буквами, перевыпустить сертификаты самоподписаные, или проверить что они есть, нажав в роутере посмотреть кнопку, для iis и для router должен быть тот же сертификат, если сделать второй то служба не запустится, имена компов должны полностью совпадать и зона dns тоже (а вообще советуют AD поднимать только этого нехватало server essential ). Подключившись по полному имени через mstsc (а dns в свойствах соединения на первом месте и вообще есть? а провайдерские в него как дополнительные прописаны recursive + root hint? ) надо установить сертификат второго компа в доверенные корневые центры сертификации на локальном компьютере и еще в доверенные издатели, имя dns совпадает,не сбилось? Вообще то это описание подмены dns а надо только чтобы имена совпадали, если у компьютеров постоянный адрес в Интернете то поможет например dyndns.dk или afraid.org если внешний но меняется то no-ip.com а вот во внутреннюю сеть снаружи не подключиться.    И еще галочка что проверять назначение сертификата, если он выпущен не для домена то будет ругань. А выше написано как сделать без этих заморочек.

.. добавил сертификаты где надо от certbot.eff.org/

 

FreeBSD  server desktop + wine + internet workstation virus free _ bitminer Cryptonight virtualbox + windows + Linux ubuntu — one Xeon processor » 29xx 48 284G 700ssd _2x3TB hdd»  .

добавил еще пример конфигурации (найдено..) а на 13 версии FreeBSD что то уточнять надо — поменялось.

[bash]роутер на фряхе Recent EntriesArchiveFriendsProfileMemories Взгляд из гнезда Previous Entry | Next Entry FreeBSD, ipfw nat и несколько провайдеров Aug. 5th, 2011 at 4:29 PM Несколько разных вариантов организации NAT в случае с несколькими провайдерами. Disclaimer: Автор не несет ответственности за результаты, возникшие в результате осмысления/применения текст данного поста. Приведенные ниже конфигурации не являются полными (не рассмотрены, например ситуации с DNS в случае нескольких провайдеров, варианты с несколькими fib'ами и аспекты переключения). Фактически, данный пост рассказывает о возможностях применения свежепоявившегося '''nat global'''. Это ограничивает область применения данных конфигураций более-менее свежим 8.2-STABLE и -CURRENT. Портировать на более старые версии не так сложно, при желании можно озвучить запрос в комментах. Варианты, от простого к сложному: Задача: есть 2 провайдера, надо организовать какое-то резервирование и немножко балансировки. Самое простое: N натов в N разных провайдеров, табличка в ipfw с сетями и номерами натов. Просто, понятно. Позволяет делать схемы с резервированием и ограниченной балансировкой Примерная реализация: ipfw nat 1 config ip ${isp1_addr} # ISP 1 ipfw nat 2 config ip ${isp2_addr} # ISP 2 # Табличка с соответствиями префиксов внутри сети с номерами натов ipfw table 1 add 172.16.1.7 1 ipfw table 1 add 172.16.1.0/24 2 # Транслируем пакетики, летящие наружу ipfw nat tablearg from 'table(1)' to not me out # Направляем отттранслированные пакеты нужному провайдеру ipfw fwd ${isp1_gw} ip4 from ${isp1_addr} to any out ipfw fwd ${isp2_gw} ip4 from ${isp2_addr} to any out # Транслируем пакеты, летящие на наши внешние адреса ipfw nat 1 from any to me recv ${isp1_iface} in ipfw nat 2 from any to me recv ${isp2_iface} in Работа ipfw fwd после применения ipfw nat требует выключения net.inet.ip.fw.one_pass для того, чтобы пакеты после трансляции попали обратно в ipfw Далеее - скриптуем доступность того или иного канала и в зависимости от этого переписываем дефолт/сети в табличке В случае, если к задаче добавляется необходимость организации проброса портов на внутренние сервисы, причем требуется доступность внутреннего сервиса со всех N (или хотя бы > 1) провайдеров, схема выше перестанет работать. Для решения необходимо либо ставить userland'ный редиректор (заплатив потерей исходных IP-адресов в логах и усложением администрирования), либо усложнять схему. Для этого потребуется Небольшой экскурс в особенности работы nat'а в ipfw В ipfw nat и ng_nat использует библиотека libalias(3). Она позволяет создать сколько угодно различных сущностей ната (пока хватает памяти, разумеется) с различными конфигурациями. Сам процесс конфигурации не представляет особого интереса, поэтому его можно опустить. Более интересно посмотреть на собственно трансляцию данных в пакетах: Сконфигуренному экземпляру ната необходимо передавать трафик посредством 2х функций: * LibAliasIn (как правило, трафик из мира на внешний адрес) * LibAliasOut (как правило, трафик от внутренних клиентов, которых нужно транслировать). Определение, какую из функций вызвать при получении пакета, ложится на пользователя libalias(3) (то есть, собственно ipfw_nat.c и ng_nat.c). ipfw nat эту задачу решает очень просто: если у пакета уже есть исходящий интерфейс (т.е. мы позваны на pfil-хуке out и выполнен routing lookup), то трафик передается LibAliasOut. В противном случае - LibAliasIn. Для пользователя системы это значит, что: * ipfw nat X ... out будет транслировать src ip-адреса/прочие атрибуты протокола в сконфигурированный IP-адрес инстанса * ipfw nat X ... in будет транслировать dst ip-адреса/прочие атрибуты протокола в внутренний адрес (взятый из таблицы стейтов) В случае выставленного в инстансе флага reverse все происходит с точностью до наоборот * Для "хитрых" конфигураций (например, сочетание reverse и обычного ната) натить на адресах интерфейсов не получится, посколько .. out хук в каком-то из случаев не будет вызываться, т.к. пакет предназначен локальной системе Есть еще один нюанс, который нам понадобится. Указанные выше функции сначала пытаются найти существующий стейт в своих таблицах. В случае, если стейт не найден функции могут его либо создать (новое TCP-соединение наружу, новая попытка соединения на адрес redirect_port), либо проигнорировать (вернуть) пакет. Поведение зависит от переданного параметра create. По умолчанию (ipfw nat, ng_nat без дополнительных опций) - соединение разрешают, то есть создают стейт. Начиная с недавнего времени в ipfw nat появилась опция global (аналог natd globalport), которая перебирает все сконфигурированные инстансы ipfw nat, вызывая LibAliasIn/LibAliasOut с параметром create, равным 0. Таким образом, только если в одном из натов найдется стейт (т.е. пакет принадлежит какой-то существующей сессии) он оттранслируется. Таким образом, конфигурация с учетом новых требований может выглядеть примерно так: ipfw nat 1 config ip ${isp1_addr} # ISP 1 ipfw nat 2 config ip ${isp2_addr} # ISP 2 ipfw nat 10 redirect_port tcp 172.16.1.2:25 ${isp1_addr}:25 redirect_port tcp 172.16.1.2:25 ${isp2_addr}:25 # Табличка с соответствиями префиксов внутри сети с номерами натов ipfw table 1 add 172.16.1.7 1 ipfw table 1 add 172.16.1.0/24 2 ... # Делим для упрощения IN и OUT ipfw skipto 5000 from any to any out # Отдаем пакет на пробу нату-редиректору. если пакет не попадает ни на один проброс - # нат не будет его никуда транслировать ipfw nat 10 ip4 from any to me recv ${isp1_iface} ipfw nat 10 ip4 from any to me recv ${isp2_iface} # Отдаем пакет per-провайдер натам. Если провайдеров сильно больше двух # или же есть много внешних адресов, в которые нужно натить - # имеет смысл переписать на tag X, tagged X для интерфейсов и tablearg для каждого адреса ipfw nat 1 ip4 from any to me recv ${isp1_iface} ipfw nat 2 ip4 from any to me recv ${isp2_iface} ... (5000) # Направляем в нужный нат существующие трансляции. У оттранслированных пакетов меняется # src-адрес и в правила дальше они не попадают ipfw nat global ip4 from ${localnet} to not me # Транслируем пакетики, летящие наружу. Поскольку теперь есть global, то возможности балансировки # значительно расширились: можно балансировать по протоколам/портам, probability и прочему. # То есть, фактически, легко можно сделать per-session load balancing ipfw nat tablearg from 'table(1)' to not me # Направляем отттранслированные пакеты нужному провайдеру ipfw fwd ${isp1_gw} ip4 from ${isp1_addr} to any ipfw fwd ${isp2_gw} ip4 from ${isp2_addr} to any Следующая задача, которая в общем-то была бы сферической в вакууме, если бы не суровая чугунная реальность: Требуется обеспечить работоспособность этих редиректов внутри локальной сети. Проблема тут в следующем: Пусть есть адрес 172.16.1.42, который через 1.2.3.4:25 должен попадать на 172.16.1.2:25. Шаг 1 (TCP SYN от .42 прилетает на шлюз) 172.16.1.42:33456 -> 1.2.3.4:25 Шаг 2 (транслируем через 10й инстанс в redirect_port на input) 172.16.1.42:33456 -> 172.16.1.2:25 Шаг 3 (пакет далее не транслируется и убегает в локальную сеть искать 172.16.1.2) Шаг 4 (172.16.1.2 получает SYN-пакет, отвечает SYN+ACK на 172.16.1.42:33456.) 172.16.1.2:25 > 172.16.1.42:33456 Шаг 5 (172.16.1.42 отвечает RST, поскольку подобного соединения в TCP-стеке найти не может (src-адрес с т.з. 42 должен быть 1.2.3.4)) Таким образом, надо менять еще и адрес источника, то есть вводить еще один nat. То есть: перед редиректом сначала меняем адрес источника, затем отдаем пакет в нат с редиректами. Ответные пакеты разворачиваем наоборот. Из-за нюансов, описанных выше, для ната нам нужен будет еще 1 адрес, не висящий непосредственно на интерфейсе. Выбирать в общем-то можно любой приватный, не использующийся в сети (т.е. тот, трафик на который пойдет через наш маршрутизатор с натами). "Не висящий непосредственно на интерфейсе" нужно для корректной работы out-хука в ipfw nat (описано выше). Реализуется оно например через blackhole маршрут (аналог типичного приема с ''ip route 1.2.3.0/24 null0'' в quagga, когда нужно натить много разных клиентов в пул публичных адресов). Примерно так: route add 10.10.10.10 -blackhole -iface lo0 Рисуем, как оно должно выглядеть: # В квадратных скобочках - в каком хуке ipfw мы получаем соответствующий пакет # TCP SYN [IN] 172.16.1.42:33456 -> 1.2.3.4:25 # ipfw nat в позе reverse (то есть, натим пакет в внешний адрес, out hook) [IN] 10.10.10.10:54123 -> 1.2.3.4:25 # наш нат с пробросом портов (in hook) [IN] 10.10.10.10:54123 -> 172.16.1.2:25 Ответ: # TCP SYN+ACK [IN] 172.16.1.2:25 -> 10.10.10.10:54123 # Отдаем пакет нату с пробросом (put hook) [OUT] 1.2.3.4:25 -> 10.10.10.10:54123 # Отдаем пакет reverse nat'у (in hook) [OUT] 1.2.3.4:25 -> 172.16.1.42:33456 Смотрим теперь как это выглядит в правилах: ipfw nat 1 config ip ${isp1_addr} # ISP 1 ipfw nat 2 config ip 2.3.4.5 # ISP 2 ipfw nat 10 redirect_port tcp 172.16.1.2:25 ${isp1_addr}:25 redirect_port tcp 172.16.1.2:25 ${isp2_addr}:25 # skip_global позволяет избежать неприятных нюансов с nat global (global не проверяет этот инстанс), который вызывается раньше ipfw nat 11 config ip 10.10.10.10 reverse skip_global ipfw table 1 add 172.16.1.7 1 # Табличка с соответствиями префиксов внутри сети с номерами натов ipfw table 1 add 172.16.1.0/24 2 ... ipfw skipto 5000 from any to any out # Делим для упрощения IN и OUT # В данный нат нужно направлять только тот трафик, который относится к редиректам # Можно сделать это например, так: ipfw allow ip4 from ${localnet} to ${localnet} recv ${int_iface} ipfw nat 11 ip4 from ${localnet} to me recv ${int_iface} ipfw nat 10 ip4 from any to me recv ${isp1_iface} ipfw nat 10 ip4 from any to me recv ${isp2_iface} ipfw nat 1 ip4 from any to me recv ${isp1_iface} ipfw nat 2 ip4 from any to me recv ${isp2_iface} # Отправляем пакеты на наш виртуальный адрес порт редиректору ipfw nat 10 ip4 from ${localnet} to 10.10.10.10 recv ${int_iface} # Направляем их же дальше 2му нату ipfw nat 11 ip4 from any to 10.10.10.10 recv ${int_iface} ... (5000) # Направляем в нужный нат существующие трансляции. У оттранслированных пакетов меняется # src-адрес и в правила дальше они не попадают ipfw nat global ip4 from ${localnet} to not me ipfw nat tablearg from ${localnet} to not me # Направляем отттранслированные пакеты нужному провайдеру ipfw fwd ${isp1_gw} ip4 from ${isp1_addr} to any ipfw fwd ${isp2_gw} ip4 from ${isp2_addr} to any Немного о внутренностях libalias, для интересующихся: Многократно упоминаемый выше стейт (link в терминах libalias) состоит из: * src ip (внутренний ip-адрес) * dst ip (адрес из "мира") * alias ip (внешний ip-адрес, в который мы натим) * proxy ip (нынче не используется) * src port * dst port * alias port * proxy port * link type (протокол (TCP, UDP, ICMP, ...)) Некоторые поля в стейтах могут быть "масками" (wildcards). Так работает, например, redirect_port (мы не знаем ни dst ip, ни dst port при конфигурации) и ряд хелперов (alias_ftp, как минимум)<br> Сами стейты живут в 2х разных хеш-таблицах (для in и для out). Поиск выполняется следующим образом: * пакеты '''in''' хешируются по dst ip, dst port, link type * пакеты '''out''' хешируются по src ip, dst ip, src port, dst port, link type. Это позволяет "маскам" работать в случае redirect_port, поскольку src ip, src port не участвуют в хешировании пакета и нужный стейт (с redirect port) находится. redirect_proto таким образом работать не может, поскольку первый пакет может прилететь не снаружи, а изнутри. Для того, чтобы редирект все-таки работало, во всех функциях, транслирующих адреса "изнутри" "наружу" в случае неудачного поиска делается отдельный хитрый поиск с указанием только src ip, dst ip и протоколом (link type) для проверки существования redirect_address. Модули libalias: Сам по себе nat является достаточно тривиальной задачей: нужно уметь транслировать TCP/UDP (адреса/порты), ICMP (адреса + сообщения об ошибках, которые надо матчить в существующие сессии), прочие протоколы (только адреса). Это все делается на L4 по более-менее фиксированным смещениям. Тем не менее, существует достаточное количесво не nat-friendly протоколов, с которыми тоже желательно что-то уметь делать. Классические примеры: FTP, SIP Здесь нужен (по возможности) полноценный разбор L7, причем в ядре. Libalias предоставляет достаточно удобные инструменты: * модульный интерфейс Здесь можно зарегистрироваться, указать, какой протокол/протоколы нас интересуют и передать ссылки на функции: быстрого матчинга и собственно транслятора * своя пересобиралка пакетов В процессе изменения пакета у него может поменяться длина, что подразумевает необходимость исправлять TCP seq на протяжении всей сессии. Libalias делает это за нас. * Создание wildcads-стейтов. Здесь возможности очень сильно ограничены хешом на out-хуке, поэтому в ряде модулей приходится либо полагаться на удачу (то, что FTP-сервер будет использовать FTP-DATA порт в случае активного FTP), либо выставлять для конфигурации модуля отдельные функции (номер порта в SCCP) В целом, тем не менее, достаточно удобно. Tags: freebsd, ipfw, nat 17 comments Leave a comment ShareFlagLink Comments ( 17 comments — Leave a comment ) dadv Aug. 5th, 2011 02:18 pm (UTC) s/2.3.4.5/${isp2_addr}/ s/ // s/"Фактически" второй раз// rm этот пост 🙂 Link | Reply | Thread | birdofluck Aug. 5th, 2011 03:35 pm (UTC) гм, зачем rm? Link | Reply | Parent | Thread | dadv Aug. 6th, 2011 06:03 pm (UTC) Потому что он больше никому не интересен. Link | Reply | Parent | Thread | birdofluck Aug. 6th, 2011 06:05 pm (UTC) Так мы все же про _пост_ или про _коммент_ ? 🙂 Link | Reply | Parent | Thread | dadv Aug. 6th, 2011 06:31 pm (UTC) Про коммент, конечно. Он тоже пост 🙂 Link | Reply | Parent | Thread | birdofluck Aug. 6th, 2011 07:28 pm (UTC) Ага 🙂 Ты обещал по существу покомментить, кстати Link | Reply | Parent | Thread | dadv Aug. 6th, 2011 07:33 pm (UTC) А ты оказался более исчерпывающь, чем я думал 🙂 Дальше дополнять смысла нет, дальше только полностью переписывать в более академическом стиле с охватом бОльшего количества смежных тем - скрипты для пингования, распространение информации о живости провайдера по внутренней сети путем переписывания ip route с redistribute static и прочие сильно advanced topics, а это уже не формат коммента. Link | Reply | Parent | Thread | birdofluck Aug. 7th, 2011 08:33 am (UTC) Вообще, нат в хитрых позах - больше [small] office specific. Не надо людей пугать еще IGP с редистрибуцией 🙂 А вот про смежные темы можно было бы и понаписать, например про определение живости. Я потом допишу еще и тему про DNS, а потом это все можно будет скомпилировать, описать более подробно и выложить куда-нибудь. Возможно - перевести и дополнить handbook Link | Reply | Parent | Thread | dionisiy_drev Aug. 18th, 2012 02:18 pm (UTC) скажу честно, довольно долго не могу настроить двух провайдеров, в части проброса портов. перепробовал многие варианты и с pf и setfib и разными прокси. Мне нужно добиться как в linux snat dnat, тут почему-то большая проблема, прямая реализация только у pf и natd Edited at 2012-08-18 02:21 pm (UTC) Link | Reply | Thread | birdofluck Aug. 18th, 2012 03:51 pm (UTC) А вопрос в чем? 🙂 Link | Reply | Parent | Thread | dionisiy_drev Aug. 19th, 2012 09:28 am (UTC) Если не получится обязательно задам, а так два провайдера, две физические сетевухи (одна с бридж АДСЛ модем, другая оптика с конвертера) + две физические для локальной сети. Сначала делал через алиасы в том числе и для провайдеров, потом еще две сетевухи добавил (точнее одну с двумя портами, low profile). До балансировки даже не доходил, т.к. перенаправление мне мозги уже вынесло. Надо перенаправлять фтп, рдп ну и еще. Т.к. шлюз в винде указан один, тут остается только в разные подсети выносить каждого провайдера, но тогда балансировка обламывается, вроде как. Короче я Вашу схему еще не пробовал с global, revers и т.д. Link | Reply | Parent | Thread | dionisiy_drev Aug. 20th, 2012 02:43 am (UTC) ipfw nat global это по всем натам шерстит? а где его config? откуда он знает что там переписывать Link | Reply | Thread | dadv Nov. 26th, 2012 01:16 pm (UTC) ему не требуется config, он знает что переписывать по текущим таблицам трансляции рабочих инстансов. Link | Reply | Parent | Thread | Дмитрий Митько Nov. 26th, 2012 01:20 pm (UTC) ошибочка " net.inet.ip.fw_one_pass" net.inet.ip.fw.one_pass Link | Reply | Thread | birdofluck Nov. 26th, 2012 01:23 pm (UTC) Re: ошибочка Поправил, спасибо. Link | Reply | Parent | Thread | stalkernova Dec. 21st, 2012 12:33 am (UTC) А можно выложить полную рабочую версию конечного конфига? А то наличие многоточия и skipto 5000 немного запутывет. Link | Reply | Thread | Сергей Баранов Jul. 11th, 2016 09:32 am (UTC) Спасибо за статью Спасибо за статью, прочитал в целом касаемо nat global все встало на свои места. У меня остался вопрос безопасности по второму примеру (да и думаю к третьему он будет иместо быть): Снаружи мы закрываемся deny_in ipfw nat 1 config ip ${isp1_addr} reset same_ports deny_in # ISP 1 А в каком месте лучше разместить контроль исходящих пакетов, например разрешить пользователям только pop3,smtp выход? Логически просится в блоке [IN] до 5000 блока, сразу после ipfw nat 2 ip4 from any to me recv ${isp2_iface} Link | Reply | Thread | ( 17 comments — Leave a comment )

Перейти к верхней панели