Утилита находится в дебрях фреймворка Apple80211:

/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport

Для упрощения работы можно сделать алиас:

$ vim ~/.bash_profile
alias ap='/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport'

Сканирование сетей:

$ /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -s
SSID    BSSID             RSSI CHANNEL HT CC SECURITY (auth/unicast/group)
XXXXXXX 00:00:00:00:00:a6  -65       2  N IL WPA(PSK/AES,TKIP/TKIP) WPA2(PSK/AES,TKIP/TKIP)
YYYYYYY 00:00:00:00:00:ab  -34       7  Y AT WPA2(PSK/AES/AES)

• SSID – service set identifier. Имя, которое идентифицирует беспроводную сеть
• BSSID – basic service set identifier. В большинстве случаев это идентификатор Access Point и является её MAC-адресом
• RSSI – Received signal strength indication. Мощность сигнала. Чем больше значение, тем сигнал мощнее (в примере сигнал сети YYYYYYY сильнее XXXXXXX).
• CHANNEL – канал, на котором работает сеть. Для информации – в 802.11g есть всего три неинтерферирующих канала, поэтому если вокруг много активно работающих сетей, то будет наблюдаться снижение скорости и сбои в работе.
• HT – я так и не нашёл, что это такое.
• CC – страна, определяет частотный диапазон и конфигурируется для Access Point. IL – Израиль, AT – Австрия.
• SECURITY (auth/unicast/group) – технология защиты, обмен ключами, шифрование.

Информация по текущей сети:

$ /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -I
     agrCtlRSSI: -37
     agrExtRSSI: 0
    agrCtlNoise: -89
    agrExtNoise: 0
          state: running
        op mode: station
     lastTxRate: 145
        maxRate: 144
lastAssocStatus: 0
    802.11 auth: open
      link auth: wpa2-psk
          BSSID: 00:00:00:00:00:ab
           SSID: XXXXXXXXXXXX
            MCS: 15
        channel: 7

Почти все параметры говорят сами за себя (кроме lastTxRate и maxRate, которые я не могу объяснить внятно). Меня интересуют два параметра:

• agrCtlRSSI – мощность сигнала, чем выше, тем лучше
• agrCtlNoise – шум, чем меньше, тем лучше

Отключение от сети

$ sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport -z

Учитывая достаточно активное потребление трафика на iPhone, я решил посмотреть, с какими сервисами он взаимодействует.

Задумано-сделано. Вариантов захватить трафик через GPRS у меня, конечно же, нет, поэтому я упростил себе задачу, отключив Cellular Data (iOS 4) и дав iPhone соединяться с Интернет только через WiFi. Внешний интерфейс WiFi-точки я подключил к компьютеру под Ubuntu через который дальше обеспечивается доступ в Интернет.

Для дальнейшего упрощения задачи я решил не анализировать детально трафик, а ограничиться просмотром хостов, к которым iPhone обращается. Тяжело найти человека, который в здравом уме в сетевых приложениях будет использовать обращение по IP-адресам, а не по именам (предполагаем, например, смену хостинговой компании или географическую балансировку нагрузки), поэтому для анализа достаточно посмотреть запросы/ответы DNS.

Я собрал данные используя tshark за полтора часа работы iPhone после его перезагрузки и нахождении его в заблокированном состоянии. Включены сервисы: Mobile Me (все – почта, календарь, адресная книга, Find My iPhone), Google Mail Exchange (только почта).

  2  15.647539 DNS Standard query A aosnotify.mac.com
  3  15.651564 DNS Standard query AAAA aosnotify.mac.com
  4  15.672783 DNS Standard query response A 17.250.248.82

Доступ к Apple Online Service (MobileMe) для календарей/контактов/etc

 23  17.275523 DNS Standard query TXT push.apple.com
 28  17.301644 DNS Standard query response TXT ("count=50")

Регистрация для получения push-нотификаций.

 26  17.289761 DNS Standard query TXT sandbox.push.apple.com
 29  17.315179 DNS Standard query response TXT ("count=10")

