knockProxy

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

В общем, началось с того, что хотелось получить сравнительно безопасный способ доступа извне домой или на работу. Для начала были проанализированы следующие варианты

Прямой доступ

Неплохой вариант, простой для использования, но есть нюансы. Первый, нельзя добраться до машин за NAT'ом, но это можно решить пробросом портов на шлюзе. Второй, более существенный, открывать доступ снаружи даже к одному сервису весьма неприятно в плане безопасности. Неверная настройка сервиса или security issue в нём, и твой компьютер уже как бы не твой. Ну или взять RDP в домене — можно не спеша перебирать логины и пароли всего домена, и если повезёт с одним каким-нить забытым тестовым логином, внутрь уже залезает злоумышленник. Так что этот способ отпадает

VPN

Отличный способ, постоянно использую. Положительных качеств вагон и маленькая тележка: работа с NAT'ом, видна вся сеть, сжатие и шифрование трафика при желании. Но есть один недостаток: сложная настройка. Например, самый простой для системы PPTP не работает на домашнем интернете от Билайна (ибо у них тоже PPTP, а PPTP over PPTP это слишком сложно). А универсальный OpenVPN требует телодвижений по настройки как на клиенте, так и на сервере. Одного логина с паролем не хватит. Так что хотелось бы что-то более простое.

IPSec

Отличная штука, можно загнать в транспортном или туннельном режиме, позволяет делать гарантированно работающие туннели, но чтобы хорошо настроить, надо очень сильно потрудиться. Если по какой-то причине он отказывается работать, то можно долго и упорно тыкать галочки, пока не отживеет. Ну и красивый IPSec без статичных IP, да так, чтобы не завалить всех остальных — сделать не очень легко. В результате, можно потратить много времени на настройку дом-работа, но уже с ноутбуком в поездке работать ничего не будет. Так что этот вариант отложен до лучших времён.

Отдельная программа для связи

Например, что-то типа TeamViewer. Платно и неспортивно.

Свой велосипед

Моё любимое занятие. Ибо точно знаешь что программа умеет, что нет, и какая область применения.
Итак, был написан свой велосипед knockProxy, на node.js, лежит на ГитХабе. Я думал следующим образом: самый удобный вариант, это прямой доступ, но напрямую доступ давать нельзя. Так будем его выдавать после ввода логина и пароля (отдельного, чтобы сузить область возможной атаки). Бонусом, дадим несколько логинов для разных пользователей.

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

Открытие дырки можно было сделать двумя способами: прописыванием правил в фаирволле (хорошо настраивается, но плохо портируется) или ручным пробросом (универсально и дубово), что я и сделал. В результате, необходимо знать только дополнительный логин и пароль и можно входить с любого устройства (например с телефона в поезде).

Но, естественно, есть недостатки, например, доступ только на один порт (я предпочитаю RDP), что для полноценной работы не хватает. Зато хватает быстро посмотреть. Второй, более существенный недостаток — соединение по этой дырке по-хорошему должно быть шифрованное. Иначе, где-то в кафе по WiFi могут утечь секурные данные. Но RDP шифруется, правильный VNC тоже, так что для них это не существенно. Обойти данную проблему можно созданием ручного туннеля, но тогда придётся настраивать клиента, что совершенно не подходит в плане удобства (уж лучше честный VPN).

Также, данную штуку можно использовать как хитрый TCP port forwarder, если есть желание, но для этого есть более простые штуки. Что ещё с ней делать, пока не придумал, но в принципе это не важно, главное, чтобы хотя бы одна задача выполнялась на отлично.

Для тулзени выбрал лицензию MIT, для работы нужен node, и какой-нить сервер с мордой наружу (нужен прямой открытый TCP порт). Веб-часть может при необходимости жить через proxy, хотя больше любит напрямую. Работает и под *NIX и под Windows. Наверное и под маком может жить. Так что универсальность полнейшая.

В общем, прошу любить и пользоваться.

Microsoft EDGE

Смотрю я на данный браузер и поражаюсь, Microsoft в очередной раз сосредоточилась не пойми на чём, вместо того, чтобы сделать удобный браузер. Вся реклама основана на том, какой он быстрый, хотя в реальности ничего особо быстрого нет, обычный средненький по производительности браузер. При этом, в плане использования всё очень плохо, и видны торчащие ноги из IE.

Собственно по пунктам, банальные вещи, которые видны сразу:

