» NAT и публикация сервисов с учётом virtual hosts

LevT
Да так и есть.
Кстати если нужно именно по ssh ходить то можно проще, что бы лишний терминал не висел...
ssh -o "ProxyCommand=ssh -p 27 root@172.22.0.3 nc %h %p" root@192.168.0.6 - вместо проброса порта, если нужно по ssh ходить. где 192.168.0.6 - внутри удалённой локали, а 172.22.0.3 ip шлюза. При таком способе, кстати, не будет косяка с файлом known_hosts, т.к. считается что ip каждый раз свой.

Есть еще замута с динамическим пробросом портов (ключ -D), в таком случае ssh создаёт socks proxy, только я не помню как потом ssh клиент выпустить через этот socks, можно браузер выпустить...

Добавлено:
FingerPrint ни как не связан с авторизацией по сертификату, это защитный механизм, запоминания "образа" сервера, что бы при повторном подключение клиент узнал, если кто-то хочет провернуть MITM, поэтому при первом подключение к серверу стоит внимательно отнестись к занесению его отпечатка в свою базу знаний (а то вдруг уже кто-то ждёт тебя, и хана твоему серверу).
На opennet'е есть неплохая статья по authorized by key.

Добавлено:
LevT
Ух... В Debian удалось выпустить так:
Сначала создаёт socks proxy: ssh -D 1999 remote_gw
Потом шляемся через него: ssh -o "ProxyCommand=nc.openbsd -x localhost:1999 %h %p" root@192.168.233.2
Пришлось поставить пакет netcat-openbsd, со стандартным не вышло, пробовал ncat --proxy-type socks4 --proxy localhost:1999 - просто подвисало соединение и всё.

Спасибо!

Вопрос по дизайну фаервола.

Один из мотивов, следуя которым я разделил шлюзы dnat-gw и snat-gw был таков: я хотел максимально избавиться на snat-gw от ручной конфигурации фаервола.

Но вот вчера обнаружил, что это не катит: для SSH-доступа к внутреннему интерфейсу snat-gw через DNAT на dnat-gw на первом всё равно приходится прописывать правило Eхternal-to-Zentyal.

Видимо, помочь соблюсти цель дизайна может дополнительный SNAT на dnat-gw?



Я в курсе, что мелкомягкие бест-практисы советуют прямо обратный дизайн: ставить UAG (функционально навороченный аналог dnat-gw) в DMZ за фаерволом TMG (в моём случае за snat-gw), пробрасывать туда http(s)-трафик 1:1 и при нужде фильтровать.

(Сам не уверен, какие мотивы у них там преобладают: технические или впаривательные...)

LevT
Мотивы всё равно не понял, какая разница на какой из машин настройки прописывать?

В смысле не катит? ssh -o "ProxyCommand=ssh user@dnat-gw-ext-ip nc %h %p" admin@snat-gw-int-ip - Так не подключается?

Alukardd

Цитата:

Мотивы всё равно не понял, какая разница на какой из машин настройки прописывать?

Я ценю модульность: она реально помогает.

Например, когда я решил попробовать Zentyal вместе с nginx - я всего лишь выдернул виртуальные линки из микротика dnat2-gw на границе со вторым провом.
(Воткнул эти линки в snat-gw, завёл его, а потом добавил к нему линк на первого прова).

Всё остальное продолжает работать как работало (включая старый дефолтный шлюз локалки, которыму я только сменил адрес, отобрав известный клиентам в пользу snat-gw), админская избыточность сохраняется: я не рискую отрубить сам себе удалёнку: под возможные источники ошибок подложена страховка. Юзеры если и заметили в результате случившегося изменения какие-то вылезшие косяки в настройке одного из вебсервисов (линуксового, кстати, настроенного кем-то задолго до меня) - то это помогло сейчас исправить контролируемым образом то, что иначе могло вылезти в неконтролируемый момент.

Линуксоид тот кстати, сам прибежал: у него оказался жесткий айпишник в настройках подключения ))
Я забыл добавить, что ещё поменял местами в сети первого прова айпишники двух шлюзов и заодно подчистил мусор в публичной DNS зоне.


Добавлено:


Цитата:

ssh -o "ProxyCommand=ssh user@dnat-gw-ext-ip nc %h %p" admin@snat-gw-int-ip - Так не подключается?