Скорее всего регистрация на sandbox для разработчиков (у меня на iPhone установлен девелоперский профиль)

 30  17.367851 DNS Standard query A 38-courier.push.apple.com
 31  17.375139 DNS Standard query AAAA 38-courier.push.apple.com
 33  17.394461 DNS Standard query response CNAME 38.courier-push-apple.com.akadns.net A 17.149.36.73 A 17.149.36.97 A 17.149.36.226 A 17.149.37.44 A 17.149.36.115 A 17.149.36.174 A 17.149.36.86 A 17.149.36.65
 32  17.387095 DNS Standard query A 9-courier.sandbox.push.apple.com
 34  17.398505 DNS Standard query AAAA 9-courier.sandbox.push.apple.com
 35  17.413188 DNS Standard query response CNAME 9.courier-sandbox-push-apple.com.akadns.net A 17.149.34.67 A 17.149.34.68 A 17.149.34.74 A 17.149.34.65 A 17.149.34.72 A 17.149.34.73 A 17.149.34.75 A 17.149.34.77

Подписка на потоки push-сообщений, детали нужно изучать отдельно. Взаимодействие строится по порту 5223/tcp

 64  18.046396 DNS Standard query A fmip.me.com
 67  18.057170 DNS Standard query AAAA fmip.me.com
 68  18.095476 DNS Standard query response CNAME fmip.me.com.edgekey.net CNAME e3381.b.akamaiedge.net A 92.123.177.205

Подписка на сервис Find My iPhone, взаимодействие по https.

179  29.440446 DNS Standard query A sync.me.com
180  29.447291 DNS Standard query AAAA sync.me.com
182  29.483431 DNS Standard query response CNAME sync.me.com.edgekey.net CNAME e3381.b.akamaiedge.net A 92.123.177.205

Доступ к данным в MobileMe для синхронизации по https

210  32.648537 DNS Standard query A mail.me.com
211  32.656911 DNS Standard query AAAA mail.me.com
212  32.674195 DNS Standard query response A 17.148.16.42 A 17.148.16.43 A 17.148.16.44 A 17.148.16.45 A 17.148.16.46

Соединение с IMAPs сервисом MobileMe – дальше получение почты будет в рамках этого соединения (на протяжении полутора часов идёт регулярный обмен данными).

231  34.002401 DNS Standard query A m.google.com
232  34.014934 DNS Standard query AAAA m.google.com
237  34.027938 DNS Standard query response CNAME mobile.l.google.com A 74.125.43.193
238  34.086932 DNS Standard query response CNAME mobile.l.google.com

Соединение с https сервиса Google Mail (Google Exchange) – дальше получение почты будет в рамках этого соединения.

571 2757.413042 DNS Standard query A 0.pool.ntp.org
572 2757.438746 DNS Standard query response A 72.14.183.39 A 66.79.167.34 A 209.68.147.66

Раз в час – синхронизация времени.

В общем ничего непредсказуемого, на “левые” хосты iPhone не соединяется, всё в рамках заявленного.

Давно я не писал про преодоление защиты сетей. Наверстываю.

Все разы, когда я ездил за границу, в отелях практически всегда был нормальный доступ по WiFi на базе NAT (в основном через transparent proxy для авторизации, но никаких телодвижений по настройке прокси со стороны клиента не требовалось). Только два раза я натыкался на “тупые” конфигурации – один раз в московском отеле, другой – в Амстердаме. Для работы приходилось прописывать прокси, руководствуясь информацией, полученной на receiption.

Конечно же, ssh через web-прокси не работает. Как назло во втором случае мне было очень нужно попасть на мой сервер. Я собирался выкручиваться путём записи на свой сайт скрипта, обеспечивающего доступ к shell, например, PHP and AJAX shell console, но @andy_shev мне порекомендовал corkscrew, утилиту для туннелирования SSH поверх HTTP-прокси. Ею я и воспользовался, за что Andy огромное спасибо.

Одно “но”. Corkscrew использует метод CONNECT, а squid, использующийся в качестве web-прокси в большинстве случаев, в конфигурации по умолчанию разрешает CONNECT только на порт 443:

acl SSL_ports port 443
acl CONNECT method CONNECT
http_access deny CONNECT !SSL_ports

Поэтому corkscrew выдаст “Proxy could not open connnection to host.com: Forbidden” при попытке соединения на любой порт, на котором обычно вешается ssh. Мне повезло, так как я на своём сервере держал ssh на порту 443. Если и вы собираетесь воспользоваться corkscrew, то предварительно перекиньте ssh на 443/tcp.

Приступим. Я использую менеджер пакетов HomeBrew.

Обновляемся:

$ brew update

Ставим corkscrew:

$ brew install corkscrew

Предположим, прокси-сервер находится на адресе 192.168.99.101 и порту 3128. Добавляем в начало конфиг-файла ssh строки:

$ vim ~/.ssh/config
Host *
    ProxyCommand /usr/local/bin/corkscrew 192.168.99.101 3128 %h %p