• Если обратиться к сайту на нестандартный порт, браузер не догадается что он предназначен для http и с упорством дебила пойдёт гуглить, что же ему подсунули. Ну детский сад же... UPD: это исправлено, претензия снимается
• Восстановление сессий, вроде бы старая и must have фича, по-прежнему работает некорректно. А именно, постоянно восстанавливается куча пустых вкладок. Откуда, блин, он их берёт?
• При запуске, если система тормозит, то при попытке ввести адрес, добрый браузер сотрёт его, и нарисует вместо него свою домашнюю страницу. Блин, я уже собираюсь уйти куда мне надо, не решай за меня!

Все эти пункты тянутся с IE и до сих пор не пофикшены, хотя в любом другом браузере — работают гораздо лучше. Неужели разработчика браузера запрещено смотреть на другие, не дай бог, сделают что-то удобное.

При этом в Edge оторвали всё хорошее из IE — акселераторы, фрагменты, плагины. Интерфейс теперь стал одним из самых габаритных среди других браузеров (а раньше хвалились, что они экономят место), окна браузера теперь все объединены в один значок, а не делятся на отдельные как в IE...

В общем, в очередной раз, Microsoft решила всё переделать, но начала переделку с копипейста и отрывания функционала. Буду с нетерпением ждать очередной реинкарнации браузера и рассказов о том, насколько теперь он быстрее.

Проблемы REST API или Яндекс тоже лажает

Вчера заметил лажу Яндекса в реализации REST API и решил немного высказаться про идеологов правильного использования REST.

Под данными идеологами я понимаю людей, которые месяцами выбирают HTTP-метод (PUT или PATCH? Сложный выбор!), вылизывают урлы (так, /user/add/group или /group/add/user, или POST /, а остальное данными?), при этом по факту никому их API никогда не нужно, а если и нужно то используется через врапперы и библиотеки.

Красивые урлы и семантика, конечно, важна, но проблема в том, что REST работает через HTTP со своими заморочками и ограничениями. Например, в GET нельзя закидывать body, и надо пытаться засунуть всё в URL, а если не влезает, то сделать POST, получить ID запроса, и сделать GET. Идиотизм. зато семантично.

Или моё любимое: по стандарту GET-ответы кешируются, если не сказано иное (хотя хрому наплевать на это). Звучит разумно, например, мы получаем текущую фазу луны, никаких параметров, она всегда одинаковая, хотя... стоп... Давайте что-нить попроще, например количество входящих сообщений пользователя... блин... Пол пользователя! Во! Главное, чтобы он к врачу не сходил. В общем, если умерить сарказм, то получается, что GET-запросы для API практически никогда не надо кешировать, ибо хоть они и получают данные, но те данные имеют тенденцию меняться в самый непредсказуемый момент.

Решений для убирания кешироания несколько:

• С сервера посылать запрет кеширования. Работает, но несемантично
• К каждому запросу подсовывать рандомную строку. Работает, но выглядит ужасно и по факту засираем кеш браузера
• Переделать API так, чтобы в нём участвовала рандомная строка. Например, дать количество сообщений пользователя на определённую дату. Пофиг, что кроме текущей мы ничего не можем сделать, зато прикрутили параметр
• Делать POST, а потом GET - очень глупо, медленно, неудобно, но семантично

В общем, вместо того, чтобы тупо сделать всё на POST'ах, мы активно боремся с инфраструктурой. И подобные проблемы периодически возникают то тут, то там. И борьба с ними идёт в основном ради красоты.

К чему всё это я — моё мнение, если вы не пишете могучее API для использования миллионами людей, то и не парьтесь, а если пишете — то сделайте SDK для него, и тоже не парьтесь. И все будут счастливы, кроме горстки перфекционистов.

Собственно, а что с Яндексом? Дело в том, что недавно они написали умную статью, о том как работать с HTTP, типа учитесь как правильно. Ок, поучился. Захожу на internet.yandex.ru и вижу картину следующего вида:

Естественно, со временем всё было в порядке. Просто я обновил данную страницу в браузере, а запрос о времени, сделанный по всем правилам Яндекса по урлу http://yandex.ru/internet/api/v0/datetime/ не имел никаких параметров кеширования. Что привело к тому, что браузер честно отдал ответ, который он запомнил 6 часов назад.
Как видите, Яндекс умеет делать красиво, рассказывать всем как правильно, только выкатывает в итоге нерабочий сервис.

UPD: Увидел ссылку, которая описывает архитектурные проблемы REST чуть в другом ключе, но пересекается с данным постом и я с ней в целом согласен. Также, могу сказать, что в одном из проектов я использовал JSON-pure API, и с ним не было никаких проблем. Данный код до сих пор бродит по разным проектам и не вызывает нареканий.

