С помощью утилиты beep под Linux
Как следует из ранее изложенного, ничего сверхъестественного не обнаружилось, и для того, чтобы воспользоваться этим VPN, требовательный к железу Debian 9 x64 не нужен совершенно. Bitmask тоже не нужен. Проблемы могут возникнуть разве что с виндой, а вот с линуксов вполне можно раздавать VPN-интернет на другие устройства в локальной сети, в т.ч. и на виндовые компьютеры. Без bitmask это даже лучше получается, поскольку он пакостит в iptables. Пакостит, правда, для «более лучшей» защиты пользователя. Но в данном случае получается, как у Черномырдина — хотели как лучше, получилось как всегда.
Первым делом надо составить конфиг для Openvpn. Не буду каждый параметр пояснять, а ссылка на сами конфиги есть в конце заметки. Вроде составил правильно, по ранее извлеченным параметрам Openvpn. Единственное что добавил от себя, это запуск пользовательских скриптов — параметры script-security 2, разрешающий оный запуск, и параметры up '/путь/к/скрипту up' и down '/путь/к/скрипту down', указывающие Openvpn, какой скрипт надо запускать при, соответственно, установке и разрыве соединения.
Про подобные скрипты я совсем недавно упоминал.
Переделывался из ранее приведенного примера с небольшими изменениями:
#!/bin/bash
#заводим человеческие переменные
MAIN_STAT=$1 #up/down
DEV_NAME=$2
TUN_MTU=$3
LINK_MTU=$4
LOCAL_IP=$5
REMOTE_IP=$6
ADD_STAT=$7 #init/restart
#путь к ip и iptables
ACPATH="/usr/sbin/"
# [...]
#соединение поднялось
if [ "$MAIN_STAT" = "up" ]; then
#установка маршрута по умолчанию
"$ACPATH"ip route del default #удаление старого
#установка нового
#именно так, локальный ip и удаленный - один и тот же
#особенность провайдера Oo
"$ACPATH"ip route add default via $LOCAL_IP dev $DEV_NAME src $LOCAL_IP
#разрешение транзитного трафика
"$ACPATH"iptables -P FORWARD ACCEPT
#установка адреса DNS-сервера
echo "nameserver 10.42.0.1">/etc/resolv.conf
exit
fi
#соединение разорвано
if [ "$MAIN_STAT" = "down" ]; then
#запрет транзитного трафика
"$ACPATH"iptables -P FORWARD DROP
#установка маршрута по умолчанию без VPN
"$ACPATH"ip route del default
"$ACPATH"ip route add default via 10.10.1.1 dev eth1 src 10.10.20.55
#восстанавление адресов DNS по умолчанию
echo "nameserver 8.8.8.8">/etc/resolv.conf
echo "nameserver 8.8.4.4">>/etc/resolv.conf
fi
Основная особенность в том, что сервер, вместо REMOTE_IP, передает маску подсети, а чтобы маршрутизация осуществлялась правильно, вместо удаленного IP надо прописать выданный сервером локальный.
Долго с этим разбирался, т.к. поначалу был глюк — транзитный трафик проходил, а вот локальный нет. Помог выхлоп ifconfig:
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1500
inet 10.42.0.2 netmask 255.255.248.0 destination 10.42.0.2
inet6 2001:db8:123::1000 prefixlen 64 scopeid 0x0
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 982346 bytes 1307345786 (1.2 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 541554 bytes 27027659 (25.7 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
Вторая важная особенность — надо прописать правильный DNS.
И не забыть передать его клиентам, если компьютер используется в качестве PPTP- или другого VPN-сервера.
ЗЫ. Если будете пользоваться сервисом riseup.net, по возможности донатьте, хорошее дело ребята делают. Фиг где в мире встретишь таких альтруистов.
Предыдущие части заметки
Часть 1. копия
Часть 2. копия
Скачать все в PDF
На PasteBin:
Голландия
Канада
США
http://riseup.net
Регистрация Riseup Black
О Riseup
Донат
Puppy по сети грузится, но с некоторыми проблемами. А именно, для полноценной загрузки ОС требуется файл puppy_slacko_X.X.sfs, содержащий основные файлы ОС.
Этот файл сам по себе по сети не подгружается. Можно, конечно, подшаманить в initrd и сделать так, чтоб файл подтягивался по tftp или с расшаренной папки, но это довольно нетривиально.
Есть другой способ — записать в initrd главный sfs. Правда, initrd раздуется от этого (аж до 150 Мб с гаком) и на совсем слабых машинах Slacko не загрузится. Но 512 Мб оперативки вполне хватает. Тестировано на селероне 1.7 с 512 Мб ОП.
Мы нашли на murga-linux скрипт, который автоматизирует данный процесс. Ссылки на оригинал не будет, т.к. никто уже не помнит, где качали. 🙂
Получение данных для нормального запуска VPN, без bitmask и на любом линуксе.
1. Ставим Debian x64. Я ставил 8.10 на виртуалку в VMWare 9 с netinst установщика, при установке можно выбрать LXDE, чтоб быстрее поставилось и тянуло меньше ерунды с инета.
2. Заходим в консоль и переключаемся под root
su
3. Обновляем списки пакетов после установки (из консоли)
apt update
4. Для удобства можно поставить mc
apt install mc
4. Ставим Openvpn
apt install openvpn
5. Качаем Bitmask (bundle-версию) отсюда копия на всякий случай и распаковываем его в отдельный каталог в пользовательской директории.
Первый вариант, на сайте https://riseup.net. Переходим по ссылке, придумываем имя пользователя и пароль.
Вариант второй — через Bitmask под катом:
Регистрация успешна, теперь надо получить данные для использования VPN
Bitmask оказался каким-то нестабильным и висючим, периодически при запуске делая бочку:
Отчего он так себя вел, непонятно совершенно. Лечилось либо убийством с помощью pkill и последующим перезапуском, либо запуском через консоль и двойным Ctrl+C (на одиночный он прячется в трей), или удалением каталога программы и каталога .config/leap из домашней директории. Накрайняк была копия HDD виртуалки.
Запускаем bitmask, вводим логин (в виде login@riseup.net) и пароль, логинимся и попадаем в главное окно, или если через bitmask и регистрировались, то сразу попадаем в главное окно, можно даже не пытаться соединиться, сертификаты уже получены.
При первом запуске с ранее зарегистрированным через сайт логином и без заранее добавленного в bitmask провайдера riseup.net может возникнуть следующая картина
Жмем Install Helper Files, после чего несколько раз будет запрошен пароль root, после чего можно нажать кнопку Trun ON
По началу у меня все очень долго соединялось, я так и не дождался. Но на момент написания данного текста все заработало сразу же, я так понял, товарищи из Riseup починили голландский сервер, висевший до этого пару дней.
Нужные сертификаты лежат в домашнем каталоге пользователя:
/home/username/.config/leap/providers/riseup.net/keys/ca/cacert.pem
/home/username/.config/leap/providers/riseup.net/keys/client/openvpn.pem
Bitmask, как выяснилось, фактически навороченная обертка над Openvpn. Соединением VPN управляет именно он. А параметры можно получить независимо от того, удалось ли соединиться с помощью bitmask, или bitmask долго думает над соединением, например, из-за какого-нибудь одного зависшего сервера. Откроем консоль и посмотрим:
ps -Af|grep openvpn
Ага! Вот и все нужные нам параметры, из которых вполне можно сделать конфиг для Openvpn:
nobody 2934 2515 0 05:27 ? 00:00:00 /usr/sbin/openvpn --setenv LEAPOPENVPN 1 --nobind --client --dev tun --tls-client --remote-cert-tls server --management-signal --script-security 1 --user nobody --persist-key --persist-local-ip --persist-remote-ip --group nogroup --verb 1 --remote 5.79.86.180 443 udp --remote 199.58.81.145 443 udp --remote 198.252.153.28 443 udp --tls-cipher DHE-RSA-AES128-SHA --cipher AES-128-CBC --auth SHA1 --keepalive 10 30 --management-client-user kvakushka --management /tmp/leap-tmpzK6zDA/openvpn.socket unix --ca /home/kvakushka/.config/leap/providers/riseup.net/keys/ca/cacert.pem --cert /home/kvakushka/.config/leap/providers/riseup.net/keys/client/openvpn.pem --key /home/kvakushka/.config/leap/providers/riseup.net/keys/client/openvpn.pem
kvakush+ 9906 2676 0 05:56 pts/3 00:00:00 grep openvpn
Ссылка на готовые конфиги копия
Этот VPN использует свой локальный DNS-сервер, дабы данные клиента не уходили к его провайдеру или, например, корпорации добра. IP можно подсмотреть в скрипте bitmask-root в каталоге с bundle bitmask’а в директории apps/helpers
NAMESERVER = "10.42.0.1"
В общем, сохраняем параметры Openvpn в текстовый файл, запоминаем адрес DNS-сервера, копируем на флэшку или закидываем в облако сертификаты, и можно настраивать данный VPN на любом другом компьютере. Но Bitmask или вообще жесткий диск виртуалки, советую куда-нибудь забэкапить. Он может потребоваться в будущем для обновления сертификатов. Как их выковырнуть вручную я, пока что, недопетрил, а Riseup периодически сертификаты обновляет.
Бесплатный, довольно быстрый, но не без геморроя. Иначе не было бы смысла о нем писать.
Сервис надежный в плане безопасности и защиты приваси от всяких нехороших дядек в погонах и пиджаках, ибо основан политическими активистами анархического толка для таких же политических активистов. Причем основан, аж в 1999 году во время протестов против ВТО в Сиэтле и с тех пор работает на благо человечества.
Кроме VPN Riseup также предоставляет защищенную электронную почту и обслуживает новостные рассылки для активистов.
Подробнее можно почитать на официальном сайте https://riseup.net/ru/about-us
Фактически, сервисов даже два. Riseup Red, включающий в себя кроме VPN, электронную почту и XMPP. VPN Red-сервиса настраивается просто и его можно без особых проблем использовать на любом устройстве. Достаточно зарегистрироваться, скачать конфиг и поставить OpenVPN. Но вот с регистрацией проблема, нужен либо инвайт от зарегистрированного пользователя, либо написать администрации, объяснив, зачем тебе их VPN и какой конкретно деятельностью ты занимаешься. Со знакомыми анархами, у которых была регистрация на Riseup, мы давно всякие контакты потеряли. Искать инвайты, или же просить админов, это, во-первых, лишнее общение с живыми людьми, а, во-вторых, х.з., дадут или нет. Нарвешься еще на как[-ого/-ую/-ое]-нибудь SJW, радикальную феминистку, веганского прозелита, или неадекватного антифа, который фашистов видит только что не в своем шкафу, и хрен тебе, а не инвайт. Хотя, среди админов, поговаривают, неадекватных нет, но зачем людей от работы отвлекать.
Есть еще один сервис Riseup Black, предоставляющий пока только VPN, но обещают и электронную почту со сквозным шифрованием в ближайшем будущем. На Riseup Red регистрация без инвайтов и даже без указания электронной почты Безопасность же и политика непередачи данных третьим лицам в виде злобных корпораций и не менее злобной гебни. Зарегистрироваться можно либо на сайте, либо через приложение Bitmask, которое и обеспечивает VPN-соединение, что рекоменовано. Вот в Bitmask и была целая песцовая нора…
Хоть вроде нам обещали доступность, анархичность, всемирное счастье и прочий мир, труд, май и благорастворение воздухов, все оказалось совсем не так радужно.
Юзерам винды не повезло вообще — версии клиента под форточки нет в природе, только обещание, что «скоро будет». Есть версии под Mac и Android, но по их поводу ничего сказать не могу, у нас нет их. Кто отпишется, тому печенька.
Версия под Linux, слава Ктулху, была, и это по началу обнадежило. И даже есть дистрибутивы bundle. Т.е. «портабельные», распаковал на флэшку и забыл о пакетах, зависимостях и установках. Но не тут-то было! В ходе непродолжительного исследования выяснилось, что Bitmask больше напоминает разработанную инопланетянами скороварку, чем программу под линуксы. «Из коробки» и корректно эта фиговина работает только на астероиде с определенной гравитацией, атмосферным давлением, и только в первую субботу после полнолуния, когда Венера в Козероге. Да и то не уверен, потому что когда понял, какой дистрибьютив официально ™ поддерживается, уже сделал так, чтоб поддерживалось везде, кроме винды. Во всяком случае, с VPN оно соединяет.
Очевидные гадости:
— приложение только под 64-разрядные ОС
— только под Убунту и Дебиан
— нифига не под все Убунты и Дебианы
Неочевидные гадости, или о раздолбайстве:
— на сайте bitmask’а нагло врут, что есть x32 версии, ссылки на bundle ведут на страницу 404, пакетов в репозиториях тоже нет, либо есть не все, либо «не подходит к гробу крышка»
— перечислены версии убунт и дебианов, которые поддерживаются. И даже приведены команды для подключения соответствующих репозиториев. Но опять та же история, то пакетов нет, или есть не все, то в команде что-то указано неправильно.
Когда, путем научного тыка, вдумчивого чтения существующих путей к репозиториям, лазания по аж двум официальным сайтам (bitmask.net и leap.se), на которых написаны совершенно разные вещи, было выяснено, что из коробки поддерживается только Debian Stretch x64 и Ubuntu 17.04, то проверять это «за ради проверки» расхотелось. Хотите — проверяйте сами.
В общем такая вот дискриминация, ложь, пиздежь и провокация, со стороны разработчиков Bitmask по отношению к пользователям других дистрибьютивов линукса, и даже к дебианщикам/убунтоводам, уж не говоря про обладателей устройств с процессорами x32.
Конечно, сейчас набегут всякие погромисты и прочие неравнодушные с криками «ну кот жи аткрыд, перепейшы1111», но дело ведь в том, что можно хотя бы везде на своих сайтах написать — «наша софтина работает только там-то, там-то и там-то, а остального мы не гарантируем» и все. А то в результате получается ситуация, когда пользователь читает, что на сайте написано, пробует у себя, оно не работает (хотя знают, что не работает, только разработчики), и так и сяк не работает, и пользователь приходит к выводу, что опенсурс (линукс, дебиан, убунта, нужное подчеркнуть) говно. И никакого равенства, братства и благорастворения воздухов.
Впрочем, сие ворчание распространяется только на горе-разработчиков Bitmask и к команде Riseup никак не относится. Хочешь VPN без геморроя, проси инвайт, или у админов, секурного VPN на всех не напасешься, тем более не напасешься на потенциальных политических противников.
Ладно, поговорили и хватит, пора расколдовать принцессу.
Для того, чтобы решить задачу, мне все таки пришлось на время одолжить более мощный ПК, правда с 32-разрядной виндой и запретом ее сносить. Оказалось, что VMWare Workstation даже на хосте с 32-разрядной XP вполне смогла запустить в качестве гостевой ОС 64-разрядный Debian 8.10
Год назад, может раньше, по совету товарищей, я переполз с PPTP VPN на Openvpn. За это время узнал несколько хинтов, которые, периодически нужны либо по работе, либо кому-нибудь.
Эталонный конфиг, который буду модифицировать, лежит здесь
Windows: не актуально
Linux: да
Решение:
Собрать из исходников, предварительно переконфигурировав командой
./configure --disable-plugin-auth-pam
Windows: да
Linux: да, за исключением старых версий, которые приходилось пересобирать со специальным ключом. Если вдруг такое попалось, то обновить.
Решение:
В конфиг соединения надо добавить строку auth-user-pass /path/to/auth/file
где
/path/to/auth/ — путь к файлу авторизации
file — имя файла
Для Windows будет что-то типа C:\path\to\file.txt
Файл авторизации — простой текстовый файл в котором содержатся две строки: первая — логин, вторая — пароль:
содержимое файла file:
username
pa$$w05D
Windows: не актуально
Linux: да
Решение:
В конфиг соединения надо добавить строку daemon
Windows: не актуально, во всяком случае, мне не встречалось
Linux: да
Для чего надо: например, для того, чтобы при установке/разрыве соединения, настроить маршрутизацию или iptables (фаерволл)
Решение:
1. Надо разрешить Openvpn выполнять пользовательские скрипты, добавив в конфиг следующую строку:
script-security 2
2. Прописать путь к скрипту в одном или нескольких нужных параметров конфига, например:
up '/home/kvakushka/scripts/ovpn-routes up'
down '/home/kvakushka/scripts/ovpn-routes down'
Надо уточнить, что скриптам up и down Openvpn передает параметры командной строки, несущие информацию о соединении:
[1..N]: Параметры, указанные пользователем в конфигурационном файле, т.е. в вышеприведенном примере, скрипту ovpn-routes при вызове после того, как поднимется тоннель, будет передано первым параметром «up«, а при разрыве соединения — «down«.
Очень полезный горшочек, позволяющий в одном скрипте обрабатывать несколько событий.
[2]: Имя сетевого устройства (тоннеля). Например, tun0
[3]: MTU сетевого интерфейса
[4]: MTU соединения
Можно использовать для сложной маршрутизации между несколькими каналами и поиска более выгодного маршрута.
[5]: IP-адрес клиента
[6]: IP-адрес клиента на стороне сервера
[7]: init, если скрипт был вызван во время запуска/останова Openvpn или restart, если скрипт был вызван при перезапуске (обрыве соединения, например).
#!/bin/bash
#заводим переменные с понятными именами
MAIN_STAT=$1 #up/down
DEV_NAME=$2
TUN_MTU=$3
LINK_MTU=$4
LOCAL_IP=$5
REMOTE_IP=$6
ADD_STAT=$7 #init/restart
#директория с iptables и ip
ACPATH="/usr/sbin/"
# [...]
#скрипт вызван при поднятии тоннеля
if [ "$MAIN_STAT" = "up" ]; then
#установка маршрута по умолчанию для VPN
"$ACPATH"ip route del default
"$ACPATH"ip route add default via $REMOTE_IP dev $DEV_NAME src $LOCAL_IP
#настройка IPTABLES
#разрешение транзитного трафика
"$ACPATH"iptables -P FORWARD ACCEPT
exit
fi
#скрипт вызван при отключении тоннеля
if [ "$MAIN_STAT" = "down" ]; then
#запрет транзитного трафика
"$ACPATH"iptables -P FORWARD DROP
#установка маршрута по умолчанию без VPN
"$ACPATH"ip route del default
"$ACPATH"ip route add default via 10.10.1.1 dev eth1 src 10.10.20.55
fi
В примере настраивается маршрут по умолчанию, для случая соединения через VPN и напрямую, а также отключается транзитный трафик, если соединение идет не через VPN.
Пример модифицированного конфига соединения Openvpn
Скрипт ovpn-routes
1. Основные команды и параметры OpenVPN Копия
2. Установка и настройка клиента OpenVPN в Ubuntu Копия
Или сраный интеловский чипсет. В общем, вызвали меня на заказ, поставили задачу — десятку убить, семерку вкрутить. Беру верную флешку с YUMI, на которой есть образ Acronis Disk Durector, всякого рода винды и линуксы, нужные для эникейной работы, и начинаю.
Снес я Windows 10, убил б-гмерзкое GPT, переделил диск, вставляю флешку с установщиком Win 7, но не выходит каменный цветок, посылает меня установщик Windows 7 за Cdrom drivers, иначе говоря, Windows 7 просит драйверы CD-ROM.
Непорядок, подумал я, ибо CD-ROM даже в проекте не было. Легкое гугление дало ответ, Windows 7 не поддерживает USB 3.0 искаробки. Гейц с ним, включаю в BIOS режим совместимости USB. Линуксы и флешку и hdd видят, акронис тоже, а вот инсталлятор Windows 7 — хрен.
В общем думал я, думал, и таки нашел способ поставить Win7 с жесткого диска, хотя кучу времени зря потратил на добавление драйверов USB, различную греблю с перетыканием флешек и прочей фигней, есть же способ гораздо проще…
1. Две флешки. На одну кладем любимую «форматилку», он же менеджер дисков и Hiren’s Boot CD. Вообще весь HBCD нам тут нахрен не нужен, можно обойтись вырезкой из сабжа.
2. Чуть не забыл, нужен еще какой-нибудь легковесный Linux. Я в конкретном случае использовал Puppy Linux.
3. Флешка 2, на которой или образ установочного диска Win7, или уже подготовленный для загрузки с флешки установщик. В моем случае, был вариант 2, заранее подготовленный с помощью rufus
4. Достаточное дисковое пространство. В моем распоряжении был аж терабайтный винт, хотя описываемый ход котом можно повторить даже на 50-гигабайтном IDE-HDD, буде он в такой конфигурации железа окажется.
1. Делаем разделы диска, как нам угодно. Например, я сделал логический диск D: для файлов пользователя, на 700 Гб, в конце диска, и оставил область в 300 Гб в начале неразмеченной. Установщик Win 7 сам ее потом разметит, положит файлы ОС на будущий диск C: и создаст свой загрузчик на отдельном разделе 'Зарезервировано системой', размером 100 Мб
2. Делаем с помощью любимого менеджера дисков, логический раздел для установщика Windows 7, размер варьируется, от 5 до 8 Гб, но лучше сделать 8. Формат (файловая система) раздела NTFS или FAT32, последнее предпочтительнее.
3. Загружаемся в Linux, и если вы последовали совету использовать Puppy, то все будет «какввенде» — рабочий стол, ряд дисков ниже, флешка с виндой с иконкой флешки. Жаль, не могу заснять видео, машину уже унесли
4. Копируем файлы с флешки с установщиком Windows на созданный раздел. Файлы скопировать просто: открываем флешку, кликая по ней 1 раз, открываем нужный диск (аналогично), переключаемся в окно с открытой флешкой, нажимаем CTRL+A, выделяя все в окне, и мышкой перетаскиваем в соседнее окно, где открт нужный раздел
5. Осталось перезагрузиться с загрузочной флешки, и выбрать пункт меню Boot From Hard Drive (Windows Vista/7/2008 or Xp), если вы грузитесь через PXE или с установленного на YUMI HBCD, или последовательно выбрать Boot Windows (XP/2003/2008/Vista/7) From Local HDD а только потом Boot From Hard Drive (Windows Vista/7/2008 or Xp)
Если все сделано верно, то Grub4DOS найдет bootmgr, а тот запустит установщик Windows 7.
Останется установщику указать неразмеченную область диска для установки.
Потом раздел с установщиком можно снести и объединить его с диском C: или D:.
Как-то так, прошу прощения, что без скриншотов и видео, пациента уже выписали.
Спросит вдумчивый читатель. И будет прав.
Отвечу на это:
1. Да чтобы запустить локальную Windows, если, например, слетел к чертям собачьим MBR, оригинального диска с виндой под руками нет, а зайти смерть, как надо, и именно в локальную винду.
2. Чтобы запустить установку Windows 7 (а может быть и 8, а может быть и 10, а может быть ворона, я не проверял) с локального жесткого диска. А вот зачем это — расскажу позднее.
1. Использован образ DOS, взятый отсюда
2. Подправлен AUTOEXEC.BAT
3. Добавлен Grub4DOS, причем особо не заморачиваясь, утащен с мультизагрузочной флешки, созданной YUMI
4. Подправлен menu.lst также нагло спертый из Hiren’s boot CD
5. Создана ISO-версия этого безобразия, по вот этому рецепту
Готовый образ
Готовый образ, сжатый gzip
ISO-образ
Вообще я использовал для работы оригинальный HBCD, а эта штуковина, хоть и сделана «по мотивам», но в реальных условиях не тестировалась. Только на тестовой виртуальной машине, так что юзайте на свой страх, риск и хвост, и оставляйте комментарии, ежели любо, или же не любо и в чем конкретно
Простенькие, на живую нитку, исключительно для автоматизации рутинных операций.
#!/bin/bash
RDMP="/mnt/ramzes"
LDRKRNLPATH="./ldrkrnl/"
LDRKRNLNAME="ldrkrnl.img"
echo "Making dirs"
mkdir $RDPATH
mkdir $RDMP
mkdir $LDRKRNLPATH
echo "Extracting RAMDISK..."
dd bs=1 if=$IMGPATH of=$RDPATH$RDGZNAME skip=464896
echo "Extracting loader and kernel"
dd bs=1 if=$IMGPATH of=$LDRKRNLPATH$LDRKRNLNAME count=464896
echo "Unpacking RAMDISK..."
cd $RDPATH
gzip -d $RDGZNAME
cd ..
echo "Mount RAMDISK"
mount -o loop $RDPATH$RDNAME $RDMP
#!/bin/bash
RDMP="/mnt/ramzes"
echo "Remove AVP"
cd $RDMP
cd root/.AVP
rm *
cd ..
rmdir .AVP
rm $RDMP"/usr/bin/AVPLinux"
cd $RDMP
cd opt
cd AVP
rm *
cd ..
rmdir AVP
cd $RDMP
#!/bin/bash
IMGPATH="./mbootdisk.img"
RDPATH="./ramdisk/"
LDRKRNL="./ldrkrnl/ldrkrnl.img"
RDNAME="ramdisk"
RDMP="/mnt/ramzes"
echo "Umount RAMDISK"
umount $RDMP
echo "Packing RAMDISK"
cd $RDPATH
gzip -9 $RDNAME
cd ..
echo "Make bootdisk"
cat $LDRKRNL $RDPATH$RDNAME".gz" >$IMGPATH
echo "Complete!"
Разборка оригинального диска на PasteBin
Удаление AVP из образа на PasteBin
Сборка модифицированного образа на PasteBin
Архив со скриптами
Часть I
Часть II
Все статьи (PDF, ZIP)
Я, почему-то, не принял во внимание ясные надписи серым по черному, и попытался распаковать полученный ramdisk, думая, будто бы это стандартный initrd. А почему? Да потому что внимательнее мануалы читать надо, и гуглить лучше, если сам чего-то не знаешь.
Оказывается, при создании дискеты была применена более старая технология создания диска в оперативной памяти
Полученный на прошлом этапе ramdisk.gz оказался действительно виртуальным диском в оперативной памяти, сжатым gzip’ом
Правда, при распаковке в Линуксе, gzip выдал предупреждение:
Пытаемся распаковать ранее вырезанный ramdisk.gz:
gzip -d ramdisk.gz
gzip: ramdisk.gz: decompression OK, trailing garbage ignored
Так, какой-то «мусор» после конца архива был игнорирован при распаковке. Как позже выяснится, фактически он ни на что не влияет, и на предупреждение gzip’а можно забить.
В конце образа дописано некоторое количество байт F6 (Ў) и нечто похожее на контрольную сумму и цифровую подпись.
Хотя, для чистоты эксперимента, ничто не мешает получить «чистый» архив, размером 876114 байт:
dd bs=1 count=876114 if=ramdisk.gz of=ramdiskcln.gz
И «мусорный» хвост (остаток размером 133614 байт).
dd bs=1 skip=876114 if=ramdisk.gz of=endimg
Пробую распаковать ramdiskcln.gz — никаких предупреждений, распаковка успешна:
Доступ к ramdisk’у и его модификация
Сначала создается точка монтирования:
mkdir /mnt/ramzes
Теперь монтирование распакованного образа:
mount -o loop ramdiskcln /mnt/ramzes
Все успешно примонтировалось, видно структуру каталогов оригинального ramdisk’а AVP Z.E.S Linux. Места, правда, маловато. Всего 3 с хвостиком Мб, а осталось свободными вообще 806 К. Но все равно, кое-что можно сделать, например, для первого раза:
— выкинуть сам AVP (директория AVP в opt, скрипт avp.run из sbin, ссылку usr/bin/AVPLinux и директорию .AVP из root)
— подправить скрипт etc/rc.d/rc.sysinit, чтоб выкинуть команды вызова AVP
1. Отмонтируем ramdisk:
umount /mnt/ramzes
2. Запакуем образ ramdisk’а:
gzip -9 ramdiskcln
3. Соберем образ диска обратно. От предыдущих экспериментов должен остаться файл ldrkrnl.img, содержащий начальный загрузчик и ядро Z.E.S. Его нужно скопировать в директорию с измененным и запакованным ramdisk’ом, и просто слить в новый образ с помощью cat:
ldrkrnl.img ramdiskcln.gz >mbootdisk.img
И все-таки попытку модификации исходного образа удалось завершить, хотя бы для демонстрации того, что «а так можно было?»
Например, в образ добавлен минималистичный текстовый редактор qed, написанный на Free Pascal:
Или даже мощный консольный редактор, переделанный из примера, поставляющегося с Free Pascal:
—Размер ramdisk’а сильно ограничен, поэтому некоторый софт, даже статически скомпилированный, туда не влез. Либо нарушалась идея «чтоб влезло на одну дискету».
-Постоянные проблемы с shared-библиотеками даже у того, что влезло. Так понимаю, что какие-то библиотеки устарели настолько, что новое не запускается, а старое, если заменить библиотеки — не работает. Или я что-то неправильно делал.
Поигрались и хватит, все равно для практического применения этот дистрибьютив не совсем подходит. Но есть и плюсы — классно поковырялся, в процессе узнал новое, в общем, удовольствие получено. Осталось даже несколько идей на будущее, например, очень понравился Free Pascal и некоторые возможности Linux, реализуемые им без геморроя, которым страдает программер на C/C++.
Начало
Использование ramdisk в Linux (ramdisk, ramfs, tmpfs)
или препарирование рамдисков
How to Create/Modify an RAM disk Image (на английском), PDF, скачать
Оригинальный образ bootdisk.img
Чисто от нефиг делать…
В состав древних версий Касперского антивируса входила утилита, для создания спасательной дискеты, включающая образ диска bootdisk.img и собственно утилиту, копировавшую этот образ на дискету №1, а на все остальные 2-3 штуки — антивирусные базы.
Дискеты с базами были самые обычные, они нас не интересуют, а вот на первой дискете был малюсенький Linux со встроенным антивирем. Linux автоматически монтировал локальные диски, причем поддерживал FAT, FAT32, NTFS, HPFS, EXT2, т.е. все самые популярные на 1999-2001 г. файловые системы.
После загрузки Касперского надо было вставить дискеты с базами, дождаться загрузки баз и далее шла проверка. Если же дискеты с базами не вставить, то выбрасывало в линуксовую консоль, в последней версии без всяких вопросов, а в более ранней надо было ввести имя пользователя root и аналогичный пароль. Далее, зная команды, можно было бродить по дискам, читать файлы с помощью cat, копировать их, и т.д.
Касперский линукс был неприхотлив, для работы ему хватало то ли 4, то ли 8 Мб оперативки, и нам с товарищем удавалось запустить его даже на 486 машине, а вот на 386 не получилось, памяти не хватило.
Сама же дискета не открывалась ни в 98 винде, ни в NT и 2000, ни в Линуксе. Линукс мы знали совсем мало-мало, винды ругались на то, что диск не форматирован, мануалов особо не было, интернета и подавно. В общем решили мы, что хитрый Касперский дискету зашифровал, чтоб чуть что ее вирусы не заразили ненароком, и решили, что тягаться с самим Валентинычем нам не под силу, да и забили на это дело.
Недавно товарищ вновь объявился на горизонте и принес тот самый bootdisk.img из дистрибутива AVP 5, правда, огорчил, что доступные ему виртуалки образом подавились. Microsoft Virtual PC свалилась вместе с виндовозом в синий экран, а Virtualbox и вовсе отказался принимать это за образ дискеты.
Я высказал предположение, что дискета в формате RAW и на ней просто последовательно без всякой файловой системы записаны загрузчик, ядро Линукса и что-нибудь типа initrd, откуда и запускается все остальное, скинул образ на флэшку, и опять забыл.
Точнее мне не хотелось слушать разговоры слесарей о машинах и футболе, мне они так же непонятны, как слесарям разговоры о Линуксе, и мне же о бабах, потому что про глючные девайсы я и в интернете могу почитать. Бухать тоже не перло, но на автобазе было тепло, а снаружи дул холодный ветер и сыпал мерзкий снег. К тому же обнаружился ЁЁЁ-писюк с модемом, а в кармане валялась та самая флешка с образом и Хрювером, он же HIEW. А пуркуа бы не па…
Скачиваю QEMU, ставлю и скармливаю ей образ дискетки:
qemu-system-i386.exe -fda bootdisk.img -boot a
Надо же, загрузились, какие мы молодцы!
Тааак… Если загрузились, должен быть и загрузчик. Вот, кстати он работает:
Вспоминаем устройство загрузочных дисков. Сначала BIOS загружает первые 512 байт, которым передает управление. Можно попробовать эти 512 байт отрезать и посмотреть, что получится.
Устанавливаю dd
И делаю вот так:
dd bs=1 count=512 if=bootdisk.img of=512.img — размер блока 1 байт
bs=1
count=512 — количество блоков
if=bootdisk.img — откуда читать
of=512.img — куда писать
Пробую скормить выходной файл QEMU:
И все, на этом висим. На самом деле, висим вполне закономерно — в первых 512 байтах только главная загрузочная запись и основной загрузчик, который хоть черта лысого может подгрузить по своему усмотрению.
Ладно, с налета, с шашкой наголо закономерно ничего не вышло, будем наблюдать дальше. Загрузимся опять с оригинального образа.
Момент раз:
Момент два, чуть погодя:
Ага! Uncompressing Linux! Compressed image found at block 454!
Похоже, моя гипотеза подтверждается: загрузчик, за ним сжатое ядро, в которое встроены необходимые модули, а за ним сжатый образ со всем остальным.
За следующую гипотезу приму то, что Касперский не изобретал крутых велосипедов, а ограничился стандартным gzip-сжатием.
Недолгое гугление дало, что gzip-архив начинается с сигнатуры 1F 8B 08 00, хорошо, что на флешке завалялся HIEW.
Загружаем в него оригинальный образ, переключаемся в HEX-режим (F4) и пробуем поискать сигнатуру архива.
Вот первое совпадение по смещению 4344h т.е. на 17221 байте от начала файла (HIEW ведет счет с 0).
А вот и второе по смещению 71800h, т.е. на 464897 байте от начала файла.
Больше сигнатур обнаружено не было. Пока с моими гипотезами все в порядке.
Чтобы окончательно убедиться в своей правоте, я решил разделить файл на несколько частей и посмотреть на их поведение при запуске, все равно слесарей по домам еще не развозили, а на улице погода и не думала улучшаться.
Сначала оставлю один загрузчик, чтобы посмотреть, как он поведет себя без всего остального.
Копирую bootdisk.img под именем loader.img, открываю loader.img в HIEW. Далее надо переключиться в HEX-режим и провести поиск первого вхождения сигнатуры 1F 8B 08 00.
Теперь переключаемся в режим редактирования (F3) и обрезаем файл с этой позиции включительно (Trunc, F10)
Выходим из HIEW, получился файл размером ровно 17220 байт. Скармливаю его QEMU.
Точно загрузчик. Не обнаружил сигнатуры запакованного gzip’ом ядра, отругался и оставил нас.
Попробую теперь повторить операцию, оставив в файле загрузчик и предполагаемое ядро. Копирую оригинальный файл под именем ldrkrnl.img и делаю все то же самое, что и в первом случае, только ищу второе вхождение. В итоге получился файл размером 464896 байт. Пробую запустить.
Ага! Ядро! Вроде бы загрузка поначалу шла нормально, но потом RAMDISK не нашел образа диска на своем месте и драйвер VFS потребовал с нас дискету с корневой файловой системой. Естественно, т.к. у дискеты нестандартный формат, то смонтировать ее не удалось и получилась kernel panic. Хотя, забегая вперед, это дает возможность отвязаться от ограничений RAMDISK и модифицировать систему как угодно. Фактически это, конечно, не нужно, проще уж что-то свое собрать, чем идти таким странным способом.
Но ради развлечения я все-таки систему модифицирую, не зря же ковырялся.
Раз уж речь зашла о модификации, то нАчать надо с того, чтобы извлечь образ ramdisk’а.
Это последнее, что я сделал в теплом гараже и на винде. Для остального уже Линукс надобен.
Итак, имеем ldrkrnl.img размером 464 896 байт, и оригинальный bootdisk.img. Чтобы вырезать рамдиск, можно воспользоваться dd:
dd bs=1 if=bootdisk.img of=ramdisk.gz skip=464896 — количество блоков размером в 1 байт (
skip=464896bs=1), которые нужно пропустить с начала файла bootdisk.img
На выходе получился файл ramdisk.gz размером мегабайт с хвостиком, имеющий в начале вышеупомянутую сигнатуру gzip-архива. Файл успешно открылся в WinRar, и тест показал, что ошибок не обнаружено.
На базу подтягивалась новая смена, слесарей повезли по домам, а я поехал к старому другу, чтобы отоспаться, пока он ставит Линукс, и продолжить эксперимент на относительно свежую голову.
Продолжение следует…
О gzip-архиве и сигнатуре ея
QEMU для Windows XP
dd для Windows
Не буду описывать для чего она нужна %) Заметка от дырявой памяти на всякий случай.
Скачать с официального сайта
Прямая ссылка на последнюю стабильную не бета-версию 0.5
Копия на всякий противопожарный
К сожалению, автор QEMU перестал поддерживать XP, а старые версии, на мой взгляд, несколько глючноватые, но для каких-то небольших задач вполне подходят.
1. Качаем последнюю версию, поддерживающую XP 2016-09-03 (2.7.0) или отсюда
2. Ставим стандартным для Windows образом
3. Поскольку QEMU, как и в линуксе, управляется с командной строки, а расположена установленная программа в Program Files, да и имена у виртуалок длинные и неудобные, типа qemu-system-i386.exe, то пишем батник, передающий программе параметры, примерно такой, как здесь
содержимое qemu386.bat:
@Echo Off
Setlocal EnableDelayedExpansion
Set P="C:\Program Files\qemu\qemu-system-i386.exe"
For %%A In (%*) Do SET P=!P! %%~A
start "QEMU"/B %P%
Команда start — чтоб после запуска из консоли, например из-под FAR’а, консоль не висела, ожидая завершения работы QEMU
Параметр "QEMU" — заголовок окна, создаваемого командой start. Без него start подумает, что заголовок окна это путь к исполняемому файлу и попытается безуспешно выполнить первый передаваемый QEMU параметр.
/B — указывает команде start не создавать это самое новое окно, если его не указать, то за окном QEMU будет висеть черное пустое окно новой консоли.
В переменной %P% будет путь к QEMU и передаваемые параметры, например:
qemu-system-i386.exe -fda bootdisk.img -boot a загрузка с образа дискеты bootdisk.img
4. Кладем батник в какой-нибудь каталог, имеющийся в PATH, например, в C:\Windows
Пример как раз таки загрузки с такого образа
Про эту дискету расскажу как-нибудь позже, она с хитринкой, а мне было нечем заняться в компании дальнобоев, автослесарей и ноута с XP и мамедным интернетом, кроме как ее (недо)-реверсингом %).
Продолжаю тему, начатую в предыдущей заметке [КОПИЯ]. В ней описывал получение данных от определенных скриптов и процессов запущенных на сервере под управлением Linux с помощью SSH, псевдотерминала и отдельного пользователя, создаваемого специально для целей мониторинга.
Будем посмотреть другой способ, с одной стороны, более сложный и требующий владения каким-нибудь языком программирования, кроме Bash-скриптов. Хотя, можно обойтись и исключительно одним Bash’ем, если клиент и сервер под Linux, или Bash прикрутили к Windows (cygwin(?), не пробовал, не знаю). А с другой стороны, наоборот, способ простой безопасный, требующий минимум вмешательства в настройки сервера.
На полноценный мануал не рассчитывайте, так, заметки на полях рабочего блокнота, чтоб не забыть и потом допилить под свои личные нужды.
Примечание: Термины «клиент» и «сервер» могут по ходу статьи быть неоднозначно истолкованными.
Серверное приложение будет наоборот, работать на «клиентском», «операторском» рабочем месте, а «сервер», в смысле компьютер с Linux, на котором я запускаю свои скрипты, и который управляет нужной мне железякой, станет вполне себе клиентом.
В общем, чтобы не вносить путаницы я условлюсь называть рабочее место оператора «локальным компьютером», а тот, который «сервер в привычном понимании» — «удаленным».
Такая же, как и в предыдущей заметке. Имеется удаленный компьютер под управлением Linux, рулящий системой контроля температуры и давления.
На самом деле, рулить он может чем угодно: от домашнего FTP с котиками или соединения с Интернетом, до управления СКД, открытием ворот, дверей, врат в Ад, личным концлагерем и т.д.
Суть в том, что нужно, чтобы удаленная система сигнализировала оператору об изменении своего состояния (изменении температуры, разрыва соединения с Интернетом, пришествии Сатаны). Оператор, как обычно, сидит под Windows (как в большинстве организаций в СНГ).
Для простоты условимся, что локальный и удаленный компьютер находятся в одной локальной сети (и одной подсети) 10.10.0.0/24, IP-адрес локального компьютера 10.10.0.30, прием данных производится через сетевой порт 11000 локального компьютера. Локальный и удаленный компьютеры обмениваются данными по протоколу TCP, данные представляют собой Unicode-строки.
Как это организовано на локальном и удаленном компьютере
Сервера приема сообщений:
— Смотреть на PasteBin
— Скачать с Mega.nz
Скрипта отправки сообщений:
— Смотреть на PasteBin
— Скачать с Mega.nz
1. Клиент-серверное приложение на потоковом сокете TCP [Копия]
2. Как открыть TCP-/UDP-сокет средствами командной оболочки bash [Копия]
Понадобилось мониторить состояние сервера, точнее не всего сервера, а определенного демона, на сервере запускаемого. Понятно, что самым простым способом мониторинга чего-то работающего в фоне, является просмотр соответствующих логов. Но такой способ на самом деле дает весьма мало интерактивности, надо постоянно заходить по SSH, ковыряться в этих самых логах. Хочется, чтоб при изменении состояния, или же по определенной команде от определенного пользователя, сервер нам все рассказывал сам.
Хорошо, если демон умеет при изменении состояния запускать некие пользовательские скрипты. Так умеет, например, демон OpenVPN или, например, демон небольшой промышленной системы метеоконтроля, который я использовал в данном примере.
Вкратце, имеется плата на Arduino, обрабатывающая показания с нескольких датчиков и передающая их в удобоваримом формате через COM-порт демону, запущенному на сервере. Демон умеет исполнять пользовательские скрипты, но вот беда (та же беда и с OpenVPN), если в скрипте написать что-то типа echo "У нас изменились параметры, шеф, все пропало" это сообщение в лучшем случае уйдет неведомо куда. В худшем — вылезет пользователю, из под которого стартует демон, посреди рабочего сеанса в консоль.
Самый простой способ всего этого избежать, при этом получив нужную интерактивность — отправлять сообщения определенному пользователю, созданному специально для данной цели.
Не так давно я делал похожего пользователя для отключения/перезагрузки сервера [КОПИЯ] . Фактически, пользователю была установлена псевдооболочка (на самом деле просто скрипт), выполняющий единственную команду перезагрузки/отключения системы. И идея создания псевдооболочек меня зацепила. Таким образом можно дать пользователю выполнять только ограниченный набор команд, да еще и обрабатывать параметры в скрипте по-своему, так что никакой злоумышленник, даже получив доступ по ssh ничего сделать не сможет, т.к. команды псевдооболочки ему неизвестны.
Почему бы не использовать такой способ и для целей мониторинга?
Первым делом создаем отдельную группу:
groupadd monusers
где monusers — любое название группы на ваш вкус, ранее в системе не существующее
Создаем пользователя:
useradd -g monusers -d /home/meteomon -s /home/meteomon/monitor.sh meteomon
где:
-g monusers группа пользователя (ранее созданная monusers)
-d /home/meteomon домашний каталог пользователя
-s /home/meteomon/monitor.sh — псевдооболочка для пользователя, скрипт, обрабатывающий команды.
meteomon — имя пользователя
Задаем пользователю пароль (иначе не сможем залогиниться по ssh):
passwd meteomon
Создаем домашний каталог:
mkdir /home/meteomon
Меняем владельца каталога на пользователя meteomon:
chown meteomon:monusers /home/meteomon
Меняем права доступа на каталог:
chmod 500 /home/meteomon
Создаем в домашнем каталоге скрипт monitor.sh о содержимом скрипта ниже.
Меняем владельца и права доступа для скрипта monitor.sh
chown meteomon:monusers /home/meteomon/monitor.sh
chmod 500 /home/meteomon/monitor.sh
Поскольку пользователь предполагается исключительно для мониторинга, разрешим ему всего одну команду — выход из системы. Соответственно, скрипт будет такой:
#!/bin/bash
echo "Hi, monitor operator"
echo "To exit enter byebye"
while [ "$KEYINPUT" != "byebye" ]; do
read KEYINPUT
done
Все просто — ввод с клавиатуры попадает в переменную KEYINPUT и пока она не равна byebye скрипт выполняется. Как только пользователь введет byebye, так прервется цикл, скрипт завершит работу, и пользователь автоматически выйдет из системы.
Для отправки сообщений пользователю используем связку команд echo и write
Можно создать отдельный скрипт со следующим содержимым:
#!/bin/bash
USERNAME="meteomon"
echo -e $1|write $USERNAME 2>/dev/null
положить его в каталог с доступными пользователям скриптами (например в /usr/sbin) и установить права доступа, например в 755, чтобы пользователь для мониторинга мог получать сообщения от всех пользователей системы.
Примечание: параметр -e команды echo позволяет использовать специальные символы, такие, как перенос строки \n, а конструкция 2>/dev/null отправляет в нуль-устройство сообщение об ошибке, которое может возникнуть, если пользователь meteomon не вошел в систему.
Осталось прописать соответствующую команду в пользовательском скрипте, вызываемом демоном, или исполняемом по cron’у:
...
DATA=`meteosrv checksystem`
/usr/sbin/techo $DATA
...
Внимание! Читайте документацию по демону, можно случайно нарваться на подводный камень, например, OpenVPN в некоторых случаях болезненно относится к ошибкам, случающимся в пользовательских скриптах.
Для Windows понадобится утилита plink, обычно она идет вместе с ssh-клиентом PuTTY. В каталоге с ней создаем bat-файл следующего содержания.
testmon.bat:
plink -ssh -P 22 -l meteomon -pw meteomonpass 192.168.0.40
где вместо meteomon надо подставить имя пользователя для мониторинга, вместо meteomonpass — заданный пароль, а вместо 192.168.0.40 настоящий адрес удаленного компьютера.
Источники
Спрашивают, как у нас сделан украинский флаг при входе на сервер. Да проще пареной репы, товарищи!
1. В любимом графическом редакторе готовим картинку. Должна быть PNG, разрешением 210×210 px и глубиной цвета 32 бита.
2. Идем в файл /usr/share/gdm/defaults.conf и ищем там параметр Logo= (секция [greeter]) и меняем путь на путь к своему файлу или заменяем сам файл.
Можно настроить приветствие:
Параметры
DefaultWelcome=false
DefaultRemoteWelcome=false
устанавливаем в false (иначе, ЕМНИС, будет использовано имя компьютера) и меняем параметры (вместо нашего названия подставьте свое):
Welcome=Welcome to UAITC
RemoteWelcome=Welcome to UAITC
Флаг (по клику можно скачать с mega.nz):
Шпаргалка на стену студенту.
Скачать архив с копиями источников, файлами большого разрешения и svg.
По материалам:
1. http://downloads.naulinux.ru/pub/NauLinux/school_server/Docs/Docs/Nau/nau-server-sbs-ru/s1-navigating-ownership.html
2. http://www.k-max.name/linux/prava-dostupa-v-linux-eshhe-odna-malenkaya-shpargalka/
Не так давно я затрагивал вопрос настройки X11 Forwarding [Копия], что позволяет через ssh запускать отдельные графические приложения на удаленной Linux-машине (сервере). Теперь буду настраивать удаленный доступ к рабочему столу через XDMCP.
XDMCP внешне похож на RDP в Windows, т.е. при подключении пользователю будет предложено ввести логин и пароль в окне входа в систему и на экране отобразится удаленный рабочий стол. Фактически, на удаленной машине в памяти висит Display Manager (GDM, XDM и т.д.) и слушает 177 порт UDP, если от X-сервера с другой машины поступает запрос, Display Manager начинает с ним общаться, принимать оттуда изображение, а туда передавать координаты мыши и нажатия с клавиатуры, рисует окошко входа в систему. Если пользователь предоставил корректные данные для входа в систему, то он сможет работать с удаленным рабочим столом.
Внимание! Не все Display Manager’ы поддерживают работу по протоколу XDMCP. Точно поддерживают XDM, GDM, KDM и LightDM [3], так что проверьте в первую очередь, какой у вас Display Manager, и может ли он работать по XDMCP. Например, на одной из машин, к которой требовался доступ по XDMCP пришлось вместо LXDM ставить GDM.
Внимание! Протокол XDMCP довольно слабо защищен, так что его не рекомендуется использовать через Интернет без дополнительного шифрования. У нас, например, сделан доступ через VPN.
Первым делом необходимо открыть на файерволе нужные порты. Обязательно для входящих соединений открывается порт UDP 177. Если соединение планируется из Windows, то необходимо также открыть порты TCP 6000-6005 в обоих направлениях (входящие и исходящие соединения). Для соединения из Gnome вроде как надо открыть также в обоих направлениях порты TCP 16001 и 35091 [2]. На практике я проверял только подключение из Windows.
Команды для настройки файервола:
# XDMCP
echo "Open 177 port UDP (XDMCP) for Avallon AG clients..."
iptables -A INPUT -s x.x.x.x/yy -p udp --dport 177 -j ACCEPT
iptables -A OUTPUT -s x.x.x.x/yy -p udp --sport 177 -j ACCEPT
echo "Open 6000:6005 ports (Windows XDMCP) in both directions for AAG clients..."
iptables -A INPUT -s x.x.x.x/yy -p tcp -m multiport --dports 6000:6005 -j ACCEPT
iptables -A OUTPUT -s x.x.x.x/yy -p tcp -m multiport --sports 6000:6005 -j ACCEPT
iptables -A INPUT -s x.x.x.x/yy -p tcp -m multiport --sports 6000:6005 -j ACCEPT
iptables -A OUTPUT -s x.x.x.x/yy -p tcp -m multiport --dports 6000:6005 -j ACCEPT
Вместо x.x.x.x/yy надо подставить адрес компьютера с которого будем связываться с компьютером под Linux, или маску подсети.
У меня был GDM, поэтому приведу его как основной, остальные дам для справки.
Необходимо найти файл custom.conf, в источниках написано, что лежать он должен по адресу /etc/gdm/custom.conf, но на самом деле это зависит от дистрибьютива. В моем случае файл находился здесь: /etc/X11/gdm/custom.conf
В файле, который выглядит, как обычный INI-файл необходимо найти секцию [xdmcp] и вписать туда следующие параметры:
Enable=true
Port=177
Как видите, можно задать альтернативный порт для XDMCP.
Настройка других DM:
Под катом
Внимание! Стоит заметить, что в некоторых случаях конфигурационные файлы могут располагаться в других местах. Если их нет по указанным путям, можно воспользоваться поиском файлов в том же mc
Понадобится уже упомянутый в заметке про X11-Forwarding Xming.
Запускаем XLaunch и устанавливаем конфигурацию.
В первом окне выбираем один из режимов «одного окна», например One window, иначе не даст создать XDMCP сессию, и указываем номер дисплея 0 (обычно 0, если вы специально ничего не переопределяли на сервере, подробнее см. документацию по используемому Display Manager’у):
Описание настройки с иллюстрациями под катом
То при запуске Xming (через мастер XLaunch или с нужными параметрами) мы увидим окно авторизации в системе:
Если авторизация удалась, то мы увидим рабочий стол удаленного компьютера.
Чтобы каждый раз не вписывать и не выбирать вручную все параметры в мастере XLaunch, можно воспользоваться двумя способами:
1. Как ранее говорилось, сохранить конфигурацию в файл *.xlaunch (например xdmcp.xlaunch) и запускать мастер XLaunch, указывая ему с помощью ключа -load файл конфигурации. Мастер XLaunch запустится, но все поля в окнах будут уже предварительно заполнены. Это удобно, если нужно соединяться по XDMCP с несколькими серверами, различающимися только, например, IP-адресом. Можно создать ярлык, в свойствах которого указать параметры к запуску XLaunch:
"C:\Program Files\Xming\XLaunch.exe" -load xdmcp.xlaunch
2. Создать ярлык Xming с нужными параметрами:
"C:\Program Files\Xming\Xming.exe" :0 -clipboard -query 10.10.3.24 -dpi 96
Естественно, вместо 10.10.3.24 нужно подставить свой адрес удаленной машины с XDMCP, а число после -dpi выбрать под свои глаза и монитор.
1. Удаленный доступ по XDMCP (удаленное подключение к рабочему столу)
2.What Ports Need to be Opened for XDMCP
3.Xdmcp