Если ssh находится не на порту 443, и squid разрешает только порт 443, то получим сообщение (при указании флага “-v”):

$ ssh -v host.com
...
debug1: Reading configuration data /etc/ssh_config
debug1: Executing proxy command: exec /usr/local/bin/corkscrew 192.168.99.101 3128 host.com 22
...
Proxy could not open connnection to host.com:  Forbidden
ssh_exchange_identification: Connection closed by remote host

Для решения проблемы нужно предварительно в конфиг-файле sshd на сервере поменять порт на 443 и перезапустить sshd (конечно же, на этом хосте не должен стоять web-сервер с https):

$ vim /etc/ssh/sshd_config
Port 443

Перезапуск sshd для разных систем делается по-своему, я делаю это через “ps ax | grep sshd”, а потом перезапускаю нужный sshd.

Всё, можно пользоваться:

$ ssh -v -p 443 host.com
Linux host.com 2.6.32-linode23 #1 SMP Sat Dec 5 16:04:55 UTC 2009 i686

12:02 [ctrld@host][~] 

Решений для выход за пределы сети существует много. Описанный мною метод – только один из многих. Любой грамотный IT-специалист навскидку найдёт несколько вариантов, и по крайней мере один из них будет вполне рабочим. Поэтому я всегда скептически отношусь к заявлениям “Специалистов По Корпоративной Безопасности”, что они способны закрыть доступ.

Мне лень напрягаться и придумывать формулировки. Приведу лишь один полезный пример.

Бывает необходимость определить, какие есть “живые” хосты в своей подсети (например, устройства, подключенные к домашней WiFi-сети). Привычный для людей, не очень далёких от сетевых технологий – это отправка icmp-пакетов (говоря проще – пинга) на широковещательный адрес (broadcast). Допустим, если у вас дома сеть 192.168.98.0/24, то broadcast – 192.168.98.255:

$ ifconfig | grep broadcast
	inet 192.168.98.10 netmask 0xffffff00 broadcast 192.168.98.255
	inet 172.16.51.1 netmask 0xffffff00 broadcast 172.16.51.255
	inet 172.16.200.1 netmask 0xffffff00 broadcast 172.16.200.255
$ ping 192.168.98.255
64 bytes from 192.168.98.10: icmp_seq=0 ttl=64 time=0.093 ms
64 bytes from 192.168.98.1: icmp_seq=0 ttl=255 time=2.366 ms (DUP!)
64 bytes from 192.168.98.2: icmp_seq=0 ttl=64 time=2.776 ms (DUP!)
64 bytes from 192.168.98.12: icmp_seq=0 ttl=64 time=8.094 ms (DUP!)

Видим, что в подсети отвечают 4 хоста (WiFi-точка, сервер, ноутбук и iPhone).

Недостаток метода в том, что нужно выяснять broadcast-адрес для конкретной сети. Это, конечно, всего лишь одна дополнительная команда, но есть способ гораздо элегантнее, основанный на использовании multicast-адреса 224.0.0.1, описывающего “The All Hosts multicast group that contains all systems on the same network segment”. Перечень “well-known” multicast-адресов можно найти в Wikipedia.

Посылаем icmp-пакеты на multicast-адрес 224.0.0.1 и получаем ответы:

$ ping  224.0.0.1
64 bytes from 192.168.98.10: icmp_seq=16 ttl=64 time=0.110 ms
64 bytes from 192.168.98.1: icmp_seq=16 ttl=255 time=0.894 ms
64 bytes from 192.168.98.2: icmp_seq=16 ttl=64 time=1.222 ms
64 bytes from 192.168.98.12: icmp_seq=16 ttl=64 time=3.254 ms

Удобно. Рекомендую.

Ещё полезные команды вы можете посмотреть в обсуждении на Server Fault и на Hacker News.

Редко это приходится делать на постоянной основе, обычно достаточно сделать на время соединения (но после рассоединения этот параметр придётся переустанавливать вручную):

$ sudo ifconfig ppp0 mtu 1454

Предварительно стоит узнать стандартный размер MTU для соединения:

$ ifconfig ppp0 | grep mtu
ppp0: flags=8151<UP,POINTOPOINT,RUNNING,PROMISC,MULTICAST> mtu 1500

Универсального оптимального MTU нет, в каждом случае нужно обдуманно к нему подходить, вооружившись информацией по структуре пакета с данными, инкапсулируемого в PPP/PPPoE/VPN/etc.

