Из подборки на я освежил для себя подзабытую команду airport, с помощью которой можно работать с WiFi-подсистемой.
Утилита находится в дебрях фреймворка Apple80211:
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport
![]()
Учитывая достаточно активное потребление трафика на iPhone, я решил посмотреть, с какими сервисами он взаимодействует.
Задумано-сделано. Вариантов захватить трафик через GPRS у меня, конечно же, нет, поэтому я упростил себе задачу, отключив Cellular Data (iOS 4) и дав iPhone соединяться с Интернет только через WiFi. Внешний интерфейс WiFi-точки я подключил к компьютеру под Ubuntu через который дальше обеспечивается доступ в Интернет.
Для дальнейшего упрощения задачи я решил не анализировать детально трафик, а ограничиться просмотром хостов, к которым iPhone обращается. Тяжело найти человека, который в здравом уме в сетевых приложениях будет использовать обращение по IP-адресам, а не по именам (предполагаем, например, смену хостинговой компании или географическую балансировку нагрузки), поэтому для анализа достаточно посмотреть запросы/ответы DNS.
![]()
Давно я не писал про преодоление защиты сетей. Наверстываю.
Все разы, когда я ездил за границу, в отелях практически всегда был нормальный доступ по WiFi на базе NAT (в основном через transparent proxy для авторизации, но никаких телодвижений по настройке прокси со стороны клиента не требовалось). Только два раза я натыкался на “тупые” конфигурации – один раз в московском отеле, другой – в Амстердаме. Для работы приходилось прописывать прокси, руководствуясь информацией, полученной на receiption.
Конечно же, ssh через web-прокси не работает. Как назло во втором случае мне было очень нужно попасть на мой сервер. Я собирался выкручиваться путём записи на свой сайт скрипта, обеспечивающего доступ к shell, например, , но мне порекомендовал , утилиту для туннелирования SSH поверх HTTP-прокси. Ею я и воспользовался, за что Andy огромное спасибо.
Знаете ли вы, что такое ““? Немногие смогут ответить, что прекрасно знают и используют его осознанно.
Мне лень напрягаться и придумывать формулировки. Приведу лишь один полезный пример.
Бывает необходимость определить, какие есть “живые” хосты в своей подсети (например, устройства, подключенные к домашней 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).
При поиске проблем для сетевых соединений бывает полезно поменять (Maximum Transmission Unit), т.е. ограничить размер пакета, который без фрагментации проходит через сетевой интерфейс.
Редко это приходится делать на постоянной основе, обычно достаточно сделать на время соединения (но после рассоединения этот параметр придётся переустанавливать вручную):
$ 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 выбран, и его нужно закрепить навсегда за интерфейсом, то можно воспользоваться рецептом ““.
![]()
Давайте представим обычный случай. Вы далеко от дома, с собой нет ноутбука, только iPhone, и внезапно нужно посмотреть что-то, что есть только на домашнем Mac’е. Сервис MobileMe “Back to my Mac” хорош, но подписка стоит денег, доступиться без предварительной подготовки по VNC проблематично (нужно открыть доступ для VNC и настроить – ведь только у редких счастливчиков для домашнего подключения выдаётся постоянный IP-адрес).
Выход, конечно же, есть, причём не сверхзатратный – ““. Подписка бесплатна и можно подключить не только Mac’и, но и компьютеры под Windows (к сожалению, агент нельзя поставить на Linux-машину). Сейчас можно испытать бесплатно бета-версию сервиса . В обычной ситуации Pro-версия стоит – $69.95 за одну рабочую станцию в год. Pro добавляет возможность File Sharing, печати (полный список можно ), но на мой личный взгляд для домашнего пользователя достаточно и Free-версии.
Знаете ли вы, что кроме стандартного File Sharing по протоколу AFP можно разрешить доступ по FTP? Если не знаете, то включить это можно в System Preferences/Sharing/File Sharing:
В прошлый раз я описал настройку удалённого доступа к Mac OS X. Несмотря на то, что можно доступаться к компьютеру либо через простой “Screen Sharing”, либо через продвинутый “Remote Management”, общее у этих методов одно – они позволяют использовать сторонние VNC-клиенты.
![]()
Mac OS X – это полноценный Unix, и им можно вполне управлять удалённо через ssh. Но это бывает неочевидно и сложно. Скажите, никуда не глядя, как включить через консоль, допустим, сервис “File Sharing”, и вы согласитесь, что гораздо быстрее (если вы не знаете решение для консоли) это сделать через GUI.
Для того, чтобы подключиться к Маку, нужно предварительно включить такую возможность. Самый простой метод, использующий протокол – Screen Sharing. Заходим в System Preferences/Sharing и отмечаем “Screen Sharing” (можно добавить пользователей, которым разрешён удалённый доступ):

В предыдущих частях мы рассмотрели настройку DNS-сервера под Mac OS X и Mac OS X Server. Сегодня же пришло время рассмотреть создание DNS-сервера в Mac OS X, но гораздо проще, всего лишь с помощью сторонней программы стоимостью 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. Но я всё-таки дал обещание сделать обзор, и поэтому решил поставить .