🥷 Джонни вещает: обходим блокировку VPN

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

— Стоит добавить, что nftables и nfqws работает у меня, но это не значит, что заработает и у вас! Возможно, вам придётся изменить некоторые параметры. (очень внимательно читаем комментарий по ссылке выше и штудируем, как портировать правила iptables в nftables.)

$ iptables-translate -A OUTPUT -t mangle -o wlan0 -p udp --dport 443 -m mark ! --mark 0x40000000/0x40000000 -j NFQUEUE --queue-num 220 --queue-bypass

И получилось:

$ nft 'add rule ip mangle OUTPUT oifname "wlan0" udp dport 443 mark and 0x40000000 != 0x40000000 counter queue num 220 bypass'

wlan0 — интерфейс, через который мы ходим в сеть, 443 — порт подключения к VPN сервису, и меняем OUTPUT на output:

$ nft 'add rule ip mangle output oifname "wlan0" udp dport { 443, 18189 } mark and 0x40000000 != 0x40000000 counter queue num 220 bypass' (у меня два VPN коннекта, отсюда и два порта)

🖥 Перед запуском, проверяем, что у нас есть таблица ip mangle:

$ nft list tables

В случае, если нет создаём её и цепочку output:

$ nft add table ip mangle
$ nft 'add chain ip mangle output { type filter hook output priority 0 ; }'

Смотрим, что всё создалось: $ nft -a list table ip mangle теперь запускаем строку с добавлением нового правила и снова проверяем, что внутри таблицы, и последнее, запускаем демон, который маскирует пакеты отправленные на требуемые порты:

$ /opt/zapret/nfq/nfqws --uid 2 --qnum=220 --dpi-desync=fake --dpi-desync-any-protocol --dpi-desync-cutoff=d2 --dpi-desync-repeats=10 --dpi-desync-ttl=5 --daemon

❗️ Обратите внимание, значение ttl у вас может отличаться. Своё я подглядел через ps aux | grep nfqws, которое стоит в демоне от zapret.

#VPN #РКН

🥷 Разработка Nginx перешла с Mercurial на Git и GitHub

Разработчики Nginx перенесли официальный репозиторий проекта на GitHub и задействовали платформы GitHub Issues и GitHub Discussions вместо системы отслеживания ошибок trac.nginx.org и обсуждений в почтовых рассылках.

Для приёма изменений от других участников проекта и разработчиков реализована возможность использования pull-запросов. Система отслеживания ошибок trac.nginx. org переведена в режим только для чтения. Для того, чтобы дать разработчикам и пользователям время на адаптацию к новому укладу, кроме использования GitHub, до 31 декабря будет сохранена возможность отправки патчей и получения консультаций через списки рассылки.

#nginx

🥷 Джонни вещает: проброс портов

Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

🆘 Для понимания ситуации пример ниже будет ссылаться на вот эту схему (click)

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.

Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8

🖥 Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А. Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.

#SSH #NAT | 😊 @iscode

⌨️ Большая подборка вопросов с собеседований: Системного администратора Linux/Devops

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

1. Вопросы для интервью системного администратора Linux/DevOps
2. Вопросы системного администратора
3. 100 важных вопросов на собеседовании по Linux с ответами
4. Подборка вопросов для собеса с системным администратором Linux/DevOps
5. Дополнительные вопросы для собеседования с системным администратором
6. Полезный материал для подготовки к собеседованию на должность инженера DevOps: Исчерпывающее руководство

#Linux #DevOps #SysAdmin #Interview

⚡ Как данные передаются через Интернет? Какое это имеет отношение к модели OSI? Как TCP/IP вписывается в это?

🚠 Семь уровней модели OSI:

1. Физический уровень
2. Канальный уровень
3. Сетевой уровень
4. Транспортный уровень
5. Сеансовый уровень
6. Уровень представления
7. Прикладной уровень

#Network #OSI | 🏃‍♂️ @iscode

🥷 Джонни вещает: откуда этот конфиг? [Debian/Ubuntu]

Цель этого поста: показать технику отладки в debian/ubuntu, связанную с "поиском первоисточника" в системном конфигурационном файле.

🖥 Тестовый пример: после долгих издевательств над tar.gz копией установленной ОС и после её восстановления и установки апдейтов мы получаем сообщение:

update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
W: initramfs-tools configuration sets RESUME=/dev/mapper/U1563304817I0-swap
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/foobar-swap)
I: Set the RESUME variable to override this.

🕹 Цель: понять, откуда это значение (U1563304817I0) пришло и как его правильно поменять. Это первый попавшийся пример, не особо интересный сам по себе, но удобный, чтобы показать практические методы работы с Linux.

Шаг номер 1: Откуда пришёл RESUME?

# cd /etc
# grep -r RESUME
initramfs-tools/conf.d/resume:RESUME=/dev/mapper/U1563304817I0-swap

Мы рекурсивно (-r) ищем упоминание этой переменной в каталоге /etc (там, где большинство конфигов). Мы находим conf.d сниппет, который явно используется пакетом initramfs-tools.

Теперь новый вопрос, а откуда этот сниппет? - есть три варианты:
1. Магический артефакт(кто-то положил и забыл ✋)
2. Конфиг из пакета
3. Конфиг, сгенерированный каким-то скриптом из системных пакетов

Теперь проверяем c помощью dpkg -S он позволяет нам поискать по базе установленных файлов и найти к какому пакету файл относится.

dpkg -S initramfs-tools/conf.d/resume
dpkg-query: no path found matching pattern *initramfs-tools/conf.d/resume*

Вот пример удачного поиска:

dpkg -S resolv.conf
manpages: /usr/share/man/man5/resolv.conf.5.gz
systemd: /lib/systemd/resolv.conf

Возвращаемся к нашей задаче: файл initramfs-tools/conf.d/resume не устанавливается в систему из пакета. Может быть он генерируется в postinst/preinst скрипте пакета? Проверяем третью версию 😡

# cd /var/lib/dpkg/info/
# grep -r initramfs-tools/conf.d/resume *
initramfs-tools-core.postrm: rm -f /etc/initramfs-tools/conf.d/resume

В каталоге /var/lib/dpkg/info/ лежат распакованные версии всех "метафайлов" пакетов (скрипты установки/удаления, описания пакетов и т.д.). Удивительно, но этот файл удаляется в postrm (при удалении) пакета initramfs-tools-core. Посмотрим содержимое его postinst… Ничего, касающегося conf.d директории.

Давайте взглянем на файлы из состава пакета initramfs-tools-core.

# dpkg -L initramfs-tools-core
...
/usr/share/initramfs-tools/hooks/resume
...

Команда dpkg -L позволяет посмотреть все файлы, которые есть в системе от указанного пакета. Я выделил интересный для изучения файл. Изучение файла показывает как эта переменная используется, но не отвечает откуда он появляется.

💳 Если пост понравился, жду от вас реакций и выпускаю на ту же тему, но уже о базе ответов debconf

#Debian #Ubuntu #dpkg