Subnets.ru blog

Добро пожаловать в блог! Надеемся, что Вы еще вернетесь.

Поводом для написание этой статьи стало обращение знакомого с вопросом о пробросе порта внутрь локалки.

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

Через некоторое время он постучался снова, снова с просьбой помочь, что у него не получается. Ну что ж, полез смотреть…..

Вот тут то и выяснился один нюанс, что ему нужно не просто пробросить порт, т.к. default gateway у железки смотрит не на сервер, с которого он пытается пробросить порт.

Дабы не объяснять потом одно и тоже очередному знакомому решил накатать сей пост, копипаст рулит ! :)))))

Для простоты будем считать, что у железки  default gateway вообще отсутствует. Почему ?

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

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

Уже есть одна, написанная мной, статья о natd: Выпускаем локальную сеть в Интернет используя сервер на FreeBSD и NATD, пусть будет вторая, продолжу тему.

Исходные данные будут такие:

• Реальник сервера: 8.8.8.8 (да да, ну люблю я гугл :)))
• Внутренний адрес железки: 10.0.2.18
• Пробрасываем на железку порт 80 через порт 8080 на сервере (т.к. порт 80 на сервере уже занят apache`ом)
• Сервер с FreeBSD 7.2
• Внешний интерфейс: em0
• Внутренний интерфейс: em1

Для полноты «картины» в статье сначала рассмотрим обычный вариант, а именно схему:

Интернет <==> (<— default GW) [8.8.8.8] Сервер с реальником [10.0.2.2]<===> (<— default GW) [10.0.2.18] Железка с внутренним адресом (default gateway смотрит на сервер)

Так уж повелось, что для natd я никогда не юзал конфиг, а так же не заворачиваю весь трафик с внешнего интерфейса в NAT.

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

Вот и в этом случае обойдемся без конфига, тем более, напомню, это времянка.

Откройте мануал (man natd), как же без него 😉

-redirect_port proto targetIP:targetPORT[-targetPORT]
[aliasIP:]aliasPORT[-aliasPORT]
[remoteIP[:remotePORT[-remotePORT]]]

……………..

The natd utility provides a Network Address Translation facility for use with divert(4) sockets under FreeBSD.

……………..

-port | -p port
Read from and write to divert(4) port port

По умолчанию natd «слушает» сокет 8668, если он у вас вдруг уже занят, то в примере я буду запускать на 8670. Итак запустим сам natd:

natd -p 8670 -s -m -a 8.8.8.8 -redirect_port tcp 10.0.2.18:80 8080

Теперь надо завернуть, только нужный нам трафик, в divert socket, для этого добавим правила ipfw:

ipfw add 700 divert 8670 tcp from any to 8.8.8.8 8080
ipfw add 710 divert 8670 tcp from 10.0.2.18 80 to any

Будьте внимательными с номерами правил, не забывайте о том, что ipfw идет по номерам сверху вниз и ищет более точное совпадение и если выше этих правил будут стоять правила с лучшим совпадением, то трафик до этих правил не дойдет.

Не лишним будет добавить разрешающие правила, например если у вас firewall закрытого типа:

ipfw add 720 allow  tcp from any to 10.0.2.18 80
ipfw add 730 allow  tcp from 10.0.2.18 80 to any

Ну собственно на этом все.

Теперь можно убедиться что все работает зайдя браузером по линку: http://8.8.8.8:8080 и глянув в tcpdump на внутреннем интерфейсе:

tcpdump -ni em1 host 10.0.2.18

Где должны быть видны запросы извне и ответы от 10.0.2.18.

Если у вас возникнут проблемы, то траблшутинг начните с просмотра tcpdump, добавлением ключа -v к запуску natd, добавив слово log в добавленные правила ipfw.

Эти действия помогут вам разобраться и найти причину проблемы.

Но вернемся к первоначальному вопросу. Теперь схема выглядит так:

Интернет <==> (<— default GW) [8.8.8.8] Сервер с реальником [10.0.2.2/24]<===> [10.0.2.18/24] Железка с внутренним адресом

и вариант описанный выше уже не работает. Почему ?

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

Считаем что мы извне обращаемся с адреса 1.1.1.1 и в tcpdump`е будет примерно следущее:

10:20:49.689619 IP 1.1.1.1.52583 > 10.0.2.18.80: S 426822729:426822729(0) win 65535
10:20:49.694417 IP 1.1.1.1.52583 > 10.0.2.18.80: . ack 1 win 260
10:20:49.694750 IP 1.1.1.1.52583 > 10.0.2.18.80: P 1:241(240) ack 1 win 260

Т.е. запросы извне к железке мы видим, но ни одного ответа от неё нет. Почему ? А вы ещё не забыли, что у 10.0.2.18 нет default gateway ? Вот потому и не отвечает, т.к. не знает куда ответить.

Что с этим делать ? Да как обычно 🙂 Решать проблему.

Для этого нам понадобится ещё один natd. Что он будет делать ? А он будет подменять SRC адрес «вопрощающего» (1.1.1.1) на свой внутренний адрес (10.0.2.2). Таким образом мы решим проблему того что на железке нет default gateway, т.к. отвечать она уже будет в свою подсеть.

Запустим второй процесс natd:

natd -s -m -a 10.0.2.2 -p 8671

Снова завернем трафик, добавим правила ipfw к уже добавленным выше:

ipfw add 705 divert 8671 tcp from any to 10.0.2.18 dst-port 80
ipfw add 706 divert 8671 tcp from 10.0.2.18 80 to 10.0.2.2

Как и в предыдущем случае обращаем внимание на номера правил ipfw.

Снова идем по линку http://8.8.8.8:8080 и смотрим в tcpdump, видим там уже другую картину:

10:43:48.573232 IP 10.0.2.2.53368 > 10.0.2.18.80: . ack 1 win 260
10:43:48.573577 IP 10.0.2.2.53368 > 10.0.2.18.80: P 1:241(240) ack 1 win 260
10:43:48.573967 IP 10.0.2.18.80 > 10.0.2.2.53368: . ack 241 win 32647
10:43:48.606660 IP 10.0.2.18.80 > 10.0.2.2.53368: P 1:92(91) ack 241 win 32647
10:43:48.656346 IP 10.0.2.18.80 > 10.0.2.2.53368: FP 92:457(365) ack 241 win 32647
10:43:48.660740 IP 10.0.2.2.53368 > 10.0.2.18.80: . ack 458 win 258
10:43:50.656411 IP 10.0.2.18.80 > 10.0.2.2.53368: R 1003605212:1003605212(0) win 0

Видим что SRC адрес изменился с 1.1.1.1 на 10.0.2.2, что нам и надо было и сразу же пошли ответы на запросы, что означает что линк открылся и в нем отобразился веб-интерфейс железки с внутренним адресом 10.0.2.18.

З.Ы. Не забываем убедиться, что переменная:

sysctl net.inet.ip.forwarding

выставлена в единицу:

net.inet.ip.forwarding: 1

З.Ы.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Поводом для написания этой статьи послужила задача, которая возникла перед нами вчера.

Задача звучала просто: необходимо установить LG (Looking Glass) для отображения информации с BGP роутера FreeBSD с установленной quagga.

Что такое LG ?

Looking Glass позволяет выполнить на BGP роутере команды и отобразить результат их выполнения в web-интерфейсе:

• show ip bgp
• show ip bgp neighbors advertised-routes
• show ip bgp summary
• ping
• traceroute

Для получения данных с роутера LG может использовать протоколы:  SSH, telnet или rsh.

Мы пользуемся telnet`ом.

LG мы всегда использовали один. Это разработка Cougar официальный сайт www.version6.net.

Данный LG написан на языке программирования PERL и является CGI скриптом. Для соединения использует PERL модуль  Net::Telnet (/usr/ports/net/p5-Net-Telnet)

Последняя версия LG, доступная на это момент, датируется 25.11.2004 года и имеет номер 1.9.

Скачать исходный код можно на официальном сайте http://www.version6.net/lg/lg-1.9.tar.bz2 или с нашего сайта http://subnets.ru/files/lg-1.9.tar.bz2.

Ранее мы использовали этот LG для получения инфы с Juniper, а тут понадобилось получить с quagga (демон bgpd).

Установили LG, зашли в web-интерфейс LG и ….. и нифига. По нажатию на кнопку «Submit» LG просто долго «думает» (подвисает), а затем выдает страницу с запрошенной командой и пустым результатом.

Пара слов об установке.

В README автор достаточно четко описал что надо делать, повторяться мы не будем, но позволим себе добавить кусок конфига для HTTP сервера apache:

<VirtualHost XXX.XXX.XXX.XXX:80>
    ServerAdmin mymail@mydomain.ru
    DocumentRoot /usr/local/www/lg
    ServerName lg.subnets.ru

    ScriptAlias / /usr/local/www/lg/cgi/lg.cgi

    ErrorLog /var/log/http/lg_error.log
    CustomLog /var/log/http/lg_access.log common

    <Directory "/usr/local/www/lg">
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
    </Directory>
</VirtualHost>

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

Остро встал вопрос о debug`е действий LG, но разработчик не предусмотрел такой возможности 🙁  В логах появляется лишь строчка с запросом и ничего больше….

Пришлось лезть в исходки. В результате изысканий стало понятно, что проблема возникает уже после установки telnet соединения  между LG и quagga (демоном bgpd).

Это удалось понять используя более детальное логирование действий LG и просмотра вывода tcpdump:

tcpdump -Xni lo0 port 2605

Слушали ифейс lo0 (loopback) т.к. LG и quagga находтся на одном сервере и bgpd запущен командой:

/usr/local/sbin/bgpd -d -A 127.0.0.1

Возникает она потому что скрипт не может заматчить «command prompt», иными словами строку приглашения.

Что делать ? Разбираться с этим дальше уже нет времени, т.к. на выяснение проблемы уже убили кучу времени.

Тут я вспомнил про порт p5-Net-Telnet-Cisco (/usr/ports/net-mgmt/p5-Telnet-Cisco).  Примеры  использовании этого порта я показывал в статье Backup конфига Cisco на FTP.

Решил по быстрому попробовать такой вариант подключения по telnet к quagga. Сказано — сделано. Установил  порт p5-Net-Telnet-Cisco, поправил исходный код lg.cgi и все заработало.

Думаю что мы не единственные кто сталкивался/столкнулся/столкнется :))) с этой проблемой, надеюсь эта статья вам поможет.

Модифицированный нами код можно скачать тут: http://subnets.ru/files/lg-1.9.1.tar.gz
В архиве присутствуют файлы:

• lg-1.9_ORIGINAL.tar.gz — это оригинальный архив от автора LG
• lg.cgi.diff — это DIFF файл между оригинальной версией и модифицированной

Уточню, что код модифировался только в части отвечающий за подключение по telnet`у к quagga, остальной код остался без изменений.

Списки Looking Glass в Инете:

• http://www.bgp4.net/wiki/doku.php?id=tools:ipv4_looking_glasses
• http://subnets.ru/wrapper.php?p=1
• http://traceroute.net.ru/
• http://www.traceroute.org/

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Пожалуйста, уважайте чужой труд.

Авторы: Панфилов Алексей (lehis (at) subnets.ru) и Николаев Дмитрий (virus (at) subnets.ru)