С помощью создания виртуальных интерфейсов и отдельного сетевого пространства имён, nsntrace запускает нужное нам приложение, и выполняет трассировку трафика только для него используя libpcap. Результат работы может быть либо перенаправлен в другое приложение, либо в файл, который можно будет прочитать любой стандартной утилитой, умеющей работать с pcap.

1. Ставим nsntrace из репозитория:

# apt install nsntrace
# dnf install nsntrace

2. Пробуем выполнить захват трафика для обычного wget, который обращается к сайту. По-умолчанию, дамп будет иметь имя nsntrace.pcap:

# nsntrace --use-public-dns wget -q -O /dev/null https://sysadmin.pm/
Starting network trace of 'wget' on interface enp1s0.
Your IP address in this trace is 172.19.28.255.
Use ctrl-c to end at any time.
Finished capturing 131 packets.

Аналогично для PHP скрипта, например:

# nsntrace php -f index.php
Starting network trace of 'php' on interface enp1s0.
Your IP address in this trace is 172.19.213.255.
Use ctrl-c to end at any time.
Finished capturing 52 packets.

3. Работаем с дампом привычной утилитой, в данном случае tcpick:

# tcpick -r nsntrace.pcap 
Starting tcpick 0.2.1 at 2023-04-28 12:28 MSK
Timeout for connections is 600
tcpick: reading from nsntrace.pcap
1 SYN-SENT 172.19.28.255:40638 > 104.244.78.134:https
1 SYN-RECEIVED 172.19.28.255:40638 > 104.244.78.134:https
1 ESTABLISHED 172.19.28.255:40638 > 104.244.78.134:https
1 FIN-WAIT-1 172.19.28.255:40638 > 104.244.78.134:https
1 FIN-WAIT-2 172.19.28.255:40638 > 104.244.78.134:https
1 RESET 172.19.28.255:40638 > 104.244.78.134:https
tcpick: done reading from nsntrace.pcap

131 packets captured
1 tcp sessions detected

Собрать nsntrace из исходников, при необходимости можно так:

# apt install automake docbook-xml docbook-xsl iptables libnl-route-3-dev libpcap-dev pkg-config xsltproc git make gcc
# git clone https://github.com/nsntrace/nsntrace
# cd nsntrace/
# ./autogen.sh 
# ./configure 
# make

Github проекта: https://github.com/nsntrace/nsntrace

Сообщение nsntrace появились сначала на Записки админа.

Инструмент пришёл на помощь в ситуации, когда появилась необходимость увидеть, проходит ли трафик через нужные цепочки iptables.

Установка и сборка.

Здесь ничего сложного. Нам потребуются git и go в системе. Устанавливаем всё необходимое и собираем:

# dnf install git go
# git clone https://github.com/x-way/iptables-tracer
# cd ./iptables-tracer/
# go build

Результатом сборки будет бинарный файл iptables-tracer в директории.

Использование.

Важно понимать, что при остановке iptables-tracer (запущенного с параметрами или без), созданные правила удалены не будут, это нужно сделать самостоятельно, выполнив команду с аргументом -с:

# ./iptables-tracer -c

Будучи запущенным без каких-либо аргументов, трейсер будет выводить информацию о udp трафике имеющем dport 53.

# ./iptables-tracer 
12:36:02.455805 raw OUTPUT 0x00000000 0x00000000 IP 95.216.163.224.33873 > 185.12.64.1.53: 21597+ A? sysadmin.pm. (29) [In: Out:eth0]
...
12:36:02.456483 raw OUTPUT 0x00000000 0x00000000 IP 95.216.163.224.33873 > 185.12.64.1.53: 61055+ AAAA? sysadmin.pm. (29) [In: Out:eth0]

При этом, в списке правил iptables можно увидеть следующее:

# iptables-save | grep nflog
-A PREROUTING -p udp -m udp --dport 53 -j NFLOG --nflog-prefix "iptr:4701:0" --nflog-group 22
-A INPUT -p udp -m udp --dport 53 -j NFLOG --nflog-prefix "iptr:4701:1" --nflog-group 22
-A OUTPUT -p udp -m udp --dport 53 -j NFLOG --nflog-prefix "iptr:4701:2" --nflog-group 22
...
-A OUTPUT -p udp -m udp --dport 53 -j NFLOG --nflog-prefix "iptr:4701:13" --nflog-group 22

При необходимости, мы можем отфильтровать только нужный нам трафик с помощью параметра -f и уже знакомого нам iptables синтаксиса. Например, отобразить информацию о трафике, поступающем с IP адреса 5.189.221.98 на порт 22. С помощью параметра -t мы указываем время в течение которого информация будет проверяться:

# ./iptables-tracer -f "-s 5.189.221.98 -p tcp --dport 22" -t 90s

12:50:27.599117 raw PREROUTING 0x00000000 0x00000000 IP 5.189.221.98.59996 > 95.216.163.224.22: Flags [S], seq 446722502, win 64240, options [mss 1203,sackOK,TS val 2477044911 ecr 0,nop,wscale 7], length 0 [In:eth0 Out:]
12:50:27.599259 mangle PREROUTING 0x00000000 0x00000000 IP 5.189.221.98.59996 > 95.216.163.224.22: Flags [S], seq 446722502, win 64240, options [mss 1203,sackOK,TS val 2477044911 ecr 0,nop,wscale 7], length 0 [In:eth0 Out:]
12:50:27.599870 mangle INPUT 0x00000000 0x00000000 IP 5.189.221.98.59996 > 95.216.163.224.22: Flags [S], seq 446722502, win 64240, options [mss 1203,sackOK,TS val 2477044911 ecr 0,nop,wscale 7], length 0 [In:eth0 Out:]
12:50:27.600005 filter INPUT 0x00000000 0x00000000 IP 5.189.221.98.59996 > 95.216.163.224.22: Flags [S], seq 446722502, win 64240, options [mss 1203,sackOK,TS val 2477044911 ecr 0,nop,wscale 7], length 0 [In:eth0 Out:]

• Исходный код и чуть больше подробностей на Github странице проекта.

Сообщение iptables-tracer появились сначала на Записки админа.

OpenVPN сервер.

1. Первичная подготовка.

Устанавливаем необходимые пакеты и готовим окружение.

# dnf install openvpn easy-rsa firewalld zip

# mkdir -p /etc/openvpn/easy-rsa/keys
# cp -arvp /usr/share/easy-rsa/3/* /etc/openvpn/easy-rsa/
# cp /etc/openvpn/easy-rsa/openssl-easyrsa.cnf /etc/openvpn/easy-rsa/openssl.cnf

2. Создаём сертификаты.

Открываем файл /etc/openvpn/easy-rsa/vars и при необходимости указываем в нём нужные данные:

export KEY_COUNTRY="RU"
export KEY_PROVINCE="RU"
export KEY_CITY="Vologda"
export KEY_ORG="VologdaVPN"
export KEY_EMAIL="info@vologdavpn.com"
export KEY_OU="VologdaVPN"

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

# cd /etc/openvpn/easy-rsa
# ./easyrsa init-pki
# ./easyrsa build-ca
# ./easyrsa gen-dh
# ./easyrsa build-server-full server nopass
# ./easyrsa gen-crl
# openvpn --genkey --secret /etc/openvpn/easy-rsa/pki/ta.key
# cp -rp /etc/openvpn/easy-rsa/pki/{ca.crt,dh.pem,crl.pem,ta.key,issued,private} /etc/openvpn/server/

3. Пишем конфиг OpenVPN сервера.

Открываем файл /etc/openvpn/server/server.conf и прописываем следующее…

# cat /etc/openvpn/server.conf 
local 1.2.3.4
port 3333
proto udp
dev tun
ca ca.crt
cert issued/server.crt
key private/server.key
dh dh.pem
crl-verify crl.pem
tls-auth ta.key 0
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
keepalive 10 120
user nobody
group nobody
persist-key
persist-tun
mssfix
fragment 1300
sndbuf 524288
rcvbuf 524288
push "sndbuf 524288"
push "rcvbuf 524288"
log openvpn.log
verb 5