Чудесатые интернеты

Решил написать про бредовую ситуацию, с которой я сегодня столкнулся. Связана она была с настройкой виртуалки в Амстердаме у Infobox.

Итак, есть виртуалка, вроде бы всё работает, но при попытке достучаться по самбе, получаю ошибку. Фактически, блокируются 135, 139 и 445-ые порты. Я поплясал с бубном, помучал фаирвол, всё бестолку. В конце-концов, решил проверить доступ с внешней машины. Он был. В полном офигении, я начал копать проблему дальше, и выяснил следующие факты

1. Любой порт кроме этих трёх работает корректно
2. Эти три порта работают корректно из любой доступной мне сети (и интернет-утилит), кроме рабочей
3. Из рабочей сети доступ на данные порты на другие внешние сервисы открыт и работает
4. Никаких запретов на подобное во внутренней сети нет

Т.е., фактически получается, что или провайдер, или хостер рубят эти три порта, именно для нашей сети или для сети хостера. Совершенно безумная ситуация, которая по идее невозможна, а если возможна, то кто-то ведёт себя очень плохо.

Есть, конечно, другой вариант. Он заключатся в том, что я таки сошёл с ума, и мне всё это кажется. С учётом бредовости ситуации, этот вариант допустим.

Вот так, блин, и работаем.

UPD: Оказалось, что это посредник Инфобокса блокирует часть портов, почему-то считая именно эти "небезопасными". Причём, блокирует только с части сетей. Признались они только после длительной переписки с саппортом.

Управление виртуалками для обычных пользователей в Hyper-V 2012 R2

Microsoft иногда очень оригинально относится к безопасности. Перекроет все щели так, что прорваться могут только админы. А потом начинает ныть, что же все сидят под админами. Ну, может быть, потому что кто-то ленится подумать про права?

В своё время, Microsoft выпустила сервер виртуализации Hyper-V, весьма неплохой, хоть и со своими тараканами. И там можно было сделать замечательную вещь: выдать пользователю права на виртуалку, которая крутится на сервере. Т.е. он мог её включать, выключать, дёргать у неё сеть, но при этом, он постоянно к ней подключён, и в тоже время не видит соседей.

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

К сожалению, чтобы раздать эти права, необходимо было произнести несколько могучих заклинаний, сжечь в полнолуние крыло летучей мыши, и попрыгать на левой ноге. Эти действия неплохо описаны в данном блоге. Единственный плюс, что всё-таки появились скрипты для автоматического выкатывания солнца.

Зато, после всех этих мучений, можно было весьма гранулированно раздавать права через AzMan (я, кстати, первый раз его видел, хотя, судя по всему, существовал в системе давно, с XP. Но мы-то знаем, что Microsoft не ищет лёгких путей и всегда есть по крайней мере три несовместимых технологии).

К сожалению, в 2012 R2, эта магия больше не работает. Всё сломано. Мне понадобилось достаточно длительное время, чтобы понять это, т.к. народ умудряется писать статьи о том, что всё таки работает. Не работает. Проверено. С большим скрежетом, я всё-таки нашёл, что можно с этим сделать. А сделать можно только одно: давать пользователю подключаться, к виртуальной машине. Т.е. включить он её не может, но хотя бы может работать с ней. Для того, чтобы как-то добавить права, судя по всему нужна отдельная прослойка, которая со своими жирными правами будет всё делать, уже сам раздавая права. Данной прослойкой может быть System Center Virtual Machine Manager или что-то своё самописное (можно добавить имперсонацию и рулить юзерами, действия тупо выполнять через PowerShell). Но само подключение можно реализовать чуть проще, хотя и не очень очевидно.

Собственно, для возможности подключения пользователя (не админа) к определённой виртуалке надо сделать следующее):

1. Выдать права на виртуалку через PowerShell
   Grant-VMConnectAccess -ComputerName host_name -VMName vm_name -UserName user_name
   Есть ещё команды Get-VMConnectAccess для просмотра прав и Revoke-VMConnectAccess для отбирания
2. В PowerShell выяснить id-нужной нам виртуалки
   Get-VM -ComputerName host_name | select id,name
3. Установить Remote Desktop Connection Manager (стандартный не катит)
4. В нём сделать новую группу, в группу добавить сервер, на вкладке Server Settings поставить VM Console Connect, ввести нужный Id и сохранить всё это дело