У меня линукса снаружи нет, потому буквально проверить не могу. А сказать то же самое галочками в SecureCRT пока затрудняюсь.



Добавлено:
Не катит подключение к опубликованному айпишнику dnat1-gw по 2222 порту, которое там DNAT-ится на 22 порт внутреннего адреса snat-gw.

С самого dnat-gw такое подключение работает.

LevT
Либо выполнять SNAT в сторону локалки на dnat-gw, либо попытаться на snat-gw вернуть пакет кому следует через iproute2. Суть идеи как с несколькими провайдерами, у меня только сомнения что всё получится... (пример с провайдерами есть в LARTC)

Цитата:

Но назрела необходимость осилить наконец nginx, ну и подвернулась возможность разобраться с Zentyal - и вот я заменил им один из граничных микротиков, и балансировщик заюзал тамошний.  А раз один из граничных роутеров потяжелел, возникла мысль обойтись без третьего роутера.  
 

Наверное, отдельный от бордеров дефолтный шлюз всё-таки нужен - потому что когда-нибудь у меня дойдут руки до реализации VRRP/CARP. По смыслу ведь подобный сервис защищает только дефолтный шлюз: от падения одного из каналов есть WAN файловер. Второй виртуальный VRRP шлюз заведу под соседним физическим хостом, туда же ткну один из граничных роутеров в лёгком варианте (типа того, что был у меня недавно с микротиками), и граничные роутеры дублировать не буду.

Или WAN канал тоже можно повесить на виртуальный адрес VRRP для доп. защиты от падения именно граничного роутера (поставив между ним и провайдером грошовый свич)? Что думаете?

LevT
Думаю, что шлюз это либо 2 физические машины (древние, там ресурсы почти не едятся) с настроенным VRRP/CARP, ЛИБО это виртуальная машина, тогда уже не нужны carp'ы и прочее, т.к. лучше настраивать HA средствами гипервизора (failover instance, так сказать). Первый вариант предпочтительнее, т.к. более безопасен - шлюз всё-таки должен отрезать сеть от внешнего мира, а не являться частью сети, которая слишком близко к реальному миру.

Fully Routed Network - это тоже достойный design goal, на мой взгляд.

Если мне удастся продвинуться в этом направлении, получится 1) искоренить множество ручных настроек сетевого уровня и 2) роутеры станут взаимозаменимыми.

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

Ну или хотя бы автогенерить чек-листы для настройки шлюзов. Чем легче будут те шлюзы, тем легче достичь заменяемости. (Та заменяемость, которая сейчас у меня есть - зависит от моей квалификации и нынешнего понимания зависимостей. Через год допустим описанная выше замена шлюза столь гладко не прошла бы: я наверняка не буду помнить детали конструкции.)

А HA средствами гипервизора я могу включить хоть сейчас... но тяжеловато будет переключать навороченный шлюз и попасть от него в зависимость.


Добавлено:

Zentyal вовсе не сахар. С 4-мя гектарами памяти едва ворочается, особенно долго коммитятся изменения конфигов.


Добавлено:

Как разберусь с линуксовой инфраструктурой в этой "коробочке" - вынесу в отдельные машинки то, что сочту оправданным вынести.

А там дальше решу, куда двигаться.

LevT
Хз что там у вас еле ворочается... Я, конечно, все эти " коробочные программные маршрутизаторы" не юзал, но они не должны есть сильно больше ресурсов чем handmade сервер.

Цитата:

Fully Routed Network

не совсем понимаю, что это значит в рамках одного офиса. Какие настройки это искоренит? Какая полная заменяемость? (речь всё-таки об одном офисе?)

Я ж говорю: одним офисом не ограничиваюсь. Офис у меня подопечный не один, просто здесь оказалось возможным собрать удобную для экспериментов инфраструктуру.


Добавлено:

Цитата:

Я, конечно, все эти " коробочные программные маршрутизаторы" не юзал, но они не должны есть сильно больше ресурсов чем handmade сервер.

В целях самообучения я установил вообще все модули.
Разумеется, коммит изменений длится вечность.

Добавлено:
(но всё ж быстрее и главное безопаснее, чем если бы надо было всё перенастраивать ручками ))

Alukardd

Цитата:

не совсем понимаю, что это значит в рамках одного офиса.

Цитата:

Я ж говорю: одним офисом не ограничиваюсь.

