Предупреждаю сразу: это пост батхерта!
Тут ко мне обратился френд с довольно простой задачей - необходимо работать из страны А с IP-адресом из страны B, но только так, чтобы адрес не палился как датацентр. То бишь с резидентным IP-шником. Нашли человека в стране B, который оказался готовым за более дорогой тариф интернета разместить у себя точку выхода VPN и попросили меня рассказать как это сделать.
Сам я давно являюсь приверженцем OpenWrt, но исходя из технического (с точки зрения прошивки девайсов кастомными прошивками) уровня моего собеседника, я понимал, что квест купить Redmi и прошить его OpenWrt не для него, а тем более не для резидента страны B. Нужно было решение, которое можно купить на местном маркетплейсе и воткнуть его. Когда-то давно я был наслышан, что Keenetic - это что-то типа брендированного OpenWrt, кроме того, на глаза попадались статьи на Хабре (правда я их не читал) о том, как на Keenetic можно взгромоздить хоть XTLS-Reality, поэтому порекомендовал обоим поставить по такому роутеру. Да и в общем-то альтернативных решений из коробки я точно не знаю больше, если не брать в расчёт Microtik - который из-за санкций я им советовать не стал.
Сказано - сделано. Дальше начинается процесс настройки. Настройка усугублялась тем, что в стране B (по крайней мере у того провайдера, к которому подключен резидент) не предоставляются (даже за доп.плату) белые IPv4 адреса - роутер получает адрес из серого сегмента 100.64.0.0/10. Зато белый IP-шник можно получить в стране A.
Наклёвывался такой setup - роутер B подключается к роутеру A, чтобы установить какой-нибудь VPN, чтобы потом гнать по этому VPN-у интернет трафик через B. В качестве протокола был выбран WireGuard так как он в этом плане симметричный: не важно, кто является сервером VPN - раздачей интернета может заниматься любой peer. Downside такой схемы в том, что по ней нету готовой инструкции, поэтому наш герой снова вернулся ко мне с задачей настройки.
Без меня они успели уже поднять WireGuard, который горел в обеих адмиках зелененьким, хэндшейки периодически обновлялись, но пинги не шли.
Приступив, мне стало понятно, что для начала не хватало банальных маршрутов. Добавили ручные маршруты и роутеры стали пинговать друг друга через WireGuard. Но дальше дело не шло - роутер на первом хопе провайдера B не пинговался с роутера A.
Первое что приходит в голову - это то, что необходимо делать NAT и подменять source IP для пакетов, приходящих на роутер B с роутера A. Потому что скорее всего маршрутизация пакетов в WAN интерфейс происходила, но роутер провайдера ничего не знал про IP-адреса роутера A, чтобы дать ответ.
И тут вот первая непонятнка с этими Keenetic'ами: роутер B успешно выполняет NAT для адресов домашней сети резидента B. Почему он это делает? Где это включается? Почему этого не происходит для пакетов с интерфейса wireguard? Все эти вопросы без ответа.
Начать с того, что управление самим NAT'ом возможно только через CLI. Тут ждал первый сюрприз. Я был уверен, что если Keenetic - это брендированный OpenWrt, то попав в него через ssh я попаду в Linux и сделаю там хоть чёрта лысого. Но вместо этого меня ждал какой-то Cisco-подобный шел с крайне урезанными возможностями. Я не являюсь спецом по кискам, и никогда их не конфигурил, поэтому я не знаю на сколько реализация CLI Keenetic соответствует кискам, но первое что меня потрясло: я могу, допустим, включить NAT командой ip nat <interface>, могу выключить командой no ip nat <interface>, но я нигде не могу посмотреть статус NAT на интерфейсе. Команда show ip nat показывает просто текущую таблицу NAT, show interface <interface> тоже вопрос не проясняла.
А нужно это хотя бы для того, чтобы понять, где его, NAT, включать и в этом ли проблема. В норме, когда настраиваешь masquerading на Linux, то вешаешь его на postrouting на исходящий интерфейс. И я бы предполагал, что и в Keenetic он будет включаться на WAN интерфейсе, для того, чтобы домашний трафик резидента B успешно "натился". Но как выяснилось в Кинетиках эта логика переиначена - включается NAT для интерфейса, через который пакет попадает в роутер. Узнал я об этом случайно, надыбав команду show running-config, которая выплевывает всю конфигурацию, и там, пролистав пару экранов, можно заметить места, на каких интерфейсах включается NAT. Офигительно удобно (нет)!
Ну что ж - включил NAT для интерфейса Wireguard0, и..... Не помогло. Я беру конфиг wireguard для роутера B и подключаюсь вместо него к роутеру A своим лэптопом с Linux, настраиваю у себя masquerading для пакетов с iifname этого интерфейса и всё работает - через меня вся домашняя сеть за роутером А успешно может ходить в интернет. Значит проблема точно на роутере B.
И вот что дальше делать - совершенно не понятно. Нет никакого способа удаленно соснифать какие пакеты отправляются на провайдерский роутер нет - tcpdump отсутствует. Да, возможно его можно поставить через opkg, но беглый гугл говорит о том, что для этого в роутер надо вставить USB-флэшку, а её у резидента B нет. Настроить логирование пакетов, что делает за 5 минут через nftables я не могу, так как к nft нету доступа. Тупик.
Пара часов гадания на кофейной гуще, и чисто случайно меняю на роурете B маску IP-адреса интерфейса Wireguard0 с /32 на /24 (изначально не я настраивал туннель), и всё начинает работать - а заодно появляется автоматический маршрут, аналог которого был добавлен руками. Что это? Почему это? Где документировано, что NAT не работает, если у интерфейса маска /32? Как вообще это можно диагностировать?
В общем первое знакомство с кинетиками меня обожгло и больше я никому не буду рекомендовать это решение.
Если тут есть представители Кинетика, то расскажите — зачем вы взяли охренительно мощный и гибкий инструмент под названием Linux и кастрировали его своим шелом? Причем безальтернативно. Лавры Apple по ограничению возможностей своих девайсов не дают покоя? Или захотелось стать киской для домохозяек? Самое печальное во всей этой истории, что команды управления сетевой конфигурацией имплементированы в какой‑то внутренней логике создателей и совершенно не понятно во что они выливаются на уровне линукса и какие side effect'ы они порождают, и что самое главное - это никак не проверить, запустив пару линуксовых команд.
Комментарии (75)
SuperTEHb
19.12.2024 11:47Когда-то давно я был наслышан, что Keenetic - это что-то типа брендированного OpenWrt, кроме того, на глаза попадались статьи на Хабре (правда я их не читал)
Так держать!
halted
19.12.2024 11:47Статья в стиле "я был наслышан, что популярная марка авто это круто и был уверен, что смогу на таком авто и 50 тонн щебёнки за раз перевезти и на морское дно опуститься и истребитель в небе обогнать".
dmitrmax Автор
19.12.2024 11:47Вы полагаете, что мне нужно было лично купить и испробовать прежде чем советовать? А мне оно зачем?
У меня такое впечатление создалось из каментов от любителей кинетиков под моими постами и постами коллег по настройке не самых типичных сценариев.halted
19.12.2024 11:47Полагаю, что оборудование надо выбирать по параметрам, а не по сарафанному радио )
dmitrmax Автор
19.12.2024 11:47По параметрам и выбрали. И поставленную задачу выполнили. Никакой ошибки с выбором оборудования не произошло. Пост о кривизне процедуры конфигурации.
dmitrmax Автор
19.12.2024 11:47Если вашу аналогию с машиной ввернуть, то получается, что когда вы покупаете машину, то вы уже глубоко в курсе того, сколько там предохранителей в щитке и за что каждый отвечает.
Хотя в реале скорее всего первое что вы будете делать, когда туда полезете - будете громко материться на тему как тяжело достаётся предохранитель из своего гнезда. =)
halted
19.12.2024 11:47Когда буду покупать машину чтобы сразу залезть под капот, то буду заранее изучать сколько там предохранителей и как легко до них добраться. Популярный сегмент на то и популярный, что он отвечает на 90% потребностей большинства, а большинство не лезет в настройки nat через текстовую консоль.
dmitrmax Автор
19.12.2024 11:47В душе не подозревал, что задача настройки NAT'а (пипец какая сложная) требует лазанья в текстовую консоль. В том же OpenWrt эта настройка вполне себе имеется на вебморде Lede. И вообще не вижу никаких проблем вынести её в вэбморду кинетика - всего-то галочку добавить в настройки интерфеса. Точнее одна проблема есть - если их модуль управления не умеет отдавать статус этого параметра, то и вэбморда не сможет отразить текущий статус.
Зато у них в интерфейсе есть загадочная галочка типа "через этот интерфейс можно ходить в интернет". К чему приводит её установка - вообще не понятно. Скорее всего будет добавлен default route, но что если таких интерфейсов несколько? Или опять расчет на то, что у 95% потребность только у одного интерфейса такую галочку ставить?
Не я сказал: но создай систему, которой сможет пользоваться только идиот, и только идиот захочет её воспользоваться.
INSTE
19.12.2024 11:47Вообще в совсем старой версии веб интерфейса возможно эта галочка была - точно не помню, но ее скорее всего убрали именно из-за того, что ей практически никто не пользовался.
А вот галочка "ходить в интернет" - очень востребована, и да, она включает использование этого интерфейса для маршрута по умолчанию. Если интерфейсов несколько, то будет реализовано горячее резервирование, и они будут использоваться для новых исходящих соединений согласно порядку на странице настройки дефолтной политики. Для входящих из Интернет будут доступны все активные в данный момент. Также эта галочка разрешает интерфейсу быть использованым в политике доступа (когда каким-то конкретным клиентам нужен доступ через конкретный WAN-интерфейс из множества).
Ну и в веб-интерфейсе возле некоторых "непонятных" галочек есть знак вопроса, при нажатии на который будет выведена подсказка, зачем он нужен и отображены связанные с этим элементом управления статьи в базе знаний. Можно воспользоваться этим инструментом в качестве справки.
edh_krusher
19.12.2024 11:47Ошибка в начале - отказались от микротик. Кинетик хорошо, но не для корпоративной среды. Шелл очень задолбал. У меня один из старых кинетиков екстра после обновления до последней версии перестал запуливать телефоны во влан вайфай клиентов, хотя все настроено, они даже адреса по дхйп от микротика получают внутри влана, но IPтрафик просто блочится и не ходить, только маки видны
dmitrmax Автор
19.12.2024 11:47Ошибка в начале - отказались от микротик.
Где гарантии, что не повториться история а-ля Meraki? Одна из двух этих стран, о которых речь в посте под санкциями.
Кинетик хорошо, но не для корпоративной среды.
Помилуйте, сударь! Какая корпоративная среда? Тут две домохозяйки на коленке борщ сварили =)
Lenar_S
19.12.2024 11:47При чем тут Meraki и Mikrotik? Meraki - это сугубо облачное решение. Mikrotik же максимум, что может сделать, это заблокировать скачивание свежих прошивок. Но мне кажется, что это можно будет спокойно обойти.
dmitrmax Автор
19.12.2024 11:47Вы, конечно, видели сорцы микротика и отвечаете, что там нет никакого "анального зонда", который при очередной проверке доступного обновления получит инструкцию "превратиться в овощ если внешний IP геолоцируется в подсанкционной стране"?
NikaLapka
19.12.2024 11:47Я люблю Кинетики, за то что уже многие годы они хорошо отображают потребности пользователей в нашей стране: надёжность и функционал, поэтому их можно встретить и в любом магазине, "-не знаете, что купить - купите кинетик", и в любом малом бизнесе, бюджетных организациях, "-нужен роутер со встроенным модемом, для торговой точки, кафе.., не знаете какой выбрать - купите кинетик", но и не только, кинетики как лакмусовая бумажка отлично показывает отношение рынка в обоих направлениях: не смогли идти параллельно с ZYXEL - "отпочковывали", есть спрос на умные и современные штуки, простой интерфейс - вот пожалуйста, нужно снизить стоимость производства - прямо сейчас можем наблюдать очередную волну снижения стоимости производства, цена как за премиальную вещь - может быть оправдано...
Кинетики - очень хорошие роутеры, и я рад что они столько лет с нами! Ну а про то что пишет автор.. на мой взгляд это всё ерунда и безграмотность автора.
INSTE
19.12.2024 11:47То, что вы считаете, что Keenetic OS является "кастрированным OpenWRT" или "другим Linux" - это исключительно ваше заблуждение. Вендор такого нигде не указывал.
Управляющий слой и система команд Keenetic OS существует со времен, когда OpenWRT еще вообще не существовало как являения (или, если хотите, продукта) доступного широкому пользователю (конец 2000-х годов). При разработке была взята ориентация на уже существовавших тогда "серьезных" вендоров, и CLI был выдержан в этом стиле. Существует подробный CLI Guide, который регулярно актуализируется (ссылка для модели KN-1011, например).
Абстракция от конкретной реализации специально выдерживается, чтобы в случае необходимости осуществлять портирование на разные архитектуры и ядра. Система команд в текущем виде существует с времен, когда основной базой SDK были ядра Linux 2.4 (без netlink и ip-route2). Также существовал проект по реализации Keenetic OS на BSD-ядре, он не был доведен до публики из-за сложностей с переносом драйверов из SDK вендоров, но такой "запасной" путь по прежнему открыт. Управляющая система не использует ничего из "классических" POSIX-like утилит и шелла для работы, потому ничего из этого не поставляется в комплекте. Управляющий модуль самодостаточен, и только вызывает крупные (навроде strongswan или nginx) внешние процессы-компоненты.
Для сбора трафика существует компонент Monitor, который можно очень легко использовать в веб-интерфейсе.
Вывод: Keenetic это продукт, который специально так сделан. Базовая и официальная часть системы не является GNU/Linux-дистрибутивом-конструктором в классическом смысле (каким является OpenWRT). Есть официальный способ запустить Linux-окружение, но это именно интерфейс для расширения пользователями, а сама система на него не полагается. Именно про этот интерфейс расширения скорее всего вы слышали в контексте "пересборки OpenWRT", но правдой здесь является то, что одним из поддерживаемых окружений является Entware, который и правда является частичной пересборкой репозитория OpenWRT. Однако это всего лишь один из вариантов, и у нас есть примеры успешного запуска полноценного Debian и Alpine в этом окружении - и вообще ничего от OpenWRT в таком случае нет.
Насчет того, что "выполняет NAT для клиентов из локальной сети" - это настраивается командой ip nat Home, которая дословно означает: "делайте SNAT для любого трафика, выходящего отсюда". Это является настройкой по-умолчанию, поскольку в варианте "из коробки" типичный пользователь ожидает именно такого поведения.
Насчет сложностей с более тонкой настройкой NAT - эта проблема известна, и происходит из давних времен, когда эта самая тонкая настройка было нужна очень малому количеству пользователей. Планируется сделать эту настройку более гибкой и очевидной, чем сейчас.
Насчет "показа статуса на интерфейсе": как минимум сама таблица показывается, но было бы очень хорошо, если бы вы показали пример того, что хотели бы увидеть на примере другого вендора, или сами подробно рассказали что там должно быть.dmitrmax Автор
19.12.2024 11:47То, что вы считаете, что Keenetic OS является "кастрированным OpenWRT" или "другим Linux" - это исключительно ваше заблуждение. Вендор такого нигде не указывал.
Не заблуждение. Наличие OPKG разбивает этот домысел, ровно как и вызов команды more по паре файликов из /proc. Обещаний, что там чистый линукс или какой-то дистриб, конечно, не было, но делать вид и прикидываться, что я тут слеп и не вижу, что там под капотом, я не буду )
При разработке была взята ориентация на уже существовавших тогда "серьезных" вендоров, и CLI был выдержан в этом стиле.
Ориентация взята, но получилось не очень (ИМХО, разумеется) и главное не понятно зачем. Keenetic явно не делает продукты для бородатых дядей из махрового Ынтырпрайза с сертификатами Циски. А рядовому юзеру погружаться в этот стиль довольно странно. И повторяю вопрос заданный вскользь в посте. Как узнать текущее значение какого-нибудь параметра, который вы можете менять командой или её отрицанием через "no"? Как узнать командой текущий статус (вкл или выкл) NAT на интерфейсе? И вообще без привязки к этому злощастному нату: как узнать включен ли или выключен ssh? Как узнать текущее значение таймаута сессии ssh? Без всего этого управление устройством является write only.
Это является настройкой по-умолчанию, поскольку в варианте "из коробки" типичный пользователь ожидает именно такого поведения.
Я ничего не имею против настроек по умолчанию. Я (как уже упоминал выше) против того, чтобы нельзя было эти настройки как-то обозреть, кроме как скопом командой
show running-config, что тоже не очевидно.Насчет "показа статуса на интерфейсе": как минимум сама таблица показывается
Таблица может быть пустой, если нет текущих tracked соединений. Но это вовсе не означает, что NAT выключен. Кроме того, по таблице совершенно не понятно к какому интерфейсу относится настройка приведшая к попаданию конкретной строчки в эту таблицу. Так что наличие таблицы никак не заменяет указания статуса NAT на конкретном интерфейсе.
но было бы очень хорошо, если бы вы показали пример того, что хотели бы увидеть на примере другого вендора, или сами подробно рассказали что там должно быть.
Без относительно NAT'а, а вообще касаемо любой настройки хорошо бы иметь что-то вроде
get ip nat Homeи получать в ответ enabled/disabled или конкретное значение параметра:get ip ssh session timeout- 60 seconds, например.Насчет сложностей с более тонкой настройкой NAT - эта проблема известна, и происходит из давних времен, когда эта самая тонкая настройка было нужна очень малому количеству пользователей. Планируется сделать эту настройку более гибкой и очевидной, чем сейчас.
Как таковой проблемы с настройкой NAT тут не было. Проблема была в том, что он по всей видимости не работал будучи настроенным, а после того, как поменяли маску адреса интерфейса вдруг заработал. Не совсем понято зачем и для чего модуль управления смотрит на маску, принимая решение переопределить волю администратора. Но если он так делает, то не плохо бы об этом написать, например, в консоль.
Именно про этот интерфейс расширения скорее всего вы слышали в контексте "пересборки OpenWRT", но правдой здесь является то, что одним из поддерживаемых окружений является Entware, который и правда является частичной пересборкой репозитория OpenWRT
Скорее всего да.
INSTE
19.12.2024 11:47То, что он сейчас построен на ядре Linux - факт, но он не гарантирован, и может быть изменен без уведомления. Мы не публикуем историю версий ядра, libc, компилятора и прочих внутренних вещей, что ожидалось бы от полноценного дистрибутива, только те вещи, которые могут быть заметны пользователю, внутренняя механика максимально прикрыта. Пользователю мы гарантируем сохранение настроек и внешнего поведения при обновлении.
Текущее значение каждого параметра описано в cli guide, ссылку на который я привел. Если команды нет в конфиге явно, то оно имеет значение по умолчанию. А насчет "косплея"
С NAT все просто - если есть команда ip nat <iface>, то значит NAT есть, иначе его нет. Какое-то особое состояние, не существующее в конфиге, для нее отсутствует.
Получение значения по умолчанию для произвольной команды, даже если ее нет в конфиге - здравая идея, но вообще вы первый (!) на моей памяти, от кого я слышу такой запрос. Конструктивные запросы мы слышим и по мере сил стараемся реализовать. Сейчас есть похожий механизм для получения значений по-умолчанию, но он сделан далеко не для всех команд и нужен только чтобы веб-интерфейс на странице смог вывести значения "по-умолчанию". Возможно его стоит обобщить для всех команды и сделать видимым пользователю.
-
Про маску так и не стало понятнее, если честно, слишком много вариантов. Но если вы придете в техподдержку и пришлете self-test, то с удовольствием посмотрим, что же там "не срабатывает".
dmitrmax Автор
19.12.2024 11:47Про маску так и не стало понятнее, если честно, слишком много вариантов. Но если вы придете в техподдержку и пришлете self-test, то с удовольствием посмотрим, что же там "не срабатывает".
Роутеры настроены, доступа у меня больше к ним нет, да их химичить в обратную сторону ради багрепорта мне не дадут скорее всего. Других кинетиков, на которых можно воспроизвести баг и сделать self-test у меня нет.
Сейчас есть похожий механизм для получения значений по-умолчанию, но он сделан далеко не для всех команд и нужен только чтобы веб-интерфейс на странице смог вывести значения "по-умолчанию".
Сдаётся мне, что поэтому же и настройка NAT у вас не вынесена в вэбморду. Хотя казалось бы: чего проще добавить одну галочку в настройки интерфейса. Lede справляется силами вэбморды с этой же задачей, к слову.
figachit
19.12.2024 11:47Влезу в ваш разговор. Была такая ситуация: Keenetic 192.*, в сети был сервер виртуализации 192...2, его виртуалки 10.*. Прописал маршрут до них, всё пробовал, убился — ну не имеют они доступ в интернет. После общения с вашей поддержкой получил команду ip nat ..., добавил, заработало. Но обратил внимание, что нигде узнать статус нельзя, кроме как в дампе конфигурации.
dmitrmax Автор
19.12.2024 11:47Есть официальный способ запустить Linux-окружение, но это именно интерфейс для расширения пользователями, а сама система на него не полагается. Именно про этот интерфейс расширения скорее всего вы слышали в контексте "пересборки OpenWRT",
Я вспомнил, где я про это слышал. https://github.com/keenetic/keenetic-sdk - тут написано: Keenetic SDK is based on the OpenWrt project (https://openwrt.org/). We recommend to read the OpenWrt build system manual (https://openwrt.org/docs/guide-developer/build-system/use-buildsystem) before following the next steps.
Я видимо не разобрался в том, что это за SDK и что оно к прошивке мало отношения имеет
dartraiden
19.12.2024 11:47KeeneticOS основана на OpenWrt, но именно, что "основана". Там под капотом уже очень много различий.
Поддержка "OPKG" (а точнее - Entware) это не показатель. Entware можно развернуть и на таких прошивках как ASUSWrt или Padavan. Вы же не называете асусовскую прошивку "кастрированной OpenWrt"?
Наконец, какая же она "кастрированная"? OpenWrt имеет что-то похожее на KeenDNS? Я могу накатить OpenWrt, "из коробки" получить уникальный домен третьего уровня и через него иметь удалённый доступ к роутеру, находящемуся за провайдерским NAT?
NetBUG
19.12.2024 11:47Более того, opkg вроде был в yocto и куче других LEDE-based фиговин
Общего там ядро и glibc
dmitrmax Автор
19.12.2024 11:47KeeneticOS основана на OpenWrt, но именно, что "основана". Там под капотом уже очень много различий.
О чем мы ломаем копья с этим OpenWrt? О том, что я написал, что "KeeneticOS является чем-то вроде брендированного OpenWrt".
По итогу одни пишут тут, что вообще никакого отношения не имеет. Вы пишите, что всё-таки основана на OpenWrt. Но в сущности: какая разница? Даже если это совсем не так, основной посыл статьи был в том, что этот самый keenetic shell отрезает возможности использования нижележащего Linux на 100%. Я бы согласился с тем, что сосуществование двух механизмов управления (через кинетиковский шел и, скажем, posix shell в имплементации какого-нить busybox) чрезвычайно сложно подружить. Но можно было бы написать большими буквами, что все изменения настроек через утилиты Linux не сохраняются. Зато остался бы способ анализа состояния системы утилитами. Вывести тот жеnft list ruleset, чтобы понять, где там затык произошел.OpenWrt имеет что-то похожее на KeenDNS? Я могу накатить OpenWrt, "из коробки" получить уникальный домен третьего уровня и через него иметь удалённый доступ к роутеру, находящемуся за провайдерским NAT?
Очевидно, что OpenWrt - это некоммерческий проект, который не предоставляет никаких облачных сервисов на своей инфраструктуре. Поэтому сравнивать прошивку с сервисами довольно некорректно. Но если я правильно понял ваш use case, то можно штатными средствами (opkg, включая вэбморду LEDE) установить cloudflared и воспользоваться похожим сервисом Cloudflare Tunnel.
igrblkv
19.12.2024 11:47Да, OpenWRT поддерживает DDNS на Ваш выбор.
Но без белого ИП доступа не будет.
Ellise
19.12.2024 11:47Насчет того, что "выполняет NAT для клиентов из локальной сети" - это настраивается командой ip nat Home, которая дословно означает: "делайте SNAT для любого трафика, выходящего отсюда". Это является настройкой по-умолчанию, поскольку в варианте "из коробки" типичный пользователь ожидает именно такого поведения.
Нет, не совсем так. И это боль. Не "делайте SNAT для любого трафика, выходящего отсюда" - а "делайте SNAT для любого трафика исходящего из подсети заданной на интерфейсе."
То есть для сети которая лежит где-то дальше за данным интерфейсом (и в эту сеть есть маршрут через этот интерфейс) - SNAT не будет.
MK_Ultra
вы кинетик не перепутали с GL.Inet?
dmitrmax Автор
Нет. GL.Inet в этих краях не купить.