После этого можно пользоваться прямым подключением к виртуалке (возможно придётся открыть ещё порт 2179).

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

Ещё одна проблема HttpWebReqest

Я уже писал про грабли HttpWebRequest, но тут нашёл ещё одну забавную, и местами неприятную. Правда наполовину она относится к HttpWebResponse, но классы связаны метровым канатом, так что не принципиально.
Вкратце: работа с куками организована очень оригинально, и не очень логично.

Для удобства распишу по условным пунктам. Для начала диспозиция:

• Сервер возвращает куки в Http-заголовке Set-Cookie
• Если надо установить две куки, сервер передаёт два заголовка (не очень логично, но ок)
• HttpWebResponse имеет пропертю Headers, и по имени заголовка можно получить значение

Тут начинаются проблемы, ибо куки две, а заголовок один. Как вы думаете что вернётся? Не буду томить, скажу, что вернётся в этом методе содержимое двух кук через запятую. Очень, блин удобно. Считаем, что куки у нас разломаны в этом виде.

Но! У Headers можно взять значения через .GetValues(), вернётся честный массив из двух элементов. И вроде бы всё хорошо, и пост можно жакончить, но тут приходит сервер, и выдаёт нам:

Set-Cookie: ABC=123; expires=Fri, 31 Dec 2010 23:59:59 GMT; path=/;

Вы заметили, что между пятницей и 31-ым числом есть запятая? HttpWebResponse тоже заметил, и вместо этой куки честно вернул нам две, обе разломанные. Всё, приехали.

Но обойти это надо, поэтому можно сделать следующие вещи:

• Вручную распарсить значения кук, зная, что запятая, по стандарту, запрещённый символ. Т.е. встретится она может только в expires
• Взять у HttpWebResponse пропертю Cookies, с уже обработанными куками

Вроде второй вариант самый правильный и логичный, за исключением случаев, когда вам хочется посмотреть на изначальные данные от сервера, а не обработанные странным кодом. Но чтобы он работал, надо обязательно, у HttpWebReqest установить пропертю CookieContainer, иначе вам вернётся пустой массив в респонзе.

request.CookieContainer = new CookieContainer()

Немного нелогично (нам ведь только ответные нужны), но в принципе допустимо. И всё из-за весьма странной реализации работы с заголовками.

На этом всё, буду ловить очередные грабли данного класса. 

Немного про починку винды через много букв

Я уже писал про то, что надо бекапить самое ценное у винды, как что-то сделать с упавшей виндой, и как работать с реестром в не загружающейся.
Сегодня чуть-чуть расскажу про то, что можно сделать, если винда пережила экзистенциальный кризис, но загружается и местами пытается работать.

В качестве примера буду приводить систему, с которой недавно боролся после того, как она сама себе испоганила диск. Точнее не она, заглючил RAID-контроллер и вместо обеспечения целостности запорол кучу файлов (похоже писал данные не в те блоки), потом он, конечно, отправил систему в синий экран, но это было уже потом.

Винда, с трудом но поднялась после всего этого, правда для этого пришлось починить несколько важных для загрузки файлов и собрать монстра из реестра (комбинация из встроенного бекапа в C:\Windows\System32\config\RegBack\ и основного реестра), но в общем-то фатальных проблем не было.
Правда при работе слегка глючила, не давала подключиться удалённо, плюс были ещё мелкие и не очень проблемы (некоторые выявились только спустя несколько месяцев).
Что можно с этим сделать, и как чинить?

Вариант 1. Апгрейд винды на саму себя из установочных файлов

Винда бережно сохраняет все настройки и восстанавливает их в новой системе. Но есть проблема, могут сохраниться ошибочные настройки, а часть данных не перенесётся, причём лучше уж поломанный сервис, который ты знаешь, что надо починить, чем рабочий, у которого потерялась какая-то хитрая настройка, и из-за этого он поведёт себя не так как надо.
Так что этот способ не очень хорош, кроме того требует некоторого даунтайма системы (на установку и настройку сервисов снова). У меня был один такой системный сервис, который очень не хотелось трогать (и да, он разваливается при переустановке, можно поднять его из бекапа, и потом донастроить).
Так что я пробовал другие способы

Вариант 2. sfc /scannow