Вот! Поймал себя на оправдании. А, собственно, почему я должен оправдываться в своём стремлении делать добротные неодноразовые масштабируемые вещи, удобные для поддержки и обслуживания?

Ну вот есть у меня страсть к такого рода задачкам. Я же не обесцениваю Вашу страсть к детальному изучению закоулков манов...



Цитата:

Сначала создаёт socks proxy: ssh -D 1999 remote_gw
Потом шляемся через него: ssh -o "ProxyCommand=nc.openbsd -x localhost:1999 %h %p" root@192.168.233.2
Пришлось поставить пакет netcat-openbsd, со стандартным не вышло, пробовал ncat --proxy-type socks4 --proxy localhost:1999 - просто подвисало соединение и всё.

Открыл для себя-виндузоида и "сетевика" нового (выбравшего пепси) поколения -совершенно новую область знания: соксы.

http://www.redbooks.ibm.com/redbooks/GG243376/wwhelp/wwhimpl/api.htm?href=22-5.htm
(ссылка исправлена)

Не, слово-то я такое слышал и раньше. Даже использовал пару раз проксификаторы в проектах, не отдавая себе отчёта в их функциях и устройстве - потому что был зажат по ресурсам и потому далёк от возвышенных интересов.

LevT
Так я не против маршрутизируемости. Я честно не понимаю как это выглядит в рамках одного офиса. Никогда с этим не сталкивался...

Да мои знания тоже весьма узки и не полные даже в том что я знаю... Вот сейчас немного познакомлюсь с гипервизорами и телефонией в рамках предприятия, а не 3-х человек.

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

Не всегда такое возможно в условиях, когда ресурсов в обрез - ну так это первая для нас для всех общая проблема: нас зажимают в ресурсах и учат довольствоваться рабским положением винтика в чужом механизме.

Человеку свойственно забывать, рассеиваться, терять контекст... Ну так что мешает инкапсулировать свои знания мелких деталей в виртуалки с чОтким интерфейсом, а опыт прилагать к достижению более крупных и индивидуализированных целей? И желательно собственных, согласованных между сторонами с учётом их интересов, а не навязанных извне за морковку.


Добавлено:


Цитата:

Я честно не понимаю как это выглядит в рамках одного офиса.

да примерно так же - только в случае правильного дизайна сложность добавления новых офисов O(1), а затраты заказчика на доп. приобретения минимальны. Человеческий ресурс технаря сберегается для творческих интересных задач и не изводится на мартышкин труд.

Вот, наткнулся на очередное преимущество той архитектуры, к которой я стремлюсь: с изоляцией сервисов и легковесными роутерами. Подтвердились мои невесёлые предположения насчет линуксовых "коробочек"-вебморд.

Сначала я решил добавить к Zentyal несколько алиасов из сети первого провайдера - фаерволл оказался в несогласованном состоянии, не давал доступа к настройкам порт форвардинга на дефолтном айпишнике. Глюк вначале казался косметическим, всё вроде работало.

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


Посоветуете производить такого рода переконфигурацию руками, выкинув дурацкие "коробочки"? Не вижу смысла приобретать и постоянно поддерживать в себе подобную квалификацию настройщика шлюзов. Потому что.

Компромиссный вариант использования коробочки: НИКОГДА не перенастраивать интерефейсы. То есть сделал шлюз в фиксированной конфигурации - и сдувай с него пыль потом вовек. Не нравится мне такая перспектива, ну развращён я циской и вмваре. Да и мелкософтом, пожалуй.


Добавлено:

Родной "дизастер рекавери план" для Zentyal - следовать путём труЪ мелкософт-самурая, подписавшись на облачный бэкап: http://forum.zentyal.org/index.php/topic,5854.0.html

Нах-нах...

LevT
Могу лишь напомнить Вам, что с коробками не работал, когда мне предложили поюзать IPCop я поставил его на тестовую машинку, посмотрел на настройки и форматнул винт) Собственно я за "ручками".
Цитата:

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

мб Вы и правы, хотя я других мнений придерживаюсь... Единственное, это я стараюсь после успешных операций, записать поэтапно что где и как. Иногда после повторного сталкивания с проблемой заметки пополняются. Зато, по ним я всегда могу повторить операцию. Отдавать настройку на откуп каким-то софтинам мне не очень нравится, точнее это следует делать но только на самом нижнем уровне, что бы совсем в системе не погрязнуть, например, я люблю вкусняшки по настройки сети в Debian интегрированные в файл interfaces, хотя некоторые из них имеют ограничения.

