XoRe
-
Публикации
4 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем XoRe
-
-
2GateKeeper:
Про свободу выбора что-нибудь слышали?
2Kuzmich:
Дело не в динамических правилах.
Я вообще не использую динамические правила в своих фаерволлах.
Во первых, не чувстую в них нужды.
Во вторых, при возникновении проблем, не хочу добавлять себе работы с тестированием опций sysctl:
net.inet.ip.fw.dyn_keepalive
net.inet.ip.fw.dyn_short_lifetime
net.inet.ip.fw.dyn_udp_lifetime
net.inet.ip.fw.dyn_rst_lifetime
net.inet.ip.fw.dyn_fin_lifetime
net.inet.ip.fw.dyn_syn_lifetime
net.inet.ip.fw.dyn_ack_lifetime
net.inet.ip.fw.dyn_max
net.inet.ip.fw.dyn_count
net.inet.ip.fw.curr_dyn_buckets
net.inet.ip.fw.dyn_buckets
А мне 100% пришлось бы их тестировать, когда я доказывал одному из наших провайдеров, что проблема не на моей стороне.
-
Статья http://www.opennet.ru/base/net/nat_jump.txt.html натолкнула на решение.
Для примера буду использовать адреса выше, а пробрасываемые порты пусть будут 10000 и 20000.
Решение:
В ipfw у меня НАТ описан так:
${ipfw} add 16010 divert 8668 ip from not me to any via fxp0
${ipfw} add 16020 divert 8669 ip from not me to any via fxp1
${ipfw} add 16030 divert 8672 ip from not me to any via fxp2
Нужно прописать такое правило:
${ipfw} add 15610 divert 8669 tcp from 192.168.0.2 10000,20000 to any out
Причем, как видно из номера правила, его нужно прописать ПЕРЕД правилами с обычным натом.
Суть решения в том, что тогда даже если пакет собирается уйти наружу через другой интерфейс, он все равно будет завернут на нат того интерфейса, через который должен выходить.
После ната у исходящего пакета будет нужный внешний адрес, т.е. 1.1.1.1.
Ну а с помощью правил:
${ipfw} add 23010 fwd 1.1.1.2 ip from 1.1.1.1 to any
${ipfw} add 23030 fwd 2.2.2.3 ip from 2.2.2.2 to any
${ipfw} add 23040 fwd 10.0.0.4 ip from 10.0.0.3 to any
Пакет уйдет через тот линк, через который нужно.
fwd правила - это реализация policy based routing.
В целом решение получается такое:
Определиться с интерфейсом, на котором пробрасывать порты.
Такой интерфейс должен быть один.
Настроить на нем редирек портов вида:
-redirect_port tcp 192.168.0.2:10000 20000
Ну и добавить в фаерволл правило, которое будет подхватывать исходящие пакеты с пробрасываемого порта и прописывать им нужный внешний адрес.
2GateKeeper:
Динамическому равилу fwd неоткуда создаться при такой настройке.
-
Стоит машинка на FreeBSD 6.0.
У машинки 3 линка в интернет (у 2 линков реальные ип адреса, у третьего ип из сети 10.0.0.0, выходит в интернет через НАТ провайдера).
Причем один линк (который через НАТ) указан, как default gateway.
А на каждый из двух других линков прописано по некоторому количеству статических маршрутов.
И есть линк в локальную сеть 192.168.
А в локальной сети стоит ещё одна машинка.
Допустим, адреса на линках в интернет такие: 1.1.1.1, 2.2.2.2 и 10.0.0.3.
И допустим, внутренний ип-адрес машинки 192.168.0.1.
А ип-адрес ещё одной машинки в локалке 192.168.0.2.
Задача: пробросить в локальную сеть пару портов на 192.168.0.2.
Причем нужно, чтобы 192.168.0.2 видел, с какого адреса из интернета к нему идет подключение.
Кажется простым делом, с которым справляется ipfw+natd благодаря опции redirect-port.
Он отлично справляется, если все идет через один канал.
А когда несколько каналов, то получается вот что:
Приходит пакет с какого-то адреса в интернете (допустим с адреса 5.5.5.5) на адрес 1.1.1.1. (пакет 5.5.5.5 -> 1.1.1.1).
Проходит внутрь локалки, становясь пакетом вида 5.5.5.5 -> 192.168.0.2.
Машинка в локальной сети отвечает пакетом 192.168.0.2 -> 5.5.5.5.
И тут начинаются грабли.
Если ответный пакет уйдет в интернет с линка 1.1.1.1, то он преобразуется в пакет 1.1.1.1 -> 5.5.5.5.
И все будет нормально, ушел пакет 5.5.5.5 -> 1.1.1.1, пришел пакет 1.1.1.1 -> 5.5.5.5, соединение установлено.
А если ответный пакет уйдет с линка 2.2.2.2 или 10.0.0.3, то компьтеру придет ответный пакет 2.2.2.2 -> 5.5.5.5 или 10.0.0.3 -> 5.5.5.5, что довольно сложно опознать, как ответ на пакет 5.5.5.5 -> 1.1.1.1.
Сейчас это делается посредством программы redir (/usr/ports/net/redir).
Но у этой программы есть один нюанс.
При посылке пакета вида 5.5.5.5 -> 1.1.1.1 при прохождении через нашу машинку пакет преобразовывается в 192.168.0.1 -> 192.168.0.2.
Т.е. для машины 192.168.0.2 все соединения идут с адреса 192.168.0.1.
На пробрасываемый порт будут обращаться из разных точек интернета.
И ответ на них идет по тому линку, который указан в таблице маршрутизации.
Список точек неизвестен, поэтому жестко прописать маршрутизацию или fwd на них не получится.
Сам по себе policy based routing на основе fwd давно настроен и работает.
Доступ к серверу с любого из линков и работа клиентов в инете работает на ура.
Необходимо сделать проброс так, чтоб 192.168.0.2 видел, с какого адреса из интернета к нему идет подключение.
Подскажите, пожалуйста, решение для сей ситуации.
Looking Glass & Quagga
в Программное обеспечение, биллинг и *unix системы
Опубликовано · Изменено пользователем XoRe · Жалоба на ответ
Если её закомментировать, то будет работать только для quagga.
Чтобы работала и для quagga, и для cisco, нужно поменять цыфырки:
31, 0, 200, 0, 0, # TELOPT_NAWS -> 31, 0, 0, 0, 0, # TELOPT_NAWS
Теория:
Третье и пятое число - это размер терминала в ширину и в высоту.
Третье число - количество символов в строке.
Пятое - количество строк на экране.
Разгадка:
Скрипт LG не работал изза того, что quagga думал, что к нему подключился клиент с маленьким монитором.
И сервер вел себя стандартным образом, когда текст не помещается на экране.
Выдавал часть информации, писал строчку "--More--" и тупо ждал ввода символов.
Скрипт, естественно, никаких символов не вводил и тупо отваливался по timeout.
Если указать в третьем и пятом числе нули, то quagga поймет, что к нему подключились с офигенно большим монитором.
Соответственно, текст всегда будет выводиться сразу и полностью.