Если оптимальный размер MTU выбран, и его нужно закрепить навсегда за интерфейсом, то можно воспользоваться рецептом “Optimising MTU setting in PPPoE ADSL Connection“.

Давайте представим обычный случай. Вы далеко от дома, с собой нет ноутбука, только iPhone, и внезапно нужно посмотреть что-то, что есть только на домашнем Mac’е. Сервис MobileMe “Back to my Mac” хорош, но подписка стоит денег, доступиться без предварительной подготовки по VNC проблематично (нужно открыть доступ для VNC и настроить DynDNS – ведь только у редких счастливчиков для домашнего подключения выдаётся постоянный IP-адрес).

Выход, конечно же, есть, причём не сверхзатратный – “LogMeIn Free“. Подписка бесплатна и можно подключить не только Mac’и, но и компьютеры под Windows (к сожалению, агент нельзя поставить на Linux-машину). Сейчас можно испытать бесплатно бета-версию сервиса Pro² for Mac. В обычной ситуации Pro-версия стоит дорого – $69.95 за одну рабочую станцию в год. Pro добавляет возможность File Sharing, печати (полный список можно посмотреть на сайте), но на мой личный взгляд для домашнего пользователя достаточно и Free-версии.

Однако если вы хотите иметь доступ к своим системам отовсюду, где есть мобильный Интернет, то придётся раскошелиться на программу под iPhone “LogMeIn Ignition“, она стоит сумму, находящуюся на грани гуманности – $29.99. Я её приобрёл и два раза, когда она мне понадобилась, вполне окупили её стоимость. Кроме этого программа реально удобна и пользовательская оценка составляет 4.5 балла (для 277 голосов) для текущей версии и 4 балла (для 1341 голосов), что, согласитесь, очень неплохо:

LogMeIn хорош тем, что не требует открывать входящие соединения на машину, куда нужно войти (а как раз эти соединения рубятся брендмауэрами). Агент устанавливает соединение на сервер LogMeIn и удалённый доступ производится через него, что не требует пробивать дыры и открывать доступ по VNC во внутреннюю сеть. Сделаю оговорку – если в политике безопасности под Windows запрещён удалённый доступ, то LogMeIn не даст вам зайти, что в принципе хорошо, так как не вступает в конфликт со внутренними политиками организации.

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

На сессию используется до 80 Kbps трафика, но по опыту через Edge можно вполне комфортно работать.

Итак, приступим к настройке сервиса. Я постоянно себя ловлю на мысли, что LogMeIn созвучно слову “Пельмень”.

Идём на сайт LogMeIn и делаем как обычно – регистрируем account:

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

Выбираем тип сервиса. Pro² beta пока бесплатна, поэтому можно использовать её. Станет платной – можно удалить систему и добавить, но уже в варианте Free. Учтите, что вид Free слегка другой, в ней все настройки производятся через сайт.

Списываем агента:

Нужно подтвердить свой account, перейдя по ссылке, полученной по email на адрес, указанный при регистрации (он у меня попал в Junk):

Устанавливаем агента:

Сразу же после установки агент запускается и доступен через menubar:

Список подключенных систем можно увидеть, зайдя в раздел “My Computers” на сайте LogMeIn:

Для того, чтобы зайти на удалённую систему, жмём “Remote Control” (в первый раз будет запрос на установку плагина для Safari, после чего нужно будет перезапустить браузер), вводим пароль пользователя на вход в систему и можем работать:

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

Есть одна проблема, с которой я сразу же столкнулся, но не искал её решение – русский текст не набирается.

LogMeIn с iPhone

Напомню, что под iPhone нужна программа “LogMeIn Ignition” ($29.99).
Вот такой процесс:

Масштабирование мне понравилось:

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

Если решить проблему с русскими буквами, то LogMeIn для меня станет идеальной системой для удалённого доступа с iPhone. Но и так вполне можно работать, причём быстро и удобно. Рекомендую.

Дальше включаем “Share files and folders using FTP”:

И доступаемся к своим данным по FTP (анонимного FTP нет, и не нужно):

В штатном клиенте есть два варианта отображения – с использованием масштабирования и без него, тогда идёт скроллирование. Отключить масштабирование можно в меню View:

С включённым масштабированием:

С отключённым:

Ещё одна очень полезная функция, доступная пользователям MobileMe “Back to My Mac“. Она позволяет подключиться из Интернет к своим компьютерам, причём не нужно разрешать какие-либо соединения внутрь сети. Включить функцию можно в System Preferences/MobileMe/Back to My Mac:

Всё гладко работает, если строить домашнюю сеть на Apple Airport Extreme/Airport Express/Time Capsule, но поддерживаются и другие устройства.

Для решения проблем можно посмотреть документ “Using and troubleshooting Back to My Mac in Mac OS X 10.5“.

После того, как функция Back to My Mac включена, доступаться к устройствам можно через Finder (в данный момент мой ноутбук подключён к провайдеру, отличному от домашнего и я могу использовать тот же Screen Sharing):

Есть и другие VNC-клиенты, об одном из них я расскажу в следующий раз.

Mac OS X – это полноценный Unix, и им можно вполне управлять удалённо через ssh. Но это бывает неочевидно и сложно. Скажите, никуда не глядя, как включить через консоль, допустим, сервис “File Sharing”, и вы согласитесь, что гораздо быстрее (если вы не знаете решение для консоли) это сделать через GUI.

Для того, чтобы подключиться к Маку, нужно предварительно включить такую возможность. Самый простой метод, использующий протокол VNC – Screen Sharing. Заходим в System Preferences/Sharing и отмечаем “Screen Sharing” (можно добавить пользователей, которым разрешён удалённый доступ):

Настройки сервиса просты (обязательно нужно установить пароль):

Второй вариант – это “Remote Management”:

Настройки немного богаче, причём при включении “Remote Management” отключается “Screen Sharing” – по сути дела это почти одно и то же. Особенность этого метода в том, в дополнение к VNC управлять Маком можно через чрезвычайно мощный пакет Apple Remote Desktop

Это больше решение корпоративного уровня, и стоит соответственно – $499 за неограниченную лицензию для одного администратора или же $299 за 10 систем, которыми можно удалённо управлять для одного администратора.

Функции Apple Remote Desktop:

• удалённая установка софта
• инвентаризация оборудования и программного обеспечения
• построение отчётов по использованию программ
• удалённая поддержка – инженер может решать вопросы не по телефону, а непосредственно на компьютере клиента. Мне понравился режим “Curtain Mode” – клиент не видит, что именно вы делаете
• удалённое администрирование, включая предустановленный набор shell-скриптов для различных задач. Причём можно выполнить задачи на гибко конфигурируемом наборе хостов, например, на всех Mac Pro с версией 10.5
• поддержка Apple Script

К сожалению, посмотреть Apple Remote Desktop я не смог (пока даже не искал легальные методы, а нелегальные меня не интересуют). Поэтому своими Маками я управляю через VNC. А делается это очень просто – нужно в Finder выбрать нужный Мак и нажать “Share Screen”:

После аутентификации можно нормально работать с удалённым хостом:

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

В предыдущих частях мы рассмотрели настройку DNS-сервера под Mac OS X и Mac OS X Server. Сегодня же пришло время рассмотреть создание DNS-сервера в Mac OS X, но гораздо проще, всего лишь с помощью сторонней программы DNS Enabler стоимостью 25$.

Меня сразу неприятно поразило то, что версию под Snow Leopard нельзя списать для того, чтобы её попробовать – для списывания нужно её купить: “The serial number and download link will be displayed in the browser after payment, and will also be sent via email”. Непривычно, согласитесь… Это был звоночек № 1. Но я всё-таки дал обещание сделать обзор, и поэтому решил поставить версию под Leopard.

Списал. В архиве zip был “DNS Enabler for Leopard 3.0.4.app”. Тоже слегка странно – в нормальных программах не ставится номер версии в имени. Звоночек № 2.

Звоночек № 3, он же финальный:

Открыл сайт производителя и начал смотреть на скриншоты и текст.

“The Log Panel shows the contents of the DNS Server log file at /Library/Logs/named.log”. Хммм… Понятно…

Версию bind’а увидели? То-то же и оно. Программа DNS Enabler – это GUI для настройки штатного BIND:

Ничего плохого в этом нет, но смысл запрета списывания вполне понятен – пользователи могут настроить bind в триальной версии, а дальше программа становится ненужной.

Резюме. Если вам нужно настроить DNS-сервер под Mac OS X, но копаться в конфигурационных файлах вам не хочется, то купить DNS Enabler вполне можно. Но если вам нужен DNS-сервер, то с большой долей вероятности можно утверждать, что вы его сможете настроить вручную, используя мою статью: “Настройка DNS-сервера в Mac OS X. Часть 1, Unix Way (BIND)“, поверьте, в этом нет ничего суперсложного.

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