Одминский блог

Как настроить машрутизатор средствами FreeBSD

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

Так что не боясь предстать капитаном очевидность в этот раз я распишу как организовать программный маршрутизатор средствами FreeBSD. И хотя писалось все это еще под 4.2, но тем не менее и под 7.4 все эти же рецепты применимы, разве только с той разницей, что все пакеты отличаются версиями с большую сторону. Сказать откровенно, я предпочитаю программные маршрутизаторы за их дешевизну, простоту и быстроту в настройке, поскольку для программного маршрутизатора сгодится любая древняя машинка, главное чтобы в ней была возможность поставить дополнительные сетевухи. При этом программный маршрутизатор отличается от аппаратных аналогов тем, что произведя один раз настройку маршрутизатора вы следующий настроите уже за полчаса, а не будите копаться в мануалах нового для вас агрегата, купленного клиентом с оказией, не понимая почему це фича вдруг оказалась багой. К тому же вменяемый аппаратный маршрутизатор стоит не малых денег и вполне сопоставим по стоимости с хорошим компом, который помимо того что будет с сотни раз мощнее, также при этом сможет, естественно при желании, стать принт-сервером, фаерволом, проксей, поточным антивирем и еще чем угодно, и что самое основное- это решение маштабируемое, то есть добавление нового интерфейса сопряжено с гораздо меньшими затратами, нежели при попытке расширения аппаратного маршрутизатора, главное подобрать материнку с 2-3 слотами под сетевуху, ибо найти две интегрированные не проблема. И естественно формула скорость работы/цена для программного маршрутизатора будет на порядки ниже аппаратного, так как стоимость гигабитного маршрутизатора уже будет сопоставима с покупкой мощного сервера для офиса. Ну это просто вода относительно того за что я люблю программные рутеры, а теперь собственно перейдем к самой настройке маршрутизатора.

(more…)

Рубрика: FreeBSD, Сети | Отзывов: 11 »

Untangle Re-Routing: це не бага, це фича

Как я у же отметил ранее, в процессе знакомства с новой, для меня, платформой Untangle я натолкнулся на довольно странное поведение. Начал я с того, что закачав образ на удаленный сервер ESXi, решил спокойно ночью поднять VPN сервер, чтобы утром уже логиниться не через rdp, а через IPSec. Подтянул образ, залил его в инвентори, начал установку.  Все поставилось прекрасно, но как только я настроил сетку на одном из интерфейсов- у меня все упало, т.е. соединение отвалилось без возможности восстановления таким образом, будто упала сеть. Имея все таки некоторое представление о работе шлюзов и фаервольных решений, я прикинул, что отвалиться ESXi уж не мог точно, ибо в любом случае новый шлюз мог бы залочить только свой виртуальный интерфейс, а не доступ во внутреннюю сетку, так что с утра я начал исходить из того, что сработал закон Мерфи, который мне в процессе многочисленных настроек неоднократно напоминал о своей существовании, когда ты нажимаешь на кнопку сохранить, а во всем офисе рубится свет;  и у меня в момент настройки Untangle порушилась сеть.

В итоге ребутнули сервак ESXi, все поднялось, так что вечером я выехал на удаленную площадку. Прибыв на место, немного пошакалил по свичам, ибо решил было, что проблема крылась в них, но все было вроде нормально, так что я приступил снова к настройке Untangle. Надо отметить, что я, как истинный российский одмин, хотя и веселюсь на эту тему, некоторое время уже как читаю мануал только после того как все сломалось, так что в данном случае я полагал, что официального wiki how-to-install untangle вполне достаточно для того чтобы поставить платформу. Стартанул сервак на ESXi, и как только, судя по процентным соотношениям загрузки, платформа запустила сетевые интерфейсы у меня снова полегла сеть. Это меня подвигло в совершеннейшие не понятки, поскольку сеть лежала наглухо- то есть она отсутствовала как класс- пинги не проходили даже до свича, в который была воткнута машина, не говоря уже про какие то шлюзы и сервера, сидевшие на соседях по каскаду. Рубанув сервер, снова поднял ESXi и удалил с него Untangle, решив поднять его в тестовом варианте у себя на машине. В итоге на след. день, подняв его в оболочке VMware Workstation я так же радостно положил сетку своего офиса, но поскольку доступ к виртуальной среде у меня уже был не по сети, то отрубив интерфейсы на виртуально машине, я полез в инет с извечным вопросом “whatafuck?”.