Alukardd

Цитата:

мб Вы и правы, хотя я других мнений придерживаюсь...

да я не меряюсь правами )
Бесссмысленное занятие в свете вот этого, контрпродуктивное.

Без надёжной и подконтрольной исполняющей среды никакой "дизайнер" далеко не уедет. Но ехать-то надо далекоОо, гораздо дальше, чем может удержать в голове один человек, хотя бы и с помощью записей.



Цитата:

Отдавать настройку на откуп каким-то софтинам мне не очень нравится,

Мне это тоже не нравится, но не столь сильно, как увязание в деталях и вызванное им исчерпание человеческого ресурса, неспособность за деревьями видеть лес и преследовать свои намерения на его счёт. ))


Кроме того, я считаю, что повторяющуюся монотонную нетворческую работу надо оффлоадить компьютерам. Странный выбор не пользоваться инструментом, именно для этой цели созданным, достигшим невиданной мощи и подручным по определению.




Добавлено:

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

Да-да, всё равно команды иптаблес как-то процессятся перед тем, как скармливаются ядру (хотя бы текст парсится). Что мешает разрешить там использовать псевдонимы вместо цыферь?


Добавлено:

При всей своей мордатости даже зентиял и микротик не решаются вот в этом месте порвать с традицией или хотя бы предоставить возможность выбора.
Мне кажется, столь укоренившаяся дурная практика неизлечима: потому надо поскорее выкинуть фраерловы на свалку и переходить на ipsec v6

Кстати, вот длинннющие адреса ipv6 - линуксоиды их тоже намерены повторять ручками во всех без исключения конфигах?
Если с ними всё-таки решились порвать шаблон - то почему бы не подумать об ipv4?

http://forum.ru-board.com/topic.cgi?action=addbookmark&forum=65&topic=4533

LevT
Мог сюда не дублировать. Ветки для сисадминов и по никсам лично у меня открыты всегда.

Alukardd

А что за фигня в этом зентиале?
Команда route не выводит дефолтного маршрута. Как будто и нет такого.
При том всё пашет.

Или это фигня в моих знаниях?

LevT
Цитата:

Команда route не выводит дефолтного маршрута.

а остальные выводит? мб тогда вывод покажете? Если вы пользовались правилами маршрутизации то всё своё добро можно посмотреть так: ip r s table all

Alukardd

Цитата:

Если вы пользовались правилами маршрутизации

Действительно, зентиял ими пользуется - но меня об этом не предупреждает ))

Понятна по этому поводу злоба "линуксоида" (в. т.ч. и соответствующей части моей собственной психики)
Но... попытаюсь объясниться с точки зрения "виндузятника": оно УЖЕ работает и не встряло на дороге моих планов крутой лёрнинг курвой.


Кажется, я ошибся насчёт микротика:

Цитата:

При всей своей мордатости даже зентиял и микротик не решаются вот в этом месте порвать с традицией или хотя бы предоставить возможность выбора.

есть там какие-то address-lists. Ща попробую заюзать. В зентияле "network objects" оказались не про то...

LevT
Дык я не понял, что там у Вас с таблицами маршрутизации? Нашли концы - как пакеты в мир уходят?)

нормально, по таблице 102

Задумался над табличкой. Всё ли у меня в порядке с дефолтными маршрутами? Если так, то объясните смысл существования трех таблиц при двух шлюзах.


