Осталось прописать модули в автоматическую загрузку, обновить ядро и перезагрузиться.
Это, опять таки, необходимо, чтобы карта при отсутствии каких-либо действий, самопроизвольно не выключилась. Если загрузка модулей прошла удачно, то следующей командой должна быть ./insmod.sh load (её следует запускать только из linuxtv-1.1.1/build-2.4)
Если Вы видите что-то подобное у себя, значит драйвера установлены вполне удачно.
Если всё выглядит так, то считаем установку удачной и можем позволить себе запустить cd linuxtv-1.1.1 && make install и прописываем автозагрузку модулей при запуске системы.
Остальные действия от версии ядра почти не зависят, так что дальше разбиения на разделы 2.4 и 2.6 не будет. Также будет почти сходна настройка карт SkyStar 1 и SkyStar 2.
Теперь нам предстоит «рассказать» карте о том, с каким транспондером и с каким каналом ей предстоит работать. Например, я использую Сервис Raduga, спутник Intelsat-904:
Raduga:11595:v:0:29270:0:0:0
S 11155000 H 2963000 3/4 S 11491000 V 5787000 3/4 S 11520000 V 12000000 3/4 S 11529000 V 2893000 3/4 S 11555000 H 2927000 5/6 S 11595000 H 29270000 5/6 S 11595000 V 29270000 7/8
«напустить» scan на этот файл. Если всё верно настроено и антенна хорошо сориентирована и Вы не забыли прописать при загрузке dvb_core dvb_shutdown_timeout=0 и всё оборудование исправно, то на экране получится что-то вроде
scanning Intel904.60W using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' initial transponder 11595000 H 29270000 7 initial transponder 11595000 V 29270000 7 initial transponder 11520000 V 12000000 3 >>> tune to: 11595:h:0:29270 WARNING: >>> tuning failed!!! >>> tune to: 11595:h:0:29270 (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: 11595:v:0:29270 WARNING: filter timeout pid 0x0011 WARNING: filter timeout pid 0x0000 WARNING: filter timeout pid 0x0010 >>> tune to: 11520:v:0:12000 0x0000 0x0001: pmt_pid 0x0105 MIR-Teleport -- Moskow (running) 0x0000 0x0002: pmt_pid 0x0106 Teleport MIR -- HTB (running) 0x0000 0x0003: pmt_pid 0x0107 MIR-Teleport -- MIR-TV (running) 0x0000 0x0004: pmt_pid 0x0108 MIR Teleport -- MGOU (running) 0x0000 0x0006: pmt_pid 0x010a MIR-Teleport -- MIR Radio Service (running) 0x0000 0x0007: pmt_pid 0x0101 MIR-Teleport -- MAYAK FM (running) 0x0000 0x0008: pmt_pid 0x0100 MIR-Teleport -- MIR Service (running) 0x0000 0x0009: pmt_pid 0x0102 Mir Teleport -- Radio MIR (running) Network Name 'NDS' dumping lists (8 services) Moskow:11520:v:0:12000:512:650:1 HTB:11520:v:0:12000:515:653:2 MIR-TV:11520:v:0:12000:514:652:3 MGOU:11520:v:0:12000:517:655:4 MIR Radio Service:11520:v:0:12000:0:660:6 MAYAK FM:11520:v:0:12000:0:662:7 MIR Service:11520:v:0:12000:513:651:8 Radio MIR:11520:v:0:12000:0:665:9 Done.
Только беда в том, что сервисы данных
scan не «отловит» (обратите внимание на строчку
>>> tune to: 11595:h:0:29270 WARNING: >>> tuning failed!!! Как раз, нужный мне транспондер) так что для настроек на Интернет Провайдера, придётся создавать файл
channels.conf вручную.
Попробуем настроить карту на приём данных:
/bin/szap -c /etc/channels.conf. Опять же, если всё было сделано верно, то мы увидим на экране следующее:
brat3 util # szap -c /etc/channels.conf -n 1 -x reading channels from file '/etc/channels.conf' zapping to 1 'I904': sat 0, frequency = 11595 MHz V, symbolrate 29270000, vpid = 0x0000, apid = 0x0000 using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 03 | signal ba7a | snr 7aeb | ber 000026cd | unc 00000000 | status 1f | signal b8fe | snr cfe1 | ber 000005c6 | unc 00000000 | FE_HAS_LOCK
Понятно, что если сигнал по той или иной причине пропал, ну например, произошло затенение отражателя, то эту процедуру надо повторить.
Осталось активировать сетевой интерфейс. Будьте внимательны — всё завист от того, какой тип фильтрации сетевых пакетов использует Ваш Интернет Провайдер. Если фильтрация пакетов идёт по MAC-адресу, то исправлять ничего не надо. Если фильтрация идёт по IP-адресу, то необходимо установить MAC-адрес карты в нужное значение. Например, если выданный мне провайдером IP-адрес 10.252.155.40, то его необходимо перевести в шестнадцатеричную форму: 0A:FC:9B:28 и прибавить в начале ещё два нуля: 00:00:0A:FC:9B:28. Иногда, правда, провайдер добавляет специальный префикс. Например, 02:00:0A:FC:9B:28. Впрочем, всю эту информацию вы у него и должны узнать.
Адрес карты устанавливаем произвольный, причём, желательно, чтоб этот адрес не попадал ни в одну из внутренних подсетей. Ну, например, для моей сети вполне подойдёт адрес 10.95.2.1, Поскольку внутренняя подсеть у меня 10.95.1.0/24. Итак:
1. Настраиваем фильтрацию по PID-у, указанному провайдером (Идентификатору Пакетов) и создаём сетевой интерфейс. Например: dvbnet -p 4152.
brat3 root # dvbnet -p 4152 DVB Network Interface Manager Version 1.1.0-TVF (Build Fri Aug 12 14:12:43 2005) Copyright (C) 2003, TV Files S.p.A Device: /dev/dvb/adapter0/net0 Status: device dvb0_0 for pid 4152 created successfully.
2. Присваиваем интерфейсу IP-адрес и MAC-адрес. Здесь будьте внимательны — если вы сделаете что-то неверно, то tcpdump будет показывать наличие траффика, но работать ничего не будет.
ifconfig dvb0_0 10.95.2.1 netmask 255.255.255.255 broadcast 255.255.255.255
ifconfig dvb0_0 hw ether 00:00:0A:FC:9B:28
route add 10.95.2.1 dev dvb0_0
Теперь ifconfig должен показать что-то в этом роде:
dvb0_0 Link encap:Ethernet HWaddr 00:00:0A:FC:F3:9F inet addr:10.95.2.1 Bcast:255.255.255.255 Mask:255.255.255.255 UP BROADCAST RUNNING NOARP MULTICAST MTU:4096 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Base address:0x1038
а в таблице маршрутизации должна появится следующая строка:
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.95.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 dvb0_0
Настал трепетный момент проверки работоспособности сетевого интрефейса. Вариантов два. Самый простой:
# tcpdump -ni dvb0_0 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on dvb0_0, link-type EN10MB (Ethernet), capture size 96 bytes 21:42:01.020568 IP 217.10.39.84.80 > <GW_IP>88.2909: . 1195548608:1195549945(1337) ack 1701755686 win 57491 21:42:01.020584 IP 217.10.39.84.80 > <GW_IP>88.2909: . 1337:2674(1337) ack 1 win 57491 21:42:01.020586 IP 217.16.19.219.80 > 10.252.246.254.2394: S 3017247152:3017247152(0) ack 4146269160 win 5840 <mss 1460>
Вот когда такое по экрану ползёт, рука сама тянется «напустить» на всё это
sniffit, но мы это делать не будем, поскольку
неприлично подглядывать за чужим траффиком. Так делают только очень нехорошие дяди. Нам вполне должно быть достаточно того, что
всё работает, однако!
Второй вариант проверки работоспособности интерфейса и того проще:
brat3 root # dvbtraffic 0365 10 p/s 1 kb/s 15 kbit 1029 89 p/s 16 kb/s 134 kbit 1030 166 p/s 30 kb/s 250 kbit 1031 774 p/s 142 kb/s 1164 kbit 1036 312 p/s 57 kb/s 469 kbit 1037 616 p/s 113 kb/s 926 kbit 1038 1035 p/s 190 kb/s 1557 kbit 1039 678 p/s 124 kb/s 1020 kbit 1040 91 p/s 16 kb/s 137 kbit 1042 119 p/s 21 kb/s 180 kbit 1050 1 p/s 0 kb/s 2 kbit 1051 2161 p/s 396 kb/s 3250 kbit 1056 5 p/s 0 kb/s 8 kbit 1057 359 p/s 65 kb/s 540 kbit 1058 961 p/s 176 kb/s 1445 kbit 1059 5 p/s 0 kb/s 8 kbit 1101 244 p/s 44 kb/s 367 kbit 1102 222 p/s 40 kb/s 334 kbit 1103 9 p/s 1 kb/s 14 kbit 1104 166 p/s 30 kb/s 249 kbit 1105 49 p/s 8 kb/s 73 kbit 1109 1095 p/s 201 kb/s 1647 kbit 2000 9177 p/s 1684 kb/s 13802 kbit -PID--FREQ-----BANDWIDTH-BANDWIDTH- 0365 9 p/s 1 kb/s 14 kbit
Того лучше, прописать какой-нибудь
init-скрипт. Скажем, для
Gentoo можно построить в
/etc/init.d/ скрипт
dvbinit:
#!/sbin/runscript # Copyright (c) Vitaliy Pryadko # 2005 ( http://www.opennet.ru/base/sys/skystar2_linux.txt.html ) # DIR=/usr/local/ #пид вашего провайдера PID=0x103B DEV_NAME=dvb0_0 #IP карты dvb. смотреть в мануале или в и-нете. IP_ADDR=10.95.2.1 NETMASK=255.255.255.255 BCAST=255.255.255.255 # здесь пишем MAC dvb карты. В данном случае -- 00:00:+ # IP-адрес, выданный провайдером в шестнадцатеричном виде. MAC_ADDR=00:00:0A:FC:F3:9F depend() { # need szap dvbnet ifconfig route after net.eth0 } start () { cd $DIR/bin # тюним на нужный спутник, частоту и т.п. ebegin "Read channels.conf" $DIR/bin/szap -c /etc/channels.conf -n 1 -x eend # создаем сетевой адаптер ebegin "Set PID $" $DIR/bin/dvbnet -p $PID eend # присваеваем карте IP ebegin "ifconfig Dev=$ IP=$, Netmask=$, Broadcast=$" /sbin/ifconfig $DEV_NAME $IP_ADDR netmask $ broadcast $ eend # присваеваем карте MAC ebegin "Set MAC-Address - $" /sbin/ifconfig $DEV_NAME hw ether $ eend # Устанавливаем маршрутизацию на этот интерфейс ebegin "Set route on DVB card interface" route add $ dev $ eend ebegin "Disable rp_filter" echo -n 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter eend } stop() { ebegin "Shutdown DVB-Interface" /sbin/ifconfig $ down $DIR/bin/dvbnet -d 0 eend }А в
Ubuntu тот же
init-скрипт может выглядеть примерно так:
#!/bin/bash # Copyright (c) Vitaliy Pryadko # 2005 ( http://www.opennet.ru/base/sys/skystar2_linux.txt.html ) # DIR=/usr/ # пид вашего провайдера (в данном случае представлен в шестнадцатеричном виде, но кто мешает в десятичном?) PID=0x103B # DVB-интерфейс DEV_NAME=dvb0_0 # IP карты dvb. смотреть в мануале или в и-нете. Назначить можно "от балды", главное прописать правильно роутинг IP_ADDR=10.95.2.1 NETMASK=255.255.255.255 BCAST=255.255.255.255 # здесь пишем MAC dvb карты. В данном случае -- 00:00:+ # IP-адрес, выданный провайдером в шестнадцатеричном виде. MAC_ADDR=00:00:0A:FC:F7:9E case "$" in start) cd $DIR/bin # настраиваем на нужный спутник, частоту и т.п. echo "Read channels.conf" $DIR/bin/szap -c /etc/channels.conf -n 1 -x # устанавливаем PID для аппаратной фильтрации пакетов echo "Set PID $" $DIR/bin/dvbnet -p $PID # Создаём сетевой интерфейс и присваеваем карте IP echo "ifconfig Dev=$ IP=$, Netmask=$, Broadcast=$" /sbin/ifconfig $DEV_NAME $IP_ADDR netmask $ broadcast $ # Устанавливаем MAC-адрес карты (если фильтрация идёт по IP, представленному в виде # шестнадцатеричной формы MAC-адреса или MAC-адрес карты не соответствует необходимому echo "Set MAC-Address - $" /sbin/ifconfig $DEV_NAME hw ether $ # Устанавливаем маршрутизацию на созданный интерфейс echo "Set route on DVB card interface" route add $ dev $ # Выключаем rp_filter для того, чтобы пакеты могли приходить с _другого_ интерфейс # (spoofing) echo "Disable rp_filter" echo 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter # Отменяем автоматическое отключение карты ( 5 сек ) echo "Disable shutdown timeout" echo 0 > /sys/module/dvb_core/parameters/dvb_shutdown_timeout ;; stop) echo "Shutdown DVB-Interface" /sbin/ifconfig $ down $DIR/bin/dvbnet -d 0 ;; reload) echo "Shutdown DVB-Interface" /sbin/ifconfig $ down $DIR/bin/dvbnet -d 0 cd $DIR/bin # настраиваем на нужный спутник, частоту и т.п. echo "Read channels.conf" $DIR/bin/szap -c /etc/channels.conf -n 1 -x # устанавливаем PID для аппаратной фильтрации пакетов echo "Set PID $" $DIR/bin/dvbnet -p $PID # Создаём сетевой интерфейс и присваеваем карте IP echo "ifconfig Dev=$ IP=$, Netmask=$, Broadcast=$" /sbin/ifconfig $DEV_NAME $IP_ADDR netmask $ broadcast $ # Устанавливаем MAC-адрес карты (если фильтрация идёт по IP, представленному в виде # шестнадцатеричной формы MAC-адреса или MAC-адрес карты не соответствует необходимому echo "Set MAC-Address - $" /sbin/ifconfig $DEV_NAME hw ether $ # Устанавливаем маршрутизацию на созданный интерфейс echo "Set route on DVB card interface" route add $ dev $ # Выключаем rp_filter для того, чтобы пакеты могли приходить с _другого_ интерфейс # (spoofing) echo "Disable rp_filter" echo 0 > /proc/sys/net/ipv4/conf/dvb0_0/rp_filter # Отменяем автоматическое отключение карты ( 5 сек ) echo "Disable shutdown timeout" echo 0 > /sys/module/dvb_core/parameters/dvb_shutdown_timeout ;; restart) echo "This reloading all DVB modules" ;; esac
Понятно, что в данном случае, скрипт переопределяет фильтрацию пакетов по MAC-адресу карты. Также, совершенно ясно, что приведённые здесь MAC-адреса взяты «от балды», то есть числа эти появились здесь совершенно случайно.
Правда, совершенно не важно, каков на самом деле настоящий MAC-карты — в данном случае, он определяется параметрами скрипта, а не прошивкой микросхемы.
Если Вы, почтеннейшие граждане Публика пользуетесь
GentOO, то не забудьте добавить Ваш скрипт в «умолчальный» уровень загрузки:
rc-update add dvbinit default
3. Ассиметричный доступ
Клопы отдельно, тараканы — отдельно
© Народный рецепт
Думаю, что никому не открою страшной тайны, если скажу, что спутниковый доступ к Интернет
ассиметричный. То есть, исходящий траффик должен идти по
другому каналу, который, как правило, называют почему-то «наземным». Забавно, но в большей части случаев подключение к Интернет через спутник осуществляется через
GPRS (
EDGE) или
CDMA мобильному телефону. Гораздо реже связь осуществляется через спутник же, но такое подключение обходится по себестоимости дороже трафика через
GPRS-провайдера (порядок цен ~ .22$ за мегабайт). Правда подключение такое будет двунаправленным, а вовсе ни разу не симметричным — устройство для исходящего трафика отдельно, для входящего — отдельно.
Ниже размещу некую картинку, дабы подчеркнуть размеры пропасти между пользователем, спутником и провайдером (что-то порядка 36.000 км до геостационарной орбиты спутника и столько же обратно):
Во-первых, мы отправляем запрос к нашему спутниковому провайдеру через подключение к наземному Интернет-провайдеру, например, через
GPRS,
EDGE,
CDMA или другим способом. Получив наш запрос наземный провайдер передаёт его Спутниковому Провадйдеру. Последний, в свою очередь, обрабатывает его и отправляет данные на спутник. Со спутника данные принимаются нашей спутниковой антенной и попадают через Спутниковую Карту на наш компьютер и, может быть, во внутренню интрасеть.
Современные спутниковые провайдеры как правило предоставляют наземное поключение по Виртуальной Частной Сети (VPN). На мой взгляд, самый простой способ осуществить подключение к сети — использовать
OpenVPN. Начиная со второй версии, Клиент
OpenVPN при подключении самостоятельно настраивает маршрутизацию и что, кстати, немаловажно при подключении через мобильный телефон
GPRS,
EDGE или
CDMA, устойчиво «держит» связь (в отличие, скажем от
P-t-P MPPE/MPPC подключения).
Кроме того,
OpenVPN-подключение можно установить и через
GPRS и
EDGE. К примеру, на сей день провайдеры
БиЛайн и
МТС закрыли возможность подключения по обычному
VPN. У
Megafon'a, вроде бы работает, но лучше бы не работало — качество связи просто отвратительное. Что же до разнесчастного
SkyLink'a, то они, через какой-то год совместно работы, обнаружили что я работаю по ассиметричному каналу. Тогда они просто перекрыли доступ в интернет. (А может и вру, может действительно, помехи из Кубинки мешали… но тогда почему с другого номера, с того же аппарата, связь прекрасно «качалась»?)
Надо так понимать, что никакие звонки в службу техподдержки и прочая ругань не помогли. Увы… хотя, надо честно признать, что
CDMA-подключение, скажем через тот же
Ubiquam-105, работает намного прияственнее, чем через
EDGE при помощи модема
Nokia-6021.
Но, увы. Не для меня это пока, не для меня. Впрочем, провайдеров тоже можно понять: раздавать большое количество дата-трафика куда как невыгоднее, чем драть за голосовой…
3.1. OpenVPN.
Если Ваш провайдер предоставляет подключение через
OpenVPN, то всё, что Вам нужно — это загрузить последнюю версию программного обеспечения, установить её. Далее, загрузить файлы ключей и конфигурационный файл у провайдера, положить их в какую-нибудь директорию (например
/etc/openvpn/config/ и набрать из командной строки:
openvpn --config client.config.
Для моего замечательного провайдера
Raduga-Internet конфигурационный OpenVPN-файл будет выглядеть простейшем виде, под
Windows ™ примерно так:
clientdev tapdev-node Radugaproto udpremote 80.81.208.82 55668resolv-retry infinitenobindpersist-keypersist-tunca ca.crtcert iXXXXXXX.crtkey iXXXXXXX.keyns-cert-type serververb 3comp-lzo comp-noadaptauth-user-pass ovpn.txt
Обратите внимание на строчку auth-user-pass.txt, в котором первая строка, данный вам провайдером логин, во-второй — пароль (некое, правда несколько сомнительное, повышение безопасности туннеля) Однако, в #nix–системах всё может выглядеть несколько иначе:
dev tapport 55668proto udpremote 80.81.208.82comp-lzocomp-noadaptifconfig 10.255.XXX.XXX 255.255.255.0route-noexectun-mtu 1400tls-clientca /etc/openvpn/raduga/ca.crtcert /etc/openvpn/raduga/iXXXXXXX.crtkey /etc/openvpn/raduga/iXXXXXXX.keyauth-user-pass /etc/openvpn/raduga/password.txt ns-cert-type serveruser daemongroup daemonverb 4
Т.е., скажем халявы с автоматической маршрутизацией пакетов не будет: роутинг, и прочие радости придётся настраивать вручную. А чегож Вы, почтеннейшие граждане Публика, хотели? #nix он на то и #nix, чтобы всё, включая закат солнца вечером, вручную.
Да и не забудьте, правильно скомпилировать то самое устройство /dev/tap, к которому мы собрались обратиться. В противном случае на экран после груды отладочной информации будет вывалено примерно такое сообщение:
Thu Nov 23 11:07:52 2006 us=372950 Control Channel MTU parms [ L:1474 D:138 EF:38 EB:0 ET:0 EL:0 ] Thu Nov 23 11:07:52 2006 us=373540 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2) Thu Nov 23 11:07:52 2006 us=373740 Note: Attempting fallback to kernel 2.2 TUN/TAP interface Thu Nov 23 11:07:52 2006 us=375631 Cannot allocate TUN/TAP dev dynamically Thu Nov 23 11:07:52 2006 us=375893 Exiting
Чтобы этого не произошло, не забудьте подключить при компилляции ядра настройку CONFIG_TUN=[m/y] (раздел «Drivers» -> «Network device support» -> «Universal TUN/TAP device driver support TUN») в случае /usr/src/linux/make menuconfig или, скажем, /usr/src/linux/make gconfig, а то и вовсе cd /usr/src/linux/ && genkernel --gconfig all)
Подробнее об устройствах /dev/net/tun и /dev/net/tap/ Вы можете почитать, к примеру в разделе документации, прилагающейся к ядру линукса /usr/src/linux/Documentation/networking/tuntap.txt.
Впрочем, если Вы, почтеннейшие граждане Публика, думаете, что на этом Ваши мучения закончились, Вы глубоко заблуждаетесь: они только начались. Нам предстоит настроить маршрутизацию IP-пакетов, что само по себе, является далеко не тривиальной задачей для ассиметричного доступа.
Да нет, нет, шучу. Нужно просто удалить «default» маршрут на входящие подключения и указать отдельные маршруты на входящие и исходящие пакеты:
route del default
route add -net <dsn спутникового провайдера> netmask 255.255.255.255 dev ppp0
/usr/sbin/openvpn --config /etc/openvpn/config/client.ovpn --daemon --log /var/log/openvpn.log
route add default gw <шлюз, указанный спутниковым провайдером>
Т.е., шлюз указывается только после того, как открыто openvpn подключение, а первичный маршрут {route add -net <dns спутникового провайдера> netmask 255.255.255.255 dev ppp0}, прописывается только для того, чтобы подключиться к спутниковому провайдеру по openvpn-каналу.
Того проще, запихать всё это, скажем в один настроечный файл. Нууу… пусть это будет либо фрагмент
/etc/ppp/ip-up-скрипта, либо (что более грамотно реализовано в штатной поставке
Ubuntu-Linux) скриптом, находящимся в директории
/etc/ppp/ip-up.d/01swparams:
#!/bin/sh## this is a script which is executed after connecting the ppp interface.# look at man pppd for details# the followings parameters are available:# $1 = interface-name# $2 = tty-device# $3 = speed# $4 = local-IP-address# $5 = remote-IP-address# $6 = ipparam CURDATE=`date`# echo "$ iface = $1 tty = $2 iface = $3 ip_local = $4 ip_remote = $5 param = $6" >> $# The environment is cleared before executing this script# so the path must be resetPATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/binexport PATH# These variables are for the use of the scripts run by run-parts# PPP_IFACE="$1"# PPP_TTY="$2"# PPP_SPEED="$3"# PPP_LOCAL="$4"# PPP_REMOTE="$5"# PPP_IPPARAM="$6"OVPNCNF="/etc/openvpn/raduga/client.ovpn"OVPNLOG="/var/log/openvpn.log"RESOLVRADUGA="/etc/ppp/resolv/resolv.raduga"OPENVPN="/usr/sbin/openvpn"ROUTE="/sbin/route"LOGGER="/usr/bin/logger"TUN_IFACE="tap0"# http://faq.d-v.ru/index.php?action=artikel&cat=44&id=212&artlang=ruSATGW="10.255.128.1"REMOTE="80.81.208.82"export PPP_IFACE PPP_TTY PPP_SPEED PPP_LOCAL PPP_REMOTE PPP_IPPARAM# as an additional convenience, $PPP_TTYNAME is set to the tty name,# stripped of /dev/ (if present) for easier matching.PPP_TTYNAME=`/usr/bin/basename "$2"`export PPP_TTYNAME case "$" in mts) $ del default $ add default gw $ iptables -F iptables -t nat -F iptables -t mangle -F iptables -t nat -A POSTROUTING -o $ -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward ;; bee) $ del default $ add default gw $ iptables -F iptables -t nat -F iptables -t mangle -F iptables -t nat -A POSTROUTING -o $ -j MASQUERADE echo 1 > /proc/sys/net/ipv4/ip_forward ;; mts+dv) echo "Delete default $ rule" $ del default echo "Add particular $ rule -net $ netmask 255.255.255.255 dev ppp0 (d-v server)" $ add -net $ netmask 255.255.255.255 dev ppp0 echo "Store old iptables rule" $ | tee iptables.old.lst echo "Startup openvpn" # From http://www.openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html : # Note that cmd can be a shell command with multiple arguments, in which case all # OpenVPN-generated arguments will be appended to cmd to build a command line which will be passed to the shell # '#' -- comment all parameters added by openvpn automatically $ --config $ --daemon --pull --up "$ add default gw $ # " --log $ echo "load IPTABLES rules for MASQUERADING and enable forwarding " iptables -F iptables -t nat -F iptables -t mangle -F iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE echo "Enable ip forwarding" echo 1 > /proc/sys/net/ipv4/ip_forward echo "Rewrite resolv.conf" /bin/cp $ /etc/resolv.conf echo "PPP_PARAM = "$", PPP_REMOTE = "$ ;; bee+dv) echo "Delete default $ rule" $ del default echo "Add particular $ rule -net $ netmask 255.255.255.255 dev ppp0 (d-v server)" $ add -net $ netmask 255.255.255.255 dev ppp0 echo "Store old iptables rule" $ | tee iptables.old.lst echo "Startup openvpn" # From http://www.openvpn.net/index.php/documentation/manuals/openvpn-20x-manpage.html : # Note that cmd can be a shell command with multiple arguments, in which case all # OpenVPN-generated arguments will be appended to cmd to build a command line which will be passed to the shell # '#' -- comment all parameters added by openvpn automatically $ --config $ --daemon --pull --up "$ add default gw $ # " --log $ echo "load IPTABLES rules for MASQUERADING and enable forwarding " iptables -F iptables -t nat -F iptables -t mangle -F iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE echo "Enable ip forwarding" echo 1 > /proc/sys/net/ipv4/ip_forward echo "Rewrite resolv.conf" /bin/cp $ /etc/resolv.conf echo "PPP_PARAM = "$", PPP_REMOTE = "$ ;;esac
Обратите внимание на то, что в строчке $ --config $ --daemon --pull --up "$ add default gw $ # " --log $ в параметре --up после $ add default gw $ стоит символ '#'. Это связано с тем, что openvpn любит добавлять свои собственные параметры (нафига так делать было?) если в --up вызывается команда с несколькими аргументами командной строки. Теперь, всё, что имеет добавить openvpn будет воспринято, как комментарий.
В данном случае, команда route add default gw <IP> добавляет маршрут по умолчанию для созданного tap интерфейса. Теперь все пакеты будут «ходить» именно через него. Кстати, большая часть ошибок в стиле «всё настроил и не работает…» приходится именно на этот участок. Не забывайте набирать в случае «не работает» почаще команду
$ route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp080.81.208.82 0.0.0.0 255.255.255.255 UH 0 0 0 ppp010.95.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 dvb0_010.255.128.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth00.0.0.0 10.255.128.1 0.0.0.0 UG 0 0 0 tap0
И, ура:
Теперь при подключении к «спутнику» можно будет набрать что-то вроде:
pppd call mts+dv
а не последовательность комманд, обозначающую, что все процессы работы с ассиметричным доступом Вы уже успели выучить наизусть и беглость пальцев при печати с избытком покрывает Вашу неприязнь к любого рода изыбточной оптимизации. Никакого прогресса! Всем назад в пещеры и картинки всем править в текстовой консоли!!!
Понятно, что самое название подключения, скажем bee+dv или sky+dv указываеся в настройках модема, используемого для исходящего трафика. Я использую для «наземного» подключения GPRS-модем (в данном случае, GPRS-модема Siemens NS75) Настройки записаны в файл /etc/ppp/peers/mts+dv и название подключения задано при помощи ipparam bee+dv:
# Siemens ES75i GPRS 115200K# 115200,8,N,1, ctsfl=1, rtsctl=2/dev/ttyACM0115200user mtsremotename "internet.mts.ru"debug-detachnovjnoauthpersist# passiveusepeerdnsnoipdefaultdefaultrouteconnect 'chat -v -f /etc/chatscripts/mts -T *99***1#'ipparam mts
Заметьте, что здесь стоит опция -detach. Это связано с тем, что модем Siemens NS75, как и некоторые другие, имеет привычку подключаться аккуратно через раз. С чем это может быть связано, даже предположить боюсь… так, что лучше держать перед глазами консоль, на которой видно состояние подключения.
Подробнее о настройке OpenVPN можно прочитать в
OpenVPN ™ 2.x HOWTO[14]. Ну а если Вы и так всё правильно настроили, то при подключении OpenVPN-клиента должно получиться что-то в этом роде:
brat3 config # openvpn --config client.ovpn Sat Sep 17 21:01:00 2005 OpenVPN 2.0 i686-pc-linux [SSL] [LZO] [EPOLL] built on Aug 14 2005 Sat Sep 17 21:01:00 2005 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Sat Sep 17 21:01:00 2005 WARNING: file 'Client.key' is group or others accessible Sat Sep 17 21:01:00 2005 Control Channel MTU parms [ L:1573 D:138 EF:38 EB:0 ET:0 EL:0 ] Sat Sep 17 21:01:00 2005 Data Channel MTU parms [ L:1573 D:1450 EF:41 EB:4 ET:32 EL:0 ] Sat Sep 17 21:01:00 2005 Local Options hash (VER=V4): '2c50bd2c' Sat Sep 17 21:01:00 2005 Expected Remote Options hash (VER=V4): '0ddbb6e3' Sat Sep 17 21:01:00 2005 UDPv4 link local: [undef] Sat Sep 17 21:01:00 2005 UDPv4 link remote: <SERVER_IP>:55684 Sat Sep 17 21:01:08 2005 TCP/UDP: Incoming packet rejected from 127.0.0.1:53[2], expected peer address: <SERVER_IP>:55684 (allow this incoming source address/port by removing --remote or adding --float) Sat Sep 17 21:01:08 2005 TCP/UDP: Incoming packet rejected from 127.0.0.1:53[2], expected peer address: <SERVER_IP>:55684 (allow this incoming source address/port by removing --remote or adding --float) Sat Sep 17 21:01:10 2005 TLS: Initial packet from <SERVER_IP>:55684, sid=7bcc4f6c bae60adb Sat Sep 17 21:01:51 2005 VERIFY OK: depth=1, /C=RU/ST=MW/L=MOSCOW/O=RadugaVPN/emailAddress=support@telecom-service.net Sat Sep 17 21:01:51 2005 VERIFY OK: nsCertType=SERVER Sat Sep 17 21:01:51 2005 VERIFY OK: depth=0, /C=RU/ST=MW/O=RadugaVPN/CN=RadugaVPN/emailAddress=support@telecom-service.net Sat Sep 17 21:01:55 2005 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Sep 17 21:01:55 2005 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sat Sep 17 21:01:55 2005 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key Sat Sep 17 21:01:55 2005 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Sat Sep 17 21:01:55 2005 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA Sat Sep 17 21:01:55 2005 [RadugaVPN] Peer Connection Initiated with <SERVER_IP>:55684 Sat Sep 17 21:01:56 2005 SENT CONTROL [RadugaVPN]: 'PUSH_REQUEST' (status=1) Sat Sep 17 21:01:57 2005 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway,dhcp-option DNS <SERVER_IP>, route-gateway <GW_IP>,ping 10, ping-restart 120, route 0.0.0.0 0.0.0.0 <GW_IP>, dhcp-option DNS 82.118.131.162, ifconfig <LOCAL_IP> 255.255.255.0' Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: timers and/or timeouts modified Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: --ifconfig/up options modified Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: route options modified Sat Sep 17 21:01:57 2005 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified Sat Sep 17 21:01:57 2005 TUN/TAP device tap0 opened Sat Sep 17 21:01:57 2005 /sbin/ifconfig tap0 <LOCAL_IP> netmask 255.255.255.0 mtu 1500 broadcast <BROADCAST_IP> Sat Sep 17 21:01:57 2005 /sbin/route add -net <SERVER_IP> netmask 255.255.255.255 gw 212.119.97.85 Sat Sep 17 21:01:57 2005 /sbin/route del -net 0.0.0.0 netmask 0.0.0.0 Sat Sep 17 21:01:57 2005 /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw <GW_IP> Sat Sep 17 21:01:57 2005 /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw <GW_IP> Sat Sep 17 21:01:57 2005 /sbin/route add -net 0.0.0.0 netmask 0.0.0.0 gw <GW_IP> Sat Sep 17 21:01:57 2005 Initialization Sequence Completed
, где <LOCAL_IP> — IP-адрес, предоставленный Вам провайдером для подключения (если используется фильтрация по IP-адресу), <SERVER_IP> — адрес сервера, к которому осуществляется подключение, <BROADCAST_IP> — IP-адрес широковещательной передачи, <GW_IP> — IP-адрес шлюза.
Таблица маршрутизации после создания VPN-подключения, соответственно, будет выглядеть так:
Kernel IP routing table | Destination | Gateway | Genmask | Flags | Metric | Ref | Use | Iface |
| <EARTHLINK_GW> | 0.0.0.0 | 255.255.255.255 | UH | 0 | 0 | 0 | ppp0 |
| <SATLINK_GW> | <EARTHLINK_GW> | 255.255.255.255 | UGH | 0 | 0 | 0 | ppp0 |
| <LOCAL_DVB_IP> | 0.0.0.0 | 255.255.255.255 | UH | 0 | 0 | 0 | dvb0_0 |
| <LOCAL_NET> | 0.0.0.0 | <LOCAL_NETMASK> | U | 0 | 0 | 0 | eth0 |
| <DVB_NETWORK> | 0.0.0.0 | <DVB_NETMASK> | U | 0 | 0 | 0 | tap0 |
| 127.0.0.0 | 127.0.0.1 | 255.0.0.0 | UG | 0 | 0 | 0 | lo |
| 0.0.0.0 | <EARTHLINK_GW> | 0.0.0.0 | UG | 0 | 0 | 0 | tap0 |
, где <EARTHLINK_GW> — шлюз для наземного подключения (в данном случае — ppp0); <SATLINK_GW> — шлюз спутникового подключения; <LOCAL_DVB_IP> — IP-адрес, присвоенный dvb-интерфейсу спутниковой карты; <LOCAL_NET>, <LOCAL_NETMASK> — соответственно, адрес локальной (интранет) сети (если есть) и маска подсети; <DVB_NETWORK>, <DVB_NETMASK> — адрес сети из которой Вам выдаётся IP-адрес при подключении и маска подсети.
Соответственно, ppp0 — интерфейс «наземного» подключения, tap0 — OpenVPN-подключение, dvb0_0 — интерфейс спутниковой карты, eth0 — сетевое подключение к внутренней (интранет) сети (если она, конечно же есть).
Ну чтож, всё, что осталось сделать — это запустить
brat3 root # ping ya.ru PING ya.ru (213.180.204.8) 56(84) bytes of data. 64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=50 time=623 ms 64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=50 time=598 ms 64 bytes from ya.ru (213.180.204.8): icmp_seq=3 ttl=50 time=519 ms
и убедиться, что всё работает… ну или не работает… тогда начинать всё сначала, проверять и перепроверять, тестировать оборудование… да мало ли?
Думаю, что в первую очередь, надо проверять, верно ли настроена филтрация IP-пакетов в спутниковой карте.
Во-всяком случае, чат-скрипт /etc/ppp/chats/skylink
'' AT+CRM=1;&C0 'OK' ATS0=0 'OK' ATS7=60 'OK' ATDT#777 'CONNECT'
и файл с «рулями» (peers) — /etc/ppp/peers/cdma-skylink
# You usually need this if there is no PAP authentication noauth # The chat script (be sure to edit that file, too!) connect "/usr/sbin/chat -v -f /etc/ppp/chats/skylink" # Set up routing to go through this PPP link defaultroute # Set this to /dev/ircomm0 or similar /dev/ttyUSB0 # Speed # 115200 23040 # Control character handling asyncmap 20A0000 escape FF # Reconnect on disconnect persist # Be extra verbose debug # You may need these passive noipdefault noproxyarp ipcp-accept-local ipcp-accept-remote ipcp-restart 2 ipcp-max-configure 20 ipcp-max-failure 20 # Use remote DNS usepeerdns # With GPRS, authentication is normally done automatically # via your cellphone number, so leave login name empty # user "mobile@mppc.skylink.msk.ru" user "mobile" ipparam cdma-skylink # Set MTU mtu 1400 # User Hardware flow -control crtscts # Let the phone figure out all the IP addresses noipdefault
и /etc/ppp/peers/skylink+dv:
# You usually need this if there is no PAP authentication noauth # The chat script (be sure to edit that file, too!) connect "/usr/sbin/chat -v -f /etc/ppp/chats/skylink" # Set up routing to go through this PPP link defaultroute # Set this to /dev/ircomm0 or similar /dev/ttyUSB0 # Speed # 115200 230400 # Set MTU mtu 1400 # Reconnect on disconnect persist # Be extra verbose debug # You may need these passive noipdefault noproxyarp # Let the phone figure out all the IP addresses ipcp-accept-local ipcp-accept-remote ipcp-restart 2 ipcp-max-configure 20 ipcp-max-failure 20 # Control character handling asyncmap 20A0000 escape FF # asyncmap 0xa0000 # No ppp compression novj nodeflate nobsdcomp # Use remote DNS usepeerdns # With GPRS, authentication is normally done automatically # via your cellphone number, so leave login name empty # user "mobile@mppc.skylink.msk.ru" user "mobile" ipparam skylink+dv # Use hardware flow conrtrol crtscts
В некоторой степени отличаются от «штатных» GPRS/EDGE-настроек.». На пример, файл для подключения Nokia-6021 через BlueTooth /etc/ppp/chats/nokia-6021:
# Siemens NS75 Serial GPRS 57K# 57600,8,N,1, ctsfl=1, rtsctl=2REPORT CONNECTABORT BUSYABORT "NO CARRIER"ABORT ERRORABORT ncorrectABORT "NO ANSWER"ABORT "NO DIALTONE"''ATZ OKAT+CGDCONT=1,"IP","internet.mts.ru" OKATDT CONNECT
всенепременно завершается запуском 'ATDT' и ожиданием 'CONNECT', в то время, как чат-скрипт для Ubiquam-105 завершается несколько странной строчкой ATDT#777 'CONNECT'
3.2 PPP MPPE/MPPC Подключение
Для меня это подключение, увы, оказалось несколько бесполезным: «наземное» подключение осуществляется через
CDMA–аппарат
Ubiquam-100, а он имеет свойство в моменты «затишья» выключаться. ppp-клиент, обнаружив, что связи нет, обрывает VPN соединение. Как с этим боротся, пока не разобрался. Впрочем, нет худа без добра: теперь могу подключаться к
SkyLink со сжатием данных, что очевидно экономит траффик.
Для
GPRS/
EDGE–подключения
MPPE/MPPD–подключение также оказалось бесполезным — нужные порты просто закрыты провайдером (у меня
Билайн)
Кроме того, настройка этого подключения под Linux оказалась несколько более хлопотная, чем установка, настройка и подключение через
OpenVPN. Ну да ладно, хватит жаловаться на неблагоприятные погодно-материальные условия! Начнём, пожалуй.
Не забудьте, что версии патчей должны соответствовать версиям ядра и ppp-клиента.
Начнём с ядра. Предположим, что вы распаковали исходный код яра и сделали линк на /usr/src/linux и зали в эту директорию (патч остался в папке /usr/src/linux-2.XX.XX-mppe-mppc-1.X.patch.gz) Набираем команду: gzip -cd linux-2.XX.XX-mppe-mppc-1.X.pathc.gz && patch -p1.
Далее, набираем make mrproper && make menuconfig (ну или, к чему Вы там привыкли?) И находим в разделе «Network device support» «PPP (point-to-point protocol) support» и «Microsoft PPP compression/encryption (MPPC/MPPE)». Отмечаем их для компиляции.
Кроме того, в разделе «Cryptographic API» надо отметить «SHA Digest algorithm» и «ARC4 cipher algorithm»
[15]. Сохраняем конфигурацию ядра и пересобираем его.
Теперь очередь pppd. «Раскручиваем» исходный код в какую-нибудь директорию, и накладываем патч: patch -p0 < ppp-2.4.X-mppe-mppc-1.X.patch.gz (patch (1) {между прочим, автор — знаменитый Larry Wall, автор regex'ов }) и далее делаем всё по инструкции установки: ./configure && make && make install.
Теперь надо настроить конфигурационные файлы ppp. Начнём с файлов авториации: /etc/ppp/chap-secrets. CHAP (Challenge Handshake Authentication Protocol протокол аутентификации с предварительным согласованием вызова) Открываем файл /etc/ppp/chap-secrets и дописываем туда логин/пароль, выданные провайдером для подключения в хорошо знакомом всем формате:
#<login> <server> <password> <IP-Address> mylogin * mypassword *
Далее принимаемся за файл /etc/options.pptp:
# # Lock the port # lock # # Debug option # debug # # We don't need the tunnel server to authenticate itself # noauth # # Turn off transmission protocols we know won't be used # nobsdcomp nodeflate # # # lock # # We want MPPE # mppe required,stateless # # We want a sane mtu/mru # mtu 1000 mru 1000 # # Time this thing out of it goes poof # lcp-echo-failure 10 lcp-echo-interval 10 # Handshake Auth Method +chap : # +mschap-v2
Я пробовал увеличивать значение lcp-echo-failure, но почему-то к толковому результату это не привело. Связь всё равно до обидного быстро обрывалась.
Теперь редактируем файл самого подключения. Обычно эти файлы находятся в директории /etc/ppp/peers. Свой файл назвал Raduga по имени сервиса, к которому подключаюсь.
# # PPTP Tunnel configuration for tunnel 904.d-v.ru # Server IP: 904.d-v.ru # Route: add -host 80.81.208.34/0 gw 10.252.243.159 # # # Tags for CHAP secret selection # name mylogin -pap +chap -mschap -mschap-v2 debug noauth novj nobsdcomp noproxyarp nodeflate silent
Ну вот, пожалуй и всё. Можно набрать pptp- start Raduga. Опять же, если всё правильно настроено, то вы логе Вы можете увидеть следующие сообщения:
Sep 18 00:24:17 brat3 pppd[1313]: Connect: ppp1 <--> /dev/pts/4 … Sep 18 00:24:58 brat3 pppd[1313]: sent [CHAP Response id=0x65 , na me = "MyLogin"] … Sep 18 00:24:58 brat3 pppd[1313]: rcvd [LCP EchoRep id=0x0 magic=0x39495f17] Sep 18 00:24:58 brat3 pppd[1313]: rcvd [CHAP Success id=0x65 "Access granted"] Sep 18 00:24:58 brat3 pppd[1313]: CHAP authentication succeeded: Access granted Sep 18 00:24:58 brat3 pppd[1313]: sent [CCP ConfReq id=0x1 ] …
Маскарадинг
Iptables
$> modprobe ipt_MASQUERADE # If this fails, try continuing anyway $> iptables -F; iptables -t nat -F; iptables -t mangle -F $> iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE $> echo 1 > /proc/sys/net/ipv4/ip_forward
или, если Вы используете MPPC/MPPE-подключение:
$> modprobe ipt_MASQUERADE # If this fails, try continuing anyway $> iptables -F; iptables -t nat -F; iptables -t mangle -F $> iptables -t nat -A POSTROUTING -o ppp1 -j MASQUERADE $> echo 1 > /proc/sys/net/ipv4/ip_forward
Что любопытно, теперь спутниковое подключение к Интернет будет доступно со всех компьютеров Вашей Локальной Сети.
Ipchains
Ой, разберитесь сами, не совсем понимаю, как это работает.
И последнее
Не забудьте прописать грамотно /etc/resolv.conf:
nameserver <адрес.dns-сервера.спутникового.провайдера>
Хотя, честно сказать, предпочитаю в /usr/local/bind/bind.conf прописать опцию forwarders…
5. Приложения
Конфигурационные файлы
Все настроечные файлы одним архивом:
3.
linuxsat.tar.bz2 — сама статья вместе с конфигурационными файлами и картинками в архиве
tar.bz24.
linuxsat.tar.gz — сама статья вместе с конфигурационными файлами и картинками в архиве
tar.gzВ папке
/etc присутствует разбиение на
/etc/gentoo и
/etc/ubuntu. Различия между ними, на самом деле невелики: во-первых, в
/etc/gentoo/openvpn/config/client.ovpn использована группа
nobody, а в
/etc/ubuntu/openvpn/config/client.ovpn использована группа
daemon; во-вторых, в
/etc/gentoo/init.d/dvbinit использутеся шелл
/sbin/runscript, традиционный для init-скриптов
GentOO, а в
/etc/ubuntu/init.d/dvbinit —
#!/bin/bash, традиционный для
init-скриптов
UbuntU.
С уважениемъ, ВашЫ
Ссылки
Сноски
1 не стоит путать её, с картой
SkyStar 1 CI — это несколько разные вещи, хотя утверждается, что эта карта работает вполне нормально работает с теми же драйверами. Что же до
SkyStar 1, то она довольно давно снята с производства, хотя до сих пор свободно продаётся в России и странах СНГ, но часто сгорающие на ней микросхемы питания 13/18V достать к ней очень и очень трудно. Если уж Вы решились её купить, то лучше сразу соберите себе внешний блок питания с ручным переключением напряжения. Так спокойнее будет.
Приобрести её можно, например
здесь.
2Dont flame me if it does not work for you, destroys your computer or what-not. I take no responsibility. My intention was to modify Carsten's dvbd so that it does not need patching anymore (at least for me). I also added this docs, help for line flags acceptable by dvbd, and made a few extensions inside the program - consult the top of dvbd.c file if you are wondering.
3 Что характерно, под
Mac OS X — этот вариант будет единственно приемлемым, поскольку
Ubiquam драйверов для
Mac OS X не поставляет(?), хотя, наверное, если как-следует покопаться на
Ross Barkman's Home Page, можно если не найти искомое, то вполне соорудить самому — невелика сложность. Правда, не совсем понятно, что делать с Ubiquam-UM300 — что там с PCMCIA-слотом? Найдутся-ли какие-нибудь штатные драйвера, которым можно будет «заобщать» это устройство с
Mac OS X или
Linux'ом?
Опять же, при помощи «штатного»
Нуль-модемного драйвера, любезно предоставленного на сайте
SkyLink'a,
Группа Народных Умельцев (GNU .-) по-последним слухам таки вполне соединила
U-серию c Mac OS X (ещё об этом полезно почитать
здесь) То есть, решение не очевидно, но, существует и вполне реализуемо.
Увы, информации о спутниковых картах, нормально взаимодействующими с этой операционной системой мне найти не удалось. Видимо, компьютера-роутера, с
Linux и спутниковой картой на борту, не избежать.
