Рубрика «Сети»
Thursday, 18 Aug 2011
Возникла какое то время назад у меня задача прикупить себе мобильный 3G интернет, поскольку я одно время много мотался, да и к тому же хотелось оставаться все время на связи, сидючи на даче, и при этом не платить безумные башли за использование мобилки, ибо заход со своего МТС в интернет мне обходился в среднем в 200-300 рублей, а с Мегафона около 100. К тому же буквально следом за этой идей, ко мне примотался клиент, которому я настраивал под ключ офис, с тем что его ломает платить 15к рублей в месяц за выделенку Билайна, для того чтобы 3 сотрудника могли пользоваться Интернетом, и хотелось бы найти какой нить приемлемый вариант мобильного интернета (хоть 3G, хоть GPRS). В связи с чем я рассматривал несколько вариантов- во сколько обойдется комплект 3G интернета в офисе- если брать 3G рутер с каким-нибудь планом, или же покупка отдельных модемов для каждого сотрудника, для того чтобы они могли пользоваться внутри офиса и в разъездах. Так что вооружившись бродилкой, я засел за изучение предложений по рынку (сразу оговорюсь, что все описанное подходит для московского региона).
(more…)
VN:F [1.9.13_1145]
Rating: 9.0/10 (4 votes cast)
VN:F [1.9.13_1145]
Rating: +2 (from 2 votes)
Рубрика: Интернет, Сети | Ваш отзыв »
Monday, 15 Aug 2011
Наверное каждый владелец нескольких мобильных телефонов сталкивался с проблемой того, что не мог вспомнить номер своего телефона. Обычно такое лечится звонком на телефон с определителем, вроде бы сейчас практически все номера определяют номер по умолчанию.
Но в эти выходные столкнулся с тем, что у клиента уволилось несколько человек, которые и унесли с собой данные о номере рекламного телефона. Вся загвоздка этого номера была в том, что он был заблокирован для исходящих звонков и работал только на прием, ну а доки от сим-карты естественно были потеряны за ненадобностью еще в прошлой жизни.
Так что встала задача определить его номер на основе сервисных USSD запросов оператора. Что и было сделано, но заодно и разжился запросами всех остальных основных операторов. Надо отметить что все USSD запросы идут в форме диалога, так что после набора комбинации нажимаем вызов, а дале придется несколько раз пересылать различные циферки, следуя ответам оператора.
Для Мегафона:
*151#
Такчже если звонки разрешены, можно набрать в суппорт оператора: 0500.
Для МТС:
*123#
Также можно позвонить в службу поддержки МТС: 0887.
Для Билайн:
*110#
Опять же можно отзвонить в поддержку оператора, по номеру: 0611.
VN:F [1.9.13_1145]
Rating: 7.5/10 (4 votes cast)
VN:F [1.9.13_1145]
Rating: +2 (from 2 votes)
Рубрика: Сети | Ваш отзыв »
Saturday, 16 Jul 2011
Вернулся во втором часу ночи от клиента, который вдруг захотел перенести в одном из офисов свичи, лежавшие на шкафу купе, в человеческий настенный шкаф, про который я толковал еще пол года назад, в наше первое знакомство.
В итоге думали с админом клиента все быстренько расшить за вечер, и в итоге семь часов просто распутывали гордиев узел, который умело сплели очередные студиозы, кидающие сетку за сто баксов- естественно без разводки, естественно без принципиальной схемы, естественно с десятком выходов и хитросплетением свичей, ибо как обычно розеток не хватило на всех. В связи с чем вспомнил несколько историй когда клиент отказывался от моих услуг в плане разводки кабельной системы и построения человеческой СКС, так что когда люди снова обращались с просьбой помочь в том, что сетка стояла колом я обнаруживал каскадирование из 8ми портовых свичеков китайского производства, или же кабельную систему расшитую по два джека на витую пару.
В связи с чем родилось несколько моментов, которые я хотел бы скорее привести для заказчика, нежели для исполнителя, так объяснять халтурщику, что он лепит горбатого бессмысленно. В данный момент хотя мозги и поставлены кальяном на место, после прозвона 60+ розеток, но в голове тем не менее легкий сумбур, так что возможно что данную статью я буду дополнять.
(more…)
VN:F [1.9.13_1145]
Rating: 10.0/10 (3 votes cast)
VN:F [1.9.13_1145]
Rating: +3 (from 3 votes)
Рубрика: Сети | Ваш отзыв »
Friday, 24 Jun 2011
Скажу откровенно- вопрос маршрутизации в Windows Server я для себя закрыл еще в далеком 200X году, когда некие умельцы в том филиале Ростелекома, где я работал на тот момент, пытались поднять программный маршрутизатор на платформе Server 2003 и скажу откровенно это выглядело уныло, так как у них постоянно падали сетки, отваливались маршруты, пакеты переставали ходить и прочее. Учитывая, что как раз в то же время я совокупил порядка 6 сеток за счет бездисковой станции, которая грузилась с дискетки Coyot Linux и шуршала только в путь, то в дальнейшем я использовал исключительно маршрутизацию на базе FreeBSD. Но тем не менее эпизодически возникает необходимость организации маршрутизации на базе Windows Server, с наиболее упертыми клиентами которые сами ничего делать не хотят, но и лезут с советами.
Тогда приходится влезать в это болото, которое называется маршрутизация средствами Windows платформ. Для начала посмотрим что у нас прописано в таблице маршрутизации на сервере. Входим в терминальную консоль cmd и даем команду:
> route PRINT
которая нам высветит список имеющихся в системе интерфейсов, таблицу маршрутизации и постоянные маршруты. Кстати точно эту же картинку можно получить и командой:
> netstat -rn
Теперь собственно мы можем добавить статический маршрут, средствами командной строки. Предположим что нам надо срутить пакеты в сеть 172.16.0.0/24 через внутренний маршрутизатор 192.168.10.250, для чего задаем следующую команду:
> route add 172.16.0.0 mask 255.255.255.0 192.168.10.250 if 1
на самом деле можно со спокойной совестью опустить, маршрут подцепится и без этого, просто пакеты будут рутиться через внутренний интерфейс 127.0.0.1. Для того чтобы удалить данный маршрут достаточно сказать:
> route delete 172.16.0.0
При добавлении машртура мы можем получить загадошное сервисное сообщение “Запрошенная операция требует повышения”, для чего правой клавишей шелкаем в иконку командной строки и говорим “запуск от имени администратора”.
Но вся беда с том, что такие маршруты живут до следующей перезагрузки, поэтому нам необходимо сказать чтобы маршруты сохранялись на потсоянной основе, для чего задаем ключик -p:
> route -p add 172.16.0.0 mask 255.255.255.0 192.168.10.250
Собственно для меня это наиболее удобный вариант, так как не требует ковыряния с системе, да и подходит как для Windows Server, так и для простых рабочих станций под управлением виндусни; но особо беспокойные умы могут воспользоваться на MS Server службой Network Policy and Access Services, для чего идем в Диспетчер сервера -> Роли -> Добавить роли -> Службы политики сети и доступа -> Маршрутизация (автоматом добавится Служба удаленного доступа) после чего уже в оснастке управления маршрутизации через правый клик на имени сервера включаем машрутизацию и, зайдя в раздел Статические маршруты прописываем необходимые нам маршруты. Там же можно настроить и политики прохождения пакетов (вкладка Основное, свойства интерфейсов), а также динамическую маршрутизацию, путем добавления RIP или IGMP протоколов.
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Рубрика: Windows, Сети | Отзывов: 2 »
Friday, 10 Jun 2011
В связи с появившимся в обилии свободным временем могу подтянуть все свои стародавние статейки относительно различных фрёвых сервисов, которые уже лет 6-7 валялись у меня на диске в ожидании когда же до них наконец то дойдут руки, и вот потихоньку это время настало.
Так что не боясь предстать капитаном очевидность в этот раз я распишу как организовать программный маршрутизатор средствами FreeBSD. И хотя писалось все это еще под 4.2, но тем не менее и под 7.4 все эти же рецепты применимы, разве только с той разницей, что все пакеты отличаются версиями с большую сторону. Сказать откровенно, я предпочитаю программные маршрутизаторы за их дешевизну, простоту и быстроту в настройке, поскольку для программного маршрутизатора сгодится любая древняя машинка, главное чтобы в ней была возможность поставить дополнительные сетевухи. При этом программный маршрутизатор отличается от аппаратных аналогов тем, что произведя один раз настройку маршрутизатора вы следующий настроите уже за полчаса, а не будите копаться в мануалах нового для вас агрегата, купленного клиентом с оказией, не понимая почему це фича вдруг оказалась багой. К тому же вменяемый аппаратный маршрутизатор стоит не малых денег и вполне сопоставим по стоимости с хорошим компом, который помимо того что будет с сотни раз мощнее, также при этом сможет, естественно при желании, стать принт-сервером, фаерволом, проксей, поточным антивирем и еще чем угодно, и что самое основное- это решение маштабируемое, то есть добавление нового интерфейса сопряжено с гораздо меньшими затратами, нежели при попытке расширения аппаратного маршрутизатора, главное подобрать материнку с 2-3 слотами под сетевуху, ибо найти две интегрированные не проблема. И естественно формула скорость работы/цена для программного маршрутизатора будет на порядки ниже аппаратного, так как стоимость гигабитного маршрутизатора уже будет сопоставима с покупкой мощного сервера для офиса. Ну это просто вода относительно того за что я люблю программные рутеры, а теперь собственно перейдем к самой настройке маршрутизатора.
(more…)
VN:F [1.9.13_1145]
Rating: 10.0/10 (2 votes cast)
VN:F [1.9.13_1145]
Рубрика: FreeBSD, Сети | Отзывов: 2 »
Friday, 15 Apr 2011
Как я у же отметил ранее, в процессе знакомства с новой, для меня, платформой 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 клиент, не требующий уже никаких вводов логина и дополнительных настроек.
VN:F [1.9.13_1145]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.13_1145]
Рубрика: IT безопасность, Сети | Ваш отзыв »
Monday, 11 Apr 2011
Забавная тут ситуевина приключилась с одним сервисом, который я настраивал для клиента. Поднимал 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, например, таких проблем замечено не было.
VN:F [1.9.13_1145]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.13_1145]
Рубрика: IT безопасность, Сети | Ваш отзыв »