1.2.3.4 здесь — это IP сервера, 3333 — порт, на котором будет работать сервер. При необходимости, ведение лога можно перенаправить в /dev/null. В данной конфигурации так же используется увеличенный буфер. Подробнее об этом нужно прочитать в отдельной заметке.

Конфиг сохраняем, сервис openvpn перезапускаем и добавляем его в автозапуск.

# systemctl -f enable openvpn-server@server.service
# systemctl restart openvpn-server@server.service

4. Настраиваем firewalld и разрешаем форвардинг.

Запускаем firewalld, если он ещё не был запущен ранее.

# systemctl -f enable firewalld
# systemctl restart firewalld

Активируем masquerade:

# firewall-cmd --permanent --add-masquerade
# INTFS=$(ip route get 8.8.8.8 | awk 'NR==1 {print $(NF-2)}')
# firewall-cmd --permanent --direct --passthrough ipv4 -t nat -A POSTROUTING -s 10.8.0.0/24 -o $INTFS -j MASQUERADE
# firewall-cmd --reload

Включаем форвардинг:

# cat /etc/sysctl.conf 
net.ipv4.ip_forward = 1 
# sysctl -p

Открываем порт для соединения (в нашем случае это 3333). Для работы VPN по UDP, открыть нужно UDP порт:

# firewall-cmd --permanent --zone=public --add-port=3333/udp

Для работы по TCP, соответственно:

# firewall-cmd --permanent --zone=public --add-port=3333/tcp

Не забываем перезапустить firewalld:

# firewall-cmd --reload

5. Не забываем о SELinux:

Порт 3333 нужно заменить на тот, что будет использоваться в конфиге сервера. В примере ниже разрешение даётся для udp на 3333 порте.

# semanage port -a -t openvpn_port_t -p udp 3333

6. Создаём сертификаты для клиента.

В примере, для клиента используется имя client, пароль для его сертификата так же не указывается. Для создания сертификата с паролем, вторая команда должна быть выполнена без nopass.

# cd /etc/openvpn/easy-rsa
# ./easyrsa build-client-full client nopass
# mkdir /root/clientserts
# cp /etc/openvpn/easy-rsa/pki/{ca.crt,issued/client.crt,private/client.key,ta.key} /root/clientserts/
# cd /root/
# zip -r -9 clientserts.zip clientserts/

7. Отзываем сертификат для клиента.

При необходимости отозвать сертификат и не дать возможности клиенту подключиться к серверу, необходимо сделать следующее (в примере описан отзыв для клиента client):

Отзываем сертификат:

# cd /etc/openvpn/easy-rsa/
# ./easyrsa revoke client

Генерируем список отозванных сертификатов (CRL). И копируем его в директорию vpn сервера:

# ./easyrsa gen-crl
# mv /etc/openvpn/easy-rsa/pki/crl.pem /etc/openvpn/server/

CRL в конфиге сервера подключается с помощью строки:

crl-verify crl.pem

Файл нужно переносить в директорию vpn сервера каждый раз, как новый сертификат будет отозван. После этого, сервер необходимо перезаустить:

# systemctl restart openvpn-server@server.service

OpenVPN клиенты.

Настраиваем подключение в Linux, с помощью NetworkManager следующим образом…

client
remote '1.2.3.4'
cert '/home/USER/.ovpn/client.crt'
key '/home/USER/.ovpn/client.key'
ca '/home/USER/.ovpn/ca.crt'
mssfix
fragment 1300
dev tun
proto udp
port 3333
tls-auth '/home/USER/.ovpn/ta.key' 1
nobind
auth-nocache
script-security 2
persist-key
persist-tun
user nm-openvpn
group nm-openvpn

Настраиваем подключение в Windows следующим образом…

