Jump to content
Калькуляторы

XoRe

Пользователи
  • Content Count

    4
  • Joined

  • Last visited

About XoRe

  • Rank
    Абитуриент
  1. Если её закомментировать, то будет работать только для quagga. Чтобы работала и для quagga, и для cisco, нужно поменять цыфырки: 31, 0, 200, 0, 0, # TELOPT_NAWS -> 31, 0, 0, 0, 0, # TELOPT_NAWS Теория: Третье и пятое число - это размер терминала в ширину и в высоту. Третье число - количество символов в строке. Пятое - количество строк на экране. Разгадка: Скрипт LG не работал изза того, что quagga думал, что к нему подключился клиент с маленьким монитором. И сервер вел себя стандартным образом, когда текст не помещается на экране. Выдавал часть информации, писал строчку "--More--" и тупо ждал ввода символов. Скрипт, естественно, никаких символов не вводил и тупо отваливался по timeout. Если указать в третьем и пятом числе нули, то quagga поймет, что к нему подключились с офигенно большим монитором. Соответственно, текст всегда будет выводиться сразу и полностью.
  2. 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% пришлось бы их тестировать, когда я доказывал одному из наших провайдеров, что проблема не на моей стороне.
  3. Статья 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 неоткуда создаться при такой настройке.
  4. Стоит машинка на 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 видел, с какого адреса из интернета к нему идет подключение. Подскажите, пожалуйста, решение для сей ситуации.