Код:
default via 195.1.1.1 dev eth2 table 102 src 195.1.1.2
10.111.113.66 dev ppp0 proto kernel scope link src 10.111.113.65
195.1.1.0/30 dev eth2 proto kernel scope link src 195.1.1.2
79.1.1.0/29 dev eth1 proto kernel scope link src 79.1.1.2
10.111.112.0/24 dev eth0 proto kernel scope link src 10.111.112.3
10.201.64.0/18 dev tap0 proto kernel scope link src 10.201.80.143
10.200.0.0/16 via 10.201.64.1 dev tap0
default via 195.1.1.1 dev eth2 table 103 src 195.1.1.2
default via 79.1.1.1 dev eth1 table 101 src 79.1.1.2
default table default
nexthop via 79.1.1.1 dev eth1 weight 1
nexthop via 195.1.1.1 dev eth2 weight 1
broadcast 10.111.112.0 dev eth0 table local proto kernel scope link src 10.111.112.3
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 10.111.112.3 dev eth0 table local proto kernel scope host src 10.111.112.3
broadcast 79.1.1.7 dev eth1 table local proto kernel scope link src 79.1.1.2
broadcast 10.201.127.255 dev tap0 table local proto kernel scope link src 10.201.80.143
local 10.201.80.143 dev tap0 table local proto kernel scope host src 10.201.80.143
broadcast 79.1.1.0 dev eth1 table local proto kernel scope link src 79.1.1.2
local 79.1.1.2 dev eth1 table local proto kernel scope host src 79.1.1.2
broadcast 195.1.1.0 dev eth2 table local proto kernel scope link src 195.1.1.2
broadcast 10.111.112.255 dev eth0 table local proto kernel scope link src 10.111.112.3
local 10.111.113.65 dev ppp0 table local proto kernel scope host src 10.111.113.65
local 195.1.1.2 dev eth2 table local proto kernel scope host src 195.1.1.2
broadcast 10.201.64.0 dev tap0 table local proto kernel scope link src 10.201.80.143
broadcast 195.1.1.3 dev eth2 table local proto kernel scope link src 195.1.1.2
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
fe80::/64 dev eth1 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth2 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
fe80::/64 dev tap0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo table unspec proto kernel metric -1 error -101 hoplimit 255
local ::1 via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295
local fe80::250:56ff:fe8b:589 via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295
local fe80::250:56ff:fe8b:58a via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295
local fe80::250:56ff:fe8b:58b via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295
local fe80::e457:ff:feb1:38ee via :: dev lo table local proto none metric 0 mtu 16436 advmss 16376 hoplimit 4294967295
ff00::/8 dev eth1 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth2 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev eth0 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
ff00::/8 dev tap0 table local metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
unreachable default dev lo table unspec proto kernel metric -1 error -101 hoplimit 255

LevT
Надо посмотреть на вывод ip ru s
Скорее всего таблицу 102 задали вы своими махинациями для файлопомоек и она подчиняется особым правилам...

Добавлено:
По поводу трейсов это надо смотреть на правила iptables/netfiter.

Alukardd

Код:
$ ip ru s
0: from all lookup local
32759: from all lookup main
32760: from 79.1.1.2 lookup 101
32761: from 79.1.1.1 lookup 101
32762: from all fwmark 0x1/0xff lookup 101
32763: from 195.1.1.2 lookup 102
32764: from 195.1.1.1 lookup 102
32765: from all fwmark 0x2/0xff lookup 102
32766: from all lookup main
32767: from all lookup default

LevT
Ну как бы да, vrrp или carp должен быть настроен, если нужна отказоустойчивость. И лучше вместе с conntrackd.

Что касается маршрута для table 103, то он конечно прописан, но что-то я не наблюдаю правил для попадания пакета в соответсвующую таблицу.

p.s. полемику по поводу файлопомоек разводить не хочу...

Цитата:

если нужна отказоустойчивость.

Вообще-то она нужна всегда и всем. Людям от IT доступность сервисов нужна всегда - а отдельную плату за отказоустойчивость требуют бесстыжие торгаши, которые впаривают вместо ТОВАРА подделки под него и модельки, радующие глаз блондинок обоего пола.

А вот админу нужна гибкость, для оптимизации сетевых сервисов на ходу и защиты от собственных ошибок. HA дефолтного шлюза - средство для этой цели. Даже если начальство жмотится платить "за отказоустойчивость" .



Цитата:

И лучше вместе с conntrackd.

А вот здесь можно подробнее? Не могу увязать смысл связки (который вроде понимаю) с теми шагами, которые следует проделать.



Цитата:

Что касается маршрута для table 103, то он конечно прописан, но что-то я не наблюдаю правил для попадания пакета в соответсвующую таблицу.

Не уверен что следует разбираться с тем инстансом зентияла (хотя он у меня сохранён в снапшоте на всяк случай): я в лучших традициях виндузятника всё уже переустановил ))


Добавлено:

Вот иптаблес от свеженастроенного зентияла. Что здесь бесспорные бестпрактисы. а что их отсебятина? Что бы Вы ещё сделать посоветовали?