Оказалось, что в платформе Untangle реализована технология Re-Router (до этого мне с ней как то не доводилось встречаться), благодаря которой данная платформа безопасности  интегрируется в существующую сетевую топологию без каких либо дополнительных перенастроек инфраструктуры, путем заворачивания на себя всего трафика на уровне L2 протоколов. Примерно тоже самое происходит при уязвимости men-in-middle, когда машина внутри сетки производит так называемую атаку ARP spoofing, отвечая на все ARP broadcasts “ЭТО ЙА!” и тем самым беря на себя функционал центрального шлюза и вообще всех машин в сетке, так что в ARP таблице свичей все пакеты замыкаются на интерфейсе Untangle,и даже после падения платформы трафик не будет проходить до динамического изменения ARP таблицы.  Данная технология интегрирована в ядро, и в первом приближении не отключабельна, так что на форуме Untangle тамошние спецы рекомендуют относиться к ней как к данности, и в этой связи, в обязательном порядке, использовать на сервере два интерфейса, даже в случае необходимости использования одного- как в моем варианте VPN-сервера. Но в этом случае рабочий интерфейс надо делать внешним, а внутренний переводить в режим bridge и бриджевать его на внешний интерфейс
Настройка в админской части Untangle: Config -> Networking -> Internal Interface
Config Type: bridge
Bridge to: External (static)

Кстати таким же образом можно организовывать проброс трафика к внешнему шлюзу, но это уже другой разговор. В случае виртуальной машины, как у меня, я просто добавил в работающую конфигурацию еще один интерфейс, подтянул его встроенным detect’ом и привязал к внешнему интерфейсу, после чего лежащая сетка ожила в течении 30 секунд. Еще в течении 15 минут поднял VPN-сервер и настроил подключение. Самое приятное, что openVPN сервер сам генерит клиентскую часть, так что просто логинимся через бродилку к VPN-серверу, заходим внутрь и из настроек openVPN сервера, раздела Clients, говорим для определенного пользователя Distribute Client, после чего либо скачиваем его по приложенным ссылкам, либо отправляем его на email который можно вписать в форму отправки. Клиент после установки получает полностью настроенный OpenVPN клиент, не требующий уже никаких вводов логина и дополнительных настроек.

Рубрика: IT безопасность, Сети | Ваш отзыв »

VMware bridged mode vs kerio vpn client

Забавная тут ситуевина приключилась с одним сервисом, который я настраивал для клиента. Поднимал Help Desk- первоначально на своей машине в виртуальном окружении VMware Workstation, после чего установил на клиентскую машину VMware Player и перенес машину. Надо отметить что виртуальная машина крутится под Cent OS, а сервер под Win 2003, так что никаких особых проблем не ожидалось.

Но в процессе запуска- выяснилось что машинка не подхватывает IP адрес по DHCP, при работе в bridged mode, а при попытке задать статический IP я получал ругань на тему того, что данный IP уже используется, при том что данный адрес был однозначно свободен. Озадачившись данной проблемой проверил на всякий случай фаервол винды, но как оказалось он был отключен. Поковырявшись в меру возможностей в серваке и vmware, решил не озадачивать клиентского админа, а переставил Player на Workstation и попробовал поднять виртуалку в таком варианте. Но проблема осталась той же самой, при этом когда я переключил сетки в NAT вариант-  поднимался внутренний IP и все начинало нормально шуршать.

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

Рубрика: IT безопасность, Сети | Отзывов: 2 »

Вывод с Google Adsense на WebMoney

Буквально на днях получил подарочек из AdSense, который все боялся обналичивать ибо акк был зареган не на меня, а на моего дядьку, которого надо было напрягать идти с паспортом на почту и прочая и прочая. И тут как гром среди ясного неба- Google начал выводить через рапиду на все многообразие платежных систем!!! А я буквально с начала года пытался зарегаться под разными американскими именами, чтобы выводить через ecoin, но гугль каждый раз меня банил как проказничающего мальчонку, так что раз на пятый я вообще разочаровался в жизни.

Так что попробовал не особо веря что получится и в итоге пришло письмо от гугля что бабки ушли, через два дня капнули на вебманю, так что теперь рассказываю что и куда.
Для начала идем и регаемся на сайте рапиды- для регистрации указывается мобильник, который необходимо иметь под рукой, так как он будет основным способом связи с вами от сервиса. Имя необходимо зарегать то же самое, что у вас зарегано и в самой системе Google Adsense, тем более что если платеж не пройдет на электронный счет, то башли уйдут обычным путем.

После того как все прошло успешно и вам вылали первый PIN- не выбрасывайте его, ибо он и будет служить паролем для вашего входа на сайт, где в качестве логина используется номер мобильного, без цифры 8. Заходим в личный кабинет, с использованием приведенных ранее параметров, и далее идем создавать шаблон для вывода бабосов: верхнее меню ПЛАТЕЖИ -> левый сайдбар СОЗДАНИЕ ШАБЛОНА -> Платежные системы -> Webmoney

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

Все- теперь идет в Google Adsense – в настройки платежей, и заполняем инфу для вывода: вкладка Мой Аккаунт -> поле Назначение платежа -> раздел Назначение платежа ->  кнопка Настройка Rapida -> где все заполняем теми же именами и фамилиями что и в Рапиде, после чего пишем адрес куда доставлять и (ВНИМАНИЕ!!!) в поле Номер шаблона в “Рапиде” прописываем именно тот уникальный номер, что был присвоен нашему шаблону (чтобы обновить в памяти, проходим в Рапиде по следующему пути: Рапида -> Личный кабинет -> Платежи -> Шаблоны и срисовываем поле Уникальный №. Как пишут люди- если в поле Номер шаблона в “Рапиде” , то бабки просто капнут на аккаунт в Рапиде и вы сможете сами распоряжаться своими бабками как пожелаете- благо там есть все, от вывода бабосов на карту, до коммунальных платежей, но меня история с вебманями устраивает более всего.

Чего и вам желаю!

Рубрика: Интернет, Сети | Ваш отзыв »

Проброс портов на D-Link DFL-210

В процессе войны с поганейшим агрегатом из всех что мне доводилось встречать, под названием D-Link DFL-210, возникла необходимость попасть в сеть клиента, при том, что VPN я поднять на нем пока не смог, ибо соединение устанавливается, но как то не понятно реализована внутренняя маршрутизация, хотя я настраивал точно по имеющимся в инете ФАКам, и после установления соединения, пингуется только внутренний интерфейс. Но это тема для другого разговора, а пока я быстро решил поднять на коленке проброс RDP на внутренний хост, с тем чтобы быстро решить необходимую мне задачу.

На D-Link сайте нашел веселые картинки, показывающие как и что сделать, но поскольку мне их публиковать ломы. то распишу руками.
1. Логинимся на рутер
2. Создаем объект на который будем пробрасывать порты:
Objects -> Address Book -> InterfaceAddresses -> Add IP4 Address
Name: Имя-сервера
Address: IP-адресс сервера
3. Создаем правила проброса портов:
Rules -> IP Rules -> Add IP Rule Folder -> Входим в новую папку и Add IP Rule (две штуки)

3.1. Правило проброса:
Вкладка General:
Action: SAT
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip
Вкладка SAT:
Включаем кнопочка на Destination IP
New IP Address: Имя-сервера (из п.2)
New Port: 3389
Включаем чекбокс: All-to-One Mapping: rewrite all destination IPs to a single IP

3.2 Правило прохождения пакета:
Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): any/all-nets
Destination (interface/network): core/wan_ip

По версии D-Link на этой торжественной ноте можно говорить: Configuration -> Save and Activate, но у меня после этого канал поднимался где то на полторы минуты, после чего соединение висло, а рутер говорил что он был перезапущен из-за ошибки: “Could not establish bi-directional communication after configuration upload”. Зная как работает D-Link, я пришел к тому, что второе правило, которое гарантирует прохождение пакета- не отрабатывает тот самый пресловутый  bi-directional , который D-Link обещает всем выбравшим в действии правила Allow, для того чтобы не создавать два правила туда и назад. Но це оказалась не фича, а бага, поэтому я добавил третье правило:

Вкладка General:
Action: Allow
Service: rdp
Source (interface/network): wan/Имя-сервера (из п.2)
Destination (interface/network): any/all-nets

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

Рубрика: Сети | Отзывов: 20 »

Распределенная сеть Wi-Fi на рутерах Linksys WRT 160NL

Возникла задача построить беспроводную сетку Wi-Fi в нескольких крыльях офиса, но так что бы всюду рулила одна сеть с единым SSID. Скажу откровенно один раз я уже накололся с этим, когда попытался совокупить CheckPoint Edge и D-Link’овский рутер, как раз из-за того что каждый производитель использует для сопряжения AP в режиме bridge, repeater и WDS свои собственные фичи, так что если есть необходимость построения подобной схемы, то оборудование надо приобретать одного бренда.

Для этих целей мы закупили Wi-Fi рутеры Linksys WRT 160NL- совершенно новые модельки, которые гонятся уже под лейблом Cisco. Но к сожалению родная прошивка рутера не позволяет поднять подобный функционал, по этой самой причине пришлось обратиться к кастомной прошивке DD-WRT, которая базируясь на открытом коде Linux’ового ядра, значительно расширяет функционал обычных рутеров. Я уже имел некоторое количество экзерсисов с этой прошивкой, когда пытался подключить другу torrent клиента и монтирование NTFS’ных дисков на рутере, и если дойдут руки, то о результатах отпишусь позднее. А пока создаем распределенную беспроводную сеть на двух (можно и более) рутерах Linksys WRT 160NL.

Для начала качаем кастомную прошиву с сайта DD-WRT и перепрошиваем основной рутер. Условно назовем его MAIN-AP. Выбираем прошивку для своего рутера, на данный момент актуальная версия v24 SP2 (SVN revision 14896), скачиваем, после чего подключаемся к рутеру через LAN кабелюку и проходим: Administration ->
Дожидаемся завершения прогресса перепрошивки и заходим в консоль администратора. Вводим имя пользователя и новый пароль, после чего настраиваем рутер для работы в обычном режиме- задаем настройки внешней сетки, внутренней, DHCP сервера и Wi-Fi сети. Также необходимо отключить встроенный брандмауэр ибо он может помешать взаимодействию сетевых устройств.

После этого переходим к настройке вторичного рутера. Назовем его Bridge-AP. Для начала задаем ему внутреннюю сетку из того же пула, что и была задана для Main-AP, и отключаем внешний интерейс и DHCP сервер, ибо адреса у нас будет раздавать первичный AP: идем Setup -> Basic Setup и расставляем галочки следующим образом
Connection Type: Disabled
STP:  Disabled
DHCP Server: Disable

После каждого изменения того или иного поля не забываем сохранять введенные настройки, путем нажатия на Save Settings.

Далее переключаемся из режима шлюза в режим рутера: Setup -> Advanced Routing и в выпадающем меню ставим Router. Отрубаем также брандмауэр ибо он может мешать работе AP: во вкладке Security -> Firewall отключаем все галки кроме Filter Multicast, после чего отключаем SPI firewall переключая в статус Disable.

После этого переходим к настройке Wi-Fi:
Идем в основные настройки Wi-Fi: Wireless -> Basic Settings и выставляем следующие параметры
Wireless Mode : Client Bridge
Wireless Network Mode : аналогично настройкам MAIN-AP
Wireless Network Name(SSID) : аналогично настройкам MAIN-AP
Wireless Channel : аналогично настройкам MAIN-AP
Wireless SSID Broadcast : аналогично настройкам MAIN-AP
Network Configuration : Bridged

Переходим к разделу настройки безопасности Wi-FI: Wireless-> Wireless Security
Выставляем тип безопасности (WEP, WPA или WPA2-Personal) аналогично настройкам MAIN-AP, точно также задаем и алгоритм шифрования: TKIP, AES, или  TKIP + AES, после чего вводим фразу что мы использовали при настройке MAIN-AP.

Сохраняемся и говорим Administration -> APPLY Settings после чего выключаем рутер, относим его в другое помещение и подключаем его прямым кабелем из его LAN порта в LAN порт рутера MAIN-AP, после чего включаем. Вуаля- у нас в обоих помещениях теперь пашет один и тот же SSID, так что тыкая из одной части зала в другую мы даже можем не заметить, когда мы перейдем на другую AP.

*** Единственный косячный момент который я заметил при работе с DD-WRT именно на Linksys заключается в том, что работать надо в IE ибо в Firefix web-интерфейс почему то подглючивает с завидным постоянством.
Тип шифрования рекомендую выставлять mixed на обоих рутерах, ибо в этом случае скорость передачи данных выше.
Также у меня возникли проблемы с раздачей репитером wi-fi в случае если запрещено широковещательное объявление SSID, поэтому пришлось транслировать имячко сети в эфир.

Обновление от 11.02.2011:  очень странная тема, ибо это решение у меня прожило в районе суток, после чего вторичный рутер перестал раздавать wi-fi в принципе, так что перепробовав 4 возможных прошивки, и перенастроив все решение раз 50, остановился на том, что у меня оба устройства работают в режиме AP. Криво в теории, но на практике работает пока нормально- продолжаю искать причину не понятного глюка.

Рубрика: Сети | Отзывов: 6 »

Ошибка HP ProCurve: port XX is Blocked by LACP

Там же тогда же. Собственно с чего начал ковырять свичик HP ProCurve: поступили жалобы на то, что криво работают после перезагрузки по броску питания. Вроде как отваливается сетка и что то тупит. В логах довольно интересные сообщения:
01/03/10 20:02:47 ports: port 39 is now off-line
01/03/10 20:02:49 ports: port 39 is Blocked by LACP
01/03/10 20:02:52 ports: port 39 is now on-line
01/03/10 20:04:28 ports: port 39 is now off-line

Это говорит нам о том, что функционал LACP отрубает порты. Сам LACP (Link Aggregation Control Protocol) это протокол обеспечивающий работу транка, то есть объединение нескольких каналов в один для увеличения пропускной способности. Агрегированные каналы LACP используют для повышения пропускной способности канала и для и повышения отказоустойчивости.
Смотрим статистику конфигурации самого LACP

Chife-0# show lacp
LACP

ORT LACP TRUNK PORT LACP LACP
NUMB ENABLED GROUP STATUS PARTNER STATUS
……………..
35 Passive 35 Down No Success
36 Passive 36 Up No Success
37 Passive 37 Down No Success
38 Passive 38 Up No Success
39 Passive 39 Up No Success

LACP исходя из статистики пребывает в passive режиме, но при этом блокирует порты. Происходит это из-за того, что когда порт поднимает линк, passive LACP запрещает его использование до тех пор пока соединение не стабилизируется и не выяснится что это активное соединение. Если утверждение верно, то создается транк, если нет, то порт освобождается.

Для решения данной проблемы есть несколько ступенчатых вариантов разрешения проблемы:
1. Обновить версию прошивки свича до последней стабильной версии.
2. Проверить чтобы на обоих окончаниях сетевого кабеля выставлена одна и та же скорость и нет конфликтов: то есть с обоих сторон должна стоять или Auto-Auto или 100FDx -100FDx, но никак не Auto-100FDx
3. Если все вышесказанное не помогло, то можно отключить LACP если мы не используем его функционал для создании транка. При отключении данного функционала ничего не теряется ибо остается еще два варианта создания транков: HP port trunking (который использую я) и FEC.
Для этого опять же заходим в консоль и далее даем команды:
Chife-0# con t
Chife-0(config)# int all
Chife-0(eth-1-48,Trk1)# no lacp
Chife-0(eth-1-48,Trk1)# write mem

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

Рубрика: Оборудование, Подсказки, Сети | Отзывов: 2 »