Буквально на днях получил подарочек из AdSense, который все боялся обналичивать ибо акк был зареган не на меня, а на моего дядьку, которого надо было напрягать идти с паспортом на почту и прочая и прочая. И тут как гром среди ясного неба- Google начал выводить через рапиду на все многообразие платежных систем!!! А я буквально с начала года пытался зарегаться под разными американскими именами, чтобы выводить через ecoin, но гугль каждый раз меня банил как проказничающего мальчонку, так что раз на пятый я вообще разочаровался в жизни.
Так что попробовал не особо веря что получится и в итоге пришло письмо от гугля что бабки ушли, через два дня капнули на вебманю, так что теперь рассказываю что и куда.
Для начала идем и регаемся на сайте рапиды- для регистрации указывается мобильник, который необходимо иметь под рукой, так как он будет основным способом связи с вами от сервиса. Имя необходимо зарегать то же самое, что у вас зарегано и в самой системе Google Adsense, тем более что если платеж не пройдет на электронный счет, то башли уйдут обычным путем.
После того как все прошло успешно и вам вылали первый PIN- не выбрасывайте его, ибо он и будет служить паролем для вашего входа на сайт, где в качестве логина используется номер мобильного, без цифры 8. Заходим в личный кабинет, с использованием приведенных ранее параметров, и далее идем создавать шаблон для вывода бабосов: верхнее меню ПЛАТЕЖИ -> левый сайдбар СОЗДАНИЕ ШАБЛОНА -> Платежные системы -> Webmoney
Тут заполняем всю инфу и надо отметить что в поле Размер суммы- сумма больше 15к рублей не пролезает, но это скорее фикция, поскольку служит гарантом того, что вы не закажите вывод 15 лямов, которых у системы в данный момент нет- мне пришла сумма гораздо больше указанной по шаблону, но тем не менее она мне упала полностью. Сохраняем щаблон и запоминаем номер, поскольку он нам пригодится при заполнении формы на Google.
Все- теперь идет в Google Adsense – в настройки платежей, и заполняем инфу для вывода: вкладка Мой Аккаунт -> поле Назначение платежа -> раздел Назначение платежа -> кнопка Настройка Rapida -> где все заполняем теми же именами и фамилиями что и в Рапиде, после чего пишем адрес куда доставлять и (ВНИМАНИЕ!!!) в поле Номер шаблона в “Рапиде” прописываем именно тот уникальный номер, что был присвоен нашему шаблону (чтобы обновить в памяти, проходим в Рапиде по следующему пути: Рапида -> Личный кабинет -> Платежи -> Шаблоны и срисовываем поле Уникальный №. Как пишут люди- если в поле Номер шаблона в “Рапиде” , то бабки просто капнут на аккаунт в Рапиде и вы сможете сами распоряжаться своими бабками как пожелаете- благо там есть все, от вывода бабосов на карту, до коммунальных платежей, но меня история с вебманями устраивает более всего.
В процессе войны с поганейшим агрегатом из всех что мне доводилось встречать, под названием 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
По версии D-Link на этой торжественной ноте можно говорить: Configuration -> Save and Activate, но у меня после этого канал поднимался где то на полторы минуты, после чего соединение висло, а рутер говорил что он был перезапущен из-за ошибки: “Could not establish bi-directional communication after configuration upload”. Зная как работает D-Link, я пришел к тому, что второе правило, которое гарантирует прохождение пакета- не отрабатывает тот самый пресловутый bi-directional , который D-Link обещает всем выбравшим в действии правила Allow, для того чтобы не создавать два правила туда и назад. Но це оказалась не фича, а бага, поэтому я добавил третье правило:
После этого коннект поднялся нормально, даже не смотря на ту же самую ошибку, которая так и осталась висеть в причине перезапуска, но уже не мешала стабильности соединения.
Возникла задача построить беспроводную сетку 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. Криво в теории, но на практике работает пока нормально- продолжаю искать причину не понятного глюка.
Там же тогда же. Собственно с чего начал ковырять свичик 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
После выполнения этих команд перезагрузка свича не требуется.
Вчера ковырялся со свичами HP ProCurve и возникла необходимость задать время ручками, поскольку с NTP сервера свич забирать данные по каким то причинам отказывался. Делается это следующим образом, подключаемся к свичу по telnet или через X-modem и в консоли задаем следующие команды:
switch# config
switch(config)# clock set MM/DD/YYYY HH:MM:SS
switch(config)# wr mem
Вторую неделю воюю с замечательным провайдером Горком на предмет поддержки ими зоны обратного просмотра, она же реверсивная зона. Точнее внесения в неё моего MX сервера, поскольку при отправке почты на удаленные сервера, многие почтари проверяют наличие у сайта PTR записи как таковой и в случае её отсутствия, расценивают отправителя как спамера. Хитрованы же из Горкома убеждают меня в том, что это должен делать я сам и вообще письма от меня не доходят вовсе не из-за реверса упоминаемого в коде ошибки, а потому что у меня дескать не правильно настроен ns сервер.
Разработка, появившегося с год назад, было спонсировано исследовательским центром армии США и стало результатом исследований, в области информационной безопасности, организации SRI International. Как становится понятно уже из названия приложение предназначено для поиска ботов и вредоносных программ ставящих под угрозу компьютерную безопасность. Приложение BotHunter разработано для прослушивания сетевого диалога между внутренними и внешними сегментами сетей. BotHunter состоит из коррелирующего движка написанного на базе Snort 2, который отслеживает подозрительную сетевую активность: сканирование портов, использование эксплоитов, подготовки атак, p2p трафик. Коррелятор BotHunter сопоставляет информацию о входящих алертах и исходящей активности, на основе чего делает заключение о зараженности хоста. Если уровень вероятности заражения хоста, с точки зрения сетевого диалога BotHunter, приближается к критической точке, то программа начинает прослушивать и регистрировать все подобные события вычисляя их значение в процессе заражения.
Приложение доступно для FreeBSD (тестировано для 7.2 версии), Linux (тестировано для RHEL, SuSe, Debian и Fedore), Windows XP/Vista/2003,а также для Mac OS X (10.4 и 10.5).