[more]
Код:
# iptables -L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
idrop all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
inospoof all -- anywhere anywhere
iexternalmodules all -- anywhere anywhere
iexternal all -- anywhere anywhere
inoexternal all -- anywhere anywhere
imodules all -- anywhere anywhere
iintservs all -- anywhere anywhere
iglobal all -- anywhere anywhere
ACCEPT icmp !f anywhere anywhere icmp echo-request state NEW
ACCEPT icmp !f anywhere anywhere icmp echo-reply state NEW
ACCEPT icmp !f anywhere anywhere icmp destination-unreachable state NEW
ACCEPT icmp !f anywhere anywhere icmp source-quench state NEW
ACCEPT icmp !f anywhere anywhere icmp time-exceeded state NEW
ACCEPT icmp !f anywhere anywhere icmp parameter-problem state NEW
idrop all -- anywhere anywhere

Chain FORWARD (policy DROP)
target prot opt source destination
fdrop all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
fnospoof all -- anywhere anywhere
fredirects all -- anywhere anywhere
fmodules all -- anywhere anywhere
ffwdrules all -- anywhere anywhere
fnoexternal all -- anywhere anywhere
fdns all -- anywhere anywhere
fobjects all -- anywhere anywhere
fglobal all -- anywhere anywhere
ACCEPT icmp !f anywhere anywhere icmp echo-request state NEW
ACCEPT icmp !f anywhere anywhere icmp echo-reply state NEW
ACCEPT icmp !f anywhere anywhere icmp destination-unreachable state NEW
ACCEPT icmp !f anywhere anywhere icmp source-quench state NEW
ACCEPT icmp !f anywhere anywhere icmp time-exceeded state NEW
ACCEPT icmp !f anywhere anywhere icmp parameter-problem state NEW
fdrop all -- anywhere anywhere

Chain OUTPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
odrop all -- anywhere anywhere state INVALID
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ointernal all -- anywhere anywhere
omodules all -- anywhere anywhere
oglobal all -- anywhere anywhere
ACCEPT icmp !f anywhere anywhere icmp echo-request state NEW
ACCEPT icmp !f anywhere anywhere icmp echo-reply state NEW
ACCEPT icmp !f anywhere anywhere icmp destination-unreachable state NEW
ACCEPT icmp !f anywhere anywhere icmp source-quench state NEW
ACCEPT icmp !f anywhere anywhere icmp time-exceeded state NEW
ACCEPT icmp !f anywhere anywhere icmp parameter-problem state NEW
odrop all -- anywhere anywhere

Chain drop (15 references)
target prot opt source destination
DROP all -- anywhere anywhere

Chain fdns (1 references)
target prot opt source destination
ACCEPT udp -- anywhere dc.mydomain.lan state NEW udp dpt:domain
ACCEPT tcp -- anywhere dc.mydomain.lan state NEW tcp dpt:domain
ACCEPT udp -- anywhere google-public-dns-a.google.com state NEW udp dpt:domain
ACCEPT tcp -- anywhere google-public-dns-a.google.com state NEW tcp dpt:domain
ACCEPT udp -- anywhere google-public-dns-b.google.com state NEW udp dpt:domain
ACCEPT tcp -- anywhere google-public-dns-b.google.com state NEW tcp dpt:domain

Chain fdrop (8 references)
target prot opt source destination
drop all -- anywhere anywhere