Способ, который рекомендуют на всех форумах, к сожалению помогает он плохо, т.е. ничего не лечит (ему неоткуда взять корректные файлы при серьёзных повреждениях), но зато создаёт логи в C:\Windows\Logs\CBS\CBS.log, с помощью которых можно узнать повреждённые файлы и физически заменить их с аналогичной системы (тут очень помогает Far, который достаточно вольно относится к отсутствию прав на файлы (т.е. если есть права выдать себе права, но в данный момент их нет, а приказ что-то сделать с файлом есть, фар решит эту проблему самостоятельно). Без фара можно ручками выдавать права на проблемные файлы, меняя владельца с TrustedInstaller на себя и раздавая права (если хочется красоты, следующий запуск sfc /scannow всё починит).
Таким образом я починил большинство проблем и система жила, пока не потребовалось ещё кое-что настроить.
Но для начала

Вариант 3. dism

Утверждается, что свежая винда может себя починить через следующую команду:

DISM.exe /Online /Cleanup-image /Restorehealth

или

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess

Первый способ обещает починить файлы через Windows Update, второй использует локальное хранилище в случае невозможности подключиться.

Вкратце: способ мне не помог, хотя что-то делал и явных ошибок работы не выдавал. Тем не менее, он много каши не просит, поэтому стоит его попробовать.

---

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

Итак, на первый взгляд проблемы появились в том, что не ставились апдейты. Изучение ошибок и логов привело к парадоксальному результату: они не ставились, потому что валился Task Scheduler со статусом что-то типа Initialize::UserTable (за точность ошибки не ручаюсь, ибо по памяти). Т.е. совершенно невменяемая ошибка. Были перепробованы все средства, пока не оказалось, что проблема в том, что в управлении пользователями отсутствовали локальные пользователи, а при открытии групп вылезало две ошибки с чтением данных. Т.е. проблема не в этом, а в том что есть именно проблема с пользователями. При этом из консоли (net user, net localgroup) проблем явных не было.

Тут я полез уже в дебри и выяснил следующее:
Вся информация о пользователях хранится в ветке реестра SAM, которая в реестре замаплена на HKEY_LOCAL_MACHINE\SAM. Если вы откроете ветку сейчас, вы ничего там не увидите. Рекомендую добавить себе права.
Там всё внутри устроено оригинально и не так как в остальном реестре. В частности, есть группы пользователей (SAM\Domains\Account\Aliases) и сами локальные пользователи (SAM\Domains\Account\Users). Они идентифицируется неким id, а сопоставление имён и id идёт в отдельном разделе (SAM\Domains\Account\Users\Names\), где в качестве типа указан данный id. Т.е. не значение, а тип. который обычно DWORD, STRING, BINARY. Впрочем, это можно списать на особенности отображения и то, что этот раздел не предназначен для обычных глаз.
У пользователей есть бинарные параметры F и V, а у групп С, которые содержат описание объекта, SIDы, и кто кому принадлежит.
В моём случае, были повреждены разделы C (их тупо не было) у групп администраторов и пользователей, и был один повреждённый пользователь (хотя визуально он был в порядке.
Эти проблемы и вызывали странное поведение в управлении пользователями.
Если хочется тут что-то сделать, вначале делаем бекап, потом играемся как хотим. У нас есть возможность откатиться.
Эмпирическим путём проблемный пользователь был вычислен и уничтожен (удалением ветки реестра), пользователи вернулись в норму. Раздел C, был импортирован с соседнего компьютера и всё ожило (Планировщик, а вместе с ним и апдейты. То ли у них были проблемы с группами, то ли с пользователем). К сожалению, в управлении группами в этих группах появились неизвестные SIDы (неудивительно, с таким-то импортом), которые не удалялись, а также не добавлялись новые пользователи.

Наилучшим решением проблемы я посчитал следующее (очень не хотелось разбираться в бинарной структуре данных записей, не стоит оно того). Например, у нас проблемная группа Administrators. Создаём группу Bdministrators. В эту группу добавляем нужных пользователей (самого администратора, например). Экспортируем из реестра обе группы по отдельности. Переносим бинарные данные из экспортированного файла от Bdministrators в Administrators, и импортируем его назад. Тем самым, у нас появились правильные администраторы (с правильным id), но неправильным именем. Ну, тут открываем в редакторе реестра бинарный редактор и меняем код байтика, отвечающий за B, на A. Всё, у нас правильные администраторы. Лишнюю группу удаляем, чтобы не мешалась. Повторяем тоже самое для других групп.
Результат — всё красиво и работает.

---

На этом пока всё. Я рассказал как чинить файлы, и что можно сделать с реестром. После этого, при желании винду можно восстановить почти из любого состояния, вопрос только целесообразности. А я буду ожидать очередного безумного сюрприза от очередной системы, но также буду надеяться, что он случится когда-нибудь попозже.