client
remote 1.2.3.4 3333
ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\client.crt"
key "C:\\Program Files\\OpenVPN\\config\\client.key"
tls-auth 'C:\\Program Files\\OpenVPN\\config\\ta.key' 1
comp-lzo yes
mssfix
fragment 1300
dev tun
proto udp
nobind
auth-nocache
script-security 2
persist-key
persist-tun

После того, как OpenVPN настроен, а подключение к нему установлено, имеет смысл сразу же проверить, всё ли работает корректно. Например можно зайти на 2ip.ru и посмотреть, какой IP и какая информация о подключении отображается там. Если всё сделано верно, 2ip покажет вместо нашего реального IP, адрес настроенного только что сервера. С этого момента, можно приступать к работе в сети.

Сообщение OpenVPN Fedora Server появились сначала на Записки админа.

В использовании очень проста:

1. Скачиваем libtree:

$ wget https://github.com/haampie/libtree/releases/download/v3.0.1/libtree_x86_64 -O libtree
$ chmod +x libtree

2. И просто проверяем нужный нам файл:

$ ./libtree /bin/nano
/bin/nano 
├── libmagic.so.1 [default path]
│ └── libz.so.1 [default path]
├── libtinfo.so.6 [default path]
└── libncursesw.so.6 [default path]
└── libtinfo.so.6 [default path]

При необходимости углубиться и получить зависимости для отображаемых библиотек просто добавляем -v, -vv или -vvv соответственно.

$ ./libtree -vvv /bin/nano
/bin/nano 
├── libmagic.so.1 [default path]
│ ├── libz.so.1 [default path]
│ │ └── libc.so.6 [default path]
│ │ └── ld-linux-x86-64.so.2 [default path]
│ └── libc.so.6 [default path]
│ └── ld-linux-x86-64.so.2 [default path]
├── libc.so.6 [default path]
│ └── ld-linux-x86-64.so.2 [default path]
├── libtinfo.so.6 [default path]
│ └── libc.so.6 [default path]
│ └── ld-linux-x86-64.so.2 [default path]
└── libncursesw.so.6 [default path]
├── libtinfo.so.6 [default path]
│ └── libc.so.6 [default path]
│ └── ld-linux-x86-64.so.2 [default path]
└── libc.so.6 [default path]
└── ld-linux-x86-64.so.2 [default path]

Отобразить полный путь до файла на сервере можно с помощью опции -p:

$ ./libtree -p -vvv /bin/ping
/bin/ping 
├── /lib64/libcap.so.2 [default path]
│ └── /lib64/libc.so.6 [default path]
│ └── /lib64/ld-linux-x86-64.so.2 [default path]
├── /lib64/libc.so.6 [default path]
│ └── /lib64/ld-linux-x86-64.so.2 [default path]
└── /lib64/libidn2.so.0 [default path]
├── /lib64/libunistring.so.2 [default path]
│ └── /lib64/libc.so.6 [default path]
│ └── /lib64/ld-linux-x86-64.so.2 [default path]
└── /lib64/libc.so.6 [default path]
└── /lib64/ld-linux-x86-64.so.2 [default path]

По умолчанию, информация о некоторых библиотеках не выводится в libtree. Подробнее об этом в выводе команды:

$ ./libtree --help

• Исходный код и готовые сборки доступны на Github странице проекта.

Сообщение libtree — shared libraries в виде дерева появились сначала на Записки админа.

Установка и использование.

Каких-то специфических шагов для установки делать не потребуется, но наличие wget (почему-то без него первый запуск скрипта не выполнялся корректно) и tar будет обязательным.

# dnf install git wget tar

Исполняемый файл static-get — это по сути скрипт, так что достаточно будет просто клонировать репозиторий с ним, и он уже будет готов к использованию.

# git clone https://github.com/minos-org/minos-static
# cd minos-static/
# ./static-get

Итак, с помощью скрипта мы можем: выполнить поиск нужной программы, скачать архив с ней, обновить её при необходимости, установить программу в систему и удалить её.

Скрипту так же можно передать некоторые параметры для работы — в каком репозитории искать пакеты, для какой архитектуры, какого формата они должны быть. Имеется возможность выполнить dry-run запуск или выполнить установку в verbose режиме. Несколько примеров работы ниже:

— Скачиваем и запускаем nano:

# ./static-get --extract nano
# ./nano/bin/nano --version
GNU nano, version 2.4.2
(C) 1999..2015 Free Software Foundation, Inc.
Email: nano@nano-editor.org Web: http://www.nano-editor.org/
Compiled options: --disable-libmagic --disable-nls --disable-utf8

— Устанавливаем qemu в систему:

# ./static-get --install qemu
qemu-1.4.0-1.tar.xz
# /bin/qemu-io --version
qemu-io version 0.0.1

— Удаляем qemu:

# ./static-get --remove qemu
# /bin/qemu-io --version
-bash: /bin/qemu-io: No such file or directory

— Ищем gcc в репозитории:

# ./static-get --search gcc
gcc-4.6.1-2.tar.xz:672ba63bc0dd505104f22e4c3295c0e6

В своей работе static-get базируется на нескольких проектах — bifrost-autobuild, morpheus-autobuild, rlsd2-autobuild, misc-autosync. Бинарные файлы описываются в специальных рецетах (предпочтительны рецепты для bifrost), а после сборки архивы с пакетами публикуются в репозитории s.minos.io, откуда скриптом и выполняется установка.

• Github репозиторий проекта.
• s.minos.io

Сообщение Static-get или портативные утилиты в Linux. появились сначала на Записки админа.

Установка и использование.

1. Скачиваем и распаковываем готовый бинарник:

# wget https://github.com/pete911/certinfo/releases/download/v1.0.4/certinfo_1.0.4_linux_amd64.tar.gz
# tar xvfz certinfo_1.0.4_linux_amd64.tar.gz

2. Выполняем запрос к нужному нам сайту и получаем информацию о цепочке сертификатов на нём:

# ./certinfo sysadmin.pm:443
--- [sysadmin.pm:443 TLS 1.3] ---
Version: 3
Serial Number: 357258883031263162612859040933879589183273
Signature Algorithm: SHA256-RSA
...
Subject: CN=ISRG Root X1,O=Internet Security Research Group,C=US
DNS Names: 
IP Addresses: 
Key Usage: Cert Sign, CRL Sign
Ext Key Usage: 
CA: true
--- 1 verified chains ---

3. Либо указываем конкретный файл сертификата или цепочки сертификатов для вывода информации о нём:

# cat /etc/letsencrypt/live/sysadmin.pm/chain.pem | ./certinfo 
--- [stdin] ---
Version: 3
Serial Number: 192961496339968674994309121183282847578
Signature Algorithm: SHA256-RSA
Type: intermediate
Issuer: CN=ISRG Root X1,O=Internet Security Research Group,C=US
...

Проверка срока действия сертификатов.

Проверка срока действия сертификатов с помощью certinfo доступна с ключём -expiry:

• Проверка сертификата на сайте:

# ./certinfo --expiry sysadmin.pm:443
--- [sysadmin.pm:443 TLS 1.3] ---
Subject: CN=sysadmin.pm
Expiry: 1 months 29 days 0 hours 9 minutes

Subject: CN=R3,O=Let's Encrypt,C=US
Expiry: 3 years 9 months 24 days 2 hours 39 minutes

Subject: CN=ISRG Root X1,O=Internet Security Research Group,C=US
Expiry: 2 years 10 months 9 days 4 hours 53 minutes

• Проверка сертификатов в системе:

# ls -d /etc/ssl/certs/*.crt | xargs ./certinfo -expiry
...
Subject: CN=emSign Root CA - C1,OU=emSign PKI,O=eMudhra Inc,C=US
Expiry: 21 years 2 months 27 days 5 hours 9 minutes

Subject: CN=emSign Root CA - G1,OU=emSign PKI,O=eMudhra Technologies Limited,C=IN
Expiry: 21 years 2 months 27 days 5 hours 9 minutes

Исходный код и дополнительные инструкции доступны в Github репозитории проекта.

Сообщение Certinfo — информация о сертификате появились сначала на Записки админа.