Chain ffwdrules (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain fglobal (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere

Chain fmodules (1 references)
target prot opt source destination

Chain fnoexternal (1 references)
target prot opt source destination
fdrop all -- anywhere anywhere state NEW
fdrop all -- anywhere anywhere state NEW

Chain fnospoof (1 references)
target prot opt source destination
fnospoofmodules all -- anywhere anywhere
fdrop all -- 10.1.1.0/24 anywhere
fdrop all -- 79.1.1.0/29 anywhere
fdrop all -- 195.1.1.1/30 anywhere

Chain fnospoofmodules (1 references)
target prot opt source destination

Chain fobjects (1 references)
target prot opt source destination

Chain fredirects (1 references)
target prot opt source destination

Chain ftoexternalonly (0 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere
fdrop all -- anywhere anywhere

Chain idrop (7 references)
target prot opt source destination
drop all -- anywhere anywhere

Chain iexternal (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
drop tcp -- anywhere anywhere tcp dpt:submission state NEW
drop tcp -- anywhere anywhere tcp dpt:4190 state NEW
drop tcp -- anywhere anywhere tcp dpt:imap2 state NEW
drop tcp -- anywhere anywhere tcp dpt:imaps state NEW
drop tcp -- anywhere anywhere tcp dpt:pop3 state NEW
drop tcp -- anywhere anywhere tcp dpt:pop3s state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:ssmtp state NEW
drop udp -- anywhere anywhere udp dpts:10000:20000 state NEW
drop udp -- anywhere anywhere udp dpt:5036 state NEW
drop udp -- anywhere anywhere udp dpt:iax state NEW
drop udp -- anywhere anywhere udp dpt:sip state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:1723 state NEW
ACCEPT gre -- anywhere anywhere state NEW

Chain iexternalmodules (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain iglobal (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:submission state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:4190 state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:imap2 state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:imaps state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:pop3 state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:pop3s state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:ssmtp state NEW
ACCEPT udp -- anywhere anywhere udp dpts:10000:20000 state NEW
ACCEPT udp -- anywhere anywhere udp dpt:5036 state NEW
ACCEPT udp -- anywhere anywhere udp dpt:iax state NEW
ACCEPT udp -- anywhere anywhere udp dpt:sip state NEW
drop tcp -- anywhere anywhere tcp dpt:ldap state NEW
drop tcp -- anywhere anywhere tcp dpt:6677 state NEW
ACCEPT udp -- anywhere anywhere udp dpt:domain state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:domain state NEW
ACCEPT udp -- anywhere anywhere udp dpt:bootps state NEW
ACCEPT udp -- anywhere anywhere udp dpt:tftp state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh state NEW
ACCEPT tcp -- anywhere anywhere tcp dpt:https state NEW

Chain iintservs (1 references)
target prot opt source destination

Chain imodules (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:3128

Chain inoexternal (1 references)
target prot opt source destination
idrop all -- anywhere anywhere state NEW
idrop all -- anywhere anywhere state NEW

Chain inointernal (0 references)
target prot opt source destination

Chain inospoof (1 references)
target prot opt source destination
inospoofmodules all -- anywhere anywhere
idrop all -- 10.1.1.0/24 anywhere
idrop all -- 79.1.1.0/29 anywhere
idrop all -- 195.1.1.1/30 anywhere

Chain inospoofmodules (1 references)
target prot opt source destination

Chain log (0 references)
target prot opt source destination
RETURN all -- anywhere anywhere

Chain odrop (2 references)
target prot opt source destination
drop all -- anywhere anywhere

Chain oglobal (1 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere state NEW

Chain ointernal (1 references)
target prot opt source destination
ACCEPT udp -- anywhere dc.mydomain.lan state NEW udp dpt:domain
ACCEPT tcp -- anywhere dc.mydomain.lan state NEW tcp dpt:domain
ACCEPT udp -- anywhere google-public-dns-a.google.com state NEW udp dpt:domain
ACCEPT tcp -- anywhere google-public-dns-a.google.com state NEW tcp dpt:domain
ACCEPT udp -- anywhere google-public-dns-b.google.com state NEW udp dpt:domain
ACCEPT tcp -- anywhere google-public-dns-b.google.com state NEW tcp dpt:domain
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:domain
ACCEPT udp -- anywhere anywhere state NEW udp dpt:domain

Chain omodules (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:smtp
ACCEPT tcp -- anywhere anywhere tcp dpt:www
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:www
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https

LevT
carp в лице ucarp позволяет следить за "напарником" и в случае отказа у него какого-либо интерфейса взвалить весь труд на себя. А conntrackd просто синхронизирует таблицу сетевых соединений. Т.о. образом при падении основного шлюза второй не просто получит его ip, но и будет знать о всех установленных соединениях, так что клиент даже не прочувствует подвоха в случае ssl и тому подобных соединений методом CONNECT.

Цитата:

Как же зенитиял балансирует трафик? Где посмотреть эти конфиги?

а вы их уже видели) Вот они:
default table default
nexthop via 79.1.1.1 dev eth1 weight 1
nexthop via 195.1.1.1 dev eth2 weight 1

p.s. iptables попозже гляну. Если не сложно, гляньте на мой вопрос.

Цитата:

default table default
nexthop via 79.1.1.1 dev eth1 weight 1
nexthop via 195.1.1.1 dev eth2 weight 1

Забавно... В микротике я такого не заметил. Мобыть. оно там называется иначе - например, VRF?