СиСА Вики

Appearance

Самостоятельная работа
Тема: Протоколы сетевого взаимодействия в GNU/Linux: DNS, SSH, FTP, NFS, SMB, iSCSI

Блок теории ​

1. DNS (Domain Name System) ​

DNS — это распределённая система, отвечающая за преобразование доменных имён (например, example.com) в IP-адреса (например, 93.184.216.34) и наоборот. В GNU/Linux процесс разрешения имён (name resolution) осуществляется с участием нескольких компонентов: резолвера, библиотеки libc, файлов конфигурации и, при необходимости, локального кэширующего DNS-сервера (например, systemd-resolved, dnsmasq).

Как работает резолвер в Linux ​

Резолвер — это программный компонент, реализованный в библиотеке glibc, который отвечает за выполнение DNS-запросов. При вызове функций, таких как getaddrinfo() или gethostbyname(), резолвер:

  1. Определяет, откуда брать информацию о преобразовании имён, используя механизм Name Service Switch (NSS).
  2. Обращается к DNS-серверам, указанным в файле /etc/resolv.conf.
  3. Выполняет рекурсивные или кэшированные запросы к DNS-серверам.
  4. Возвращает IP-адрес приложению.
Файл /etc/resolv.conf ​

Этот файл содержит список DNS-серверов, используемых системой:

conf
nameserver 8.8.8.8
nameserver 1.1.1.1
search example.com
  • nameserver — IP-адрес DNS-сервера.
  • search — домены, которые добавляются к коротким именам (например, ping server → server.example.com).
  • options — дополнительные параметры (например, timeout, attempts).

⚠️ В современных системах (с systemd-networkd или NetworkManager) /etc/resolv.conf часто является симлинком на /run/systemd/resolve/stub-resolv.conf или управляется автоматически.

Name Service Switch (/etc/nsswitch.conf) ​

Файл /etc/nsswitch.conf определяет порядок и источники, из которых система получает информацию о хостах, пользователях, группах и т.д.

Для DNS особенно важна строка:

conf
hosts: files dns myhostname
  • files — сначала проверяется /etc/hosts.
  • dns — если в /etc/hosts нет записи, запускается DNS-запрос.
  • myhostname — разрешение имени локальной машины (важно для localhost, FQDN и т.п.).

Таким образом, при обращении к google.com система:

  1. Проверяет /etc/hosts.
  2. Если не найдено — запрашивает DNS через резолвер.
Кэширование и ускорение ​

Для повышения производительности можно использовать локальные DNS-кэши:

  • systemd-resolved — интегрирован в systemd, кэширует ответы и может работать как stub resolver.
  • dnsmasq — легковесный DNS-прокси с кэшированием.
  • unbound — полноценный рекурсивный DNS-сервер.

2. SSH (Secure Shell) ​

SSH — это криптографический сетевой протокол для безопасного удалённого доступа к системам. В GNU/Linux основной реализацией является OpenSSH (openssh-server, openssh-client).

Основные возможности SSH ​
  • Удалённое выполнение команд через ssh user@host.
  • Безопасная передача файлов через scp, sftp.
  • Аутентификация по паролю или по ключам (SSH keys).
  • Шифрование всех передаваемых данных (с использованием TLS-подобных алгоритмов).
Конфигурационные файлы ​
  • /etc/ssh/sshd_config — настройки сервера SSH.
  • ~/.ssh/config — пользовательские настройки клиента.
  • ~/.ssh/authorized_keys — ключи для аутентификации по ключу.
  • ~/.ssh/known_hosts — список известных хостов и их отпечатков.
SSH-ключи ​

Генерация ключей:

bash
ssh-keygen -t ed25519 -C "user@host"

Публичный ключ копируется на сервер:

bash
ssh-copy-id user@remote_host
SSH-туннелирование (Port Forwarding) ​

SSH позволяет создавать безопасные туннели для перенаправления трафика. Это особенно полезно для обхода фаерволов, шифрования незащищённых протоколов или доступа к внутренним сервисам.

1. Локальное проброс портов (Local Port Forwarding) ​

Перенаправляет порт с локальной машины на удалённый сервер через SSH-туннель.

Пример: доступ к веб-интерфейсу на remote_host:8080 через localhost:9000:

bash
ssh -L 9000:localhost:8080 user@remote_host

Теперь запросы к http://localhost:9000 будут перенаправлены на remote_host:8080.

Примечание: localhost в 8080 — это с точки зрения remote_host.

2. Удалённое проброс портов (Remote Port Forwarding) ​

Открывает порт на удалённом сервере, который перенаправляет трафик обратно на локальную машину.

Пример: предоставить доступ к локальному веб-серверу (на localhost:3000) через порт 8080 на удалённом сервере:

bash
ssh -R 8080:localhost:3000 user@remote_host

Теперь пользователи на remote_host могут зайти на http://localhost:8080 и попасть на ваш локальный сервер.

Требует настройки GatewayPorts yes в /etc/ssh/sshd_config, если нужно, чтобы туннель был доступен не только с localhost.

3. Динамическое проброс портов (SOCKS Proxy) ​

Создаёт локальный SOCKS-прокси, через который можно направлять любой трафик.

bash
ssh -D 1080 user@remote_host

После этого можно настроить браузер или систему на использование SOCKS5-прокси localhost:1080, и весь трафик будет шифроваться и проходить через SSH-туннель.

Применение туннелирования ​
  • Безопасный доступ к базам данных (например, MySQL на 3306).
  • Работа с веб-интерфейсами внутренних сервисов.
  • Обход цензуры или фаерволов.
  • Защита незашифрованных протоколов (HTTP, FTP и т.д.).

3. FTP (File Transfer Protocol) ​

FTP — старый протокол для передачи файлов. Имеет две версии:

  • Active FTP: сервер инициирует соединение к клиенту (проблемы с NAT/фаерволами).
  • Passive FTP: клиент инициирует все соединения (более совместим с NAT).

В GNU/Linux FTP-клиенты: ftp, lftp, wget, curl.
FTP-серверы: vsftpd, proftpd, pure-ftpd.

FTP передаёт данные и пароли в открытом виде — небезопасен. Для безопасной передачи файлов рекомендуется использовать SFTP (через SSH) или FTPS (FTP over SSL/TLS).

Практические задания по FTP опущены.

4. NFS (Network File System) ​

NFS — протокол, разработанный Sun Microsystems, для монтирования удалённых файловых систем в Unix-подобных системах. Наиболее распространённая версия — NFSv4.

В GNU/Linux:

  • Сервер: пакет nfs-kernel-server, конфигурация — /etc/exports.
  • Клиент: nfs-common, монтирование через mount -t nfs.

NFS использует RPC (Remote Procedure Call) и требует запуска демонов (rpcbind, nfsd).

Особенности:

  • Прозрачное монтирование.
  • Поддержка прав доступа (UID/GID).
  • NFSv4 добавляет поддержку Kerberos и работает через один порт (2049).

Практические задания по NFS опущены.

5. SMB (Server Message Block) ​

SMB — протокол для доступа к файлам, принтерам и другим ресурсам в сетях. Используется в Windows, но в GNU/Linux реализуется через Samba.

Samba позволяет:

  • Предоставлять общие папки Linux для Windows.
  • Подключаться к Windows-шарам с Linux.
  • Интегрироваться в домены Active Directory.

Клиентские утилиты: smbclient, mount.cifs.
Конфигурация сервера — /etc/samba/smb.conf.

Практические задания по SMB опущены.

6. iSCSI (Internet Small Computer System Interface) ​

iSCSI — протокол, позволяющий передавать команды SCSI по IP-сети. Используется для построения SAN (Storage Area Network).

В GNU/Linux:

  • Initiator (клиент): open-iscsi, утилиты iscsiadm.
  • Target (сервер): targetcli, tgtd.

iSCSI позволяет монтировать удалённые диски как локальные блочные устройства (/dev/sdX). После подключения диск можно форматировать, размечать, использовать как обычный HDD.

Пример подключения:

bash
iscsiadm -m discovery -t st -p 192.168.1.100
iscsiadm -m node -l

Практические задания по iSCSI опущены.

Вывод ​

DNS, SSH, FTP, NFS, SMB и iSCSI — ключевые протоколы сетевого взаимодействия в GNU/Linux. Каждый из них решает свою задачу: от разрешения имён до удалённого доступа и передачи данных.

Особое внимание в современных системах уделяется безопасности:

  • DNS защищается через DNSSEC и DoT/DoH (не рассмотрено, но актуально).
  • SSH обеспечивает шифрование и мощные механизмы туннелирования.
  • FTP постепенно заменяется SFTP/SCP.
  • NFS и SMB требуют правильной настройки политик доступа.
  • iSCSI используется в защищённых средах с аутентификацией CHAP.

Понимание работы этих протоколов, особенно на уровне конфигурации Linux (nsswitch.conf, /etc/resolv.conf, SSH-ключи, туннели), необходимо для администрирования сетевых систем.

Протокол smb ​

Используя консоль ​

Создаем папку, которая будет общей; назначаем ей права

mkdir /home/docstore; chmod 777 /home/docstore

Делаем бэкап конфигурационного файла самбы

mv /etc/samba/smb.conf /etc/samba/smb.conf.old

Папка без пароля ​

Прописываем в /etc/samba/smb.conf следующие параметры

bash
[global]
dos charset = CP866
unix charset = utf8
#имя рабочей группы
workgroup = WORKGROUP
#имя сервера
server string = Filestore
#группа пользователей
security = USER
map to guest = Bad User

#имя ресурса
[Public] 
#путь к папке
path = /home/docstore 
guest ok = Yes
browseable = yes
writable = yes
create mask = 0777
directory mask = 0777

Создаем служебный каталог:

bash
mkdir -p /var/lib/samba/private

Перезапускаем сервис SMB:

bash
systemctl restart smb.service nmb.service

Включаем автозапуск:

bash
systemctl enable smb.service nmb.service

Добавление второй папки без пароля ​

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

В первом примере у нас Public и папка docstore. Во втором будет Share и files.

Создаем папку

bash
mkdir /home/files;chmod 777 /home/files

Прописываем в /etc/samba/smb.conf следующие параметры

bash
[Share]
path = /home/files
read only = Yes
guest ok = Yes
browseable = yes
writable = yes
create mask = 0777
directory mask = 0777

Перезапускаем сервис SMB:

bash
systemctl restart smb.service nmb.service

Папка с паролем ​

Создадим пользователя в системе, имя пользователя share, его пароль 1q@W3e, при создании сделаем каталог пользователя (ключ -m) и зададим пароль (ключ -p).

bash
useradd -m share -p 1q@W3e

Назначим нового владельца, пользователя share, и несколько изменим разрешения:

bash
mkdir /home/kadry;chmod 777 /home/kadry
chown -R share:users /home/kadry
chmod -R ugo+rwx /home/kadry

Примечание: Утилита smbpasswd находится в пакете samba-client

Добавляем пользователя в Samba (вводим пароль 1q@W3e):

bash
smbpasswd -a share

Добавим в smb.conf следующее:

bash
[Kadry]
comment = Кадры
path = /home/kadry
read only = no
guest ok = no
browseable = yes
writable = yes
create mask = 0777
directory mask = 0777
force user = share
force group = users

Папка будет доступна пользователю share с паролем 1q@W3e.

Перезапускаем сервис SMB:

bash
systemctl restart smb.service nmb.service

Используя графический интерфейс ​

bash
systemctl enable --now smb
systemctl enable --now nmb

Создаем папку в удобной директории. Нажимаем по ней ПКМ - Опции публикации

Настраиваем по своему желанию и нажимаем Создать публикацию.

Протокол nfs ​

Сервер NFS ​

Настройка сервера NFS ​

Синтаксис /etc/exports ​

Все настройки NFS-сервера хранятся в файле /etc/exports.

Файл /etc/exports определяет, какие файловые системы экспортируются на удаленные узлы, и определяет параметры. Для этого файла действуют следующие синтаксические правила:

  • пустые строки игнорируются;
  • комментарии начинаются с символа решётки (#);
  • для продолжения записи на новой строке можно использовать символ обратной косой черты ();
  • каждая экспортируемая ФС должна находиться на отдельной строке;
  • списки авторизованных узлов, размещаемые после экспортированной файловой системы, должны быть разделены пробелами;
  • параметры для каждого из узлов должны быть помещены в скобки непосредственно после идентификатора узла, без пробелов, разделяющих узел и первую скобку;
  • если название экспортируемого каталога содержит пробелы, его следует заключить в двойные кавычки.

Каждая запись экспортированной файловой системы имеет следующую структуру:

bash
export host(options)

Где:

  • export — путь к экспортируемому каталогу;
  • host — узел или сеть, в которую передается экспорт;
  • options — параметры, которые будут использоваться для узла.

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

bash
/mysharedir 192.168.0.100/24(no_subtree_check,rw)  192.168.10.0/24(no_subtree_check,ro)

Некоторые опции:

  • rw/ro — установка разрешения доступа к ресурсу (чтение запись/только чтение);
  • no_subtree_check/subtree_check — если экспортируется подкаталог файловой системы, но не вся файловая система, то с опцией subtree_check сервер, проверяет, находится ли запрошенный файл в экспортированном подкаталоге. Если экспортируется вся файловая система, запрет проверки подкаталогов (no_subtree_check) может увеличить скорость передачи;
  • sync/async — синхронный/асинхронный режим доступа. Опция sync указывает, что сервер должен отвечать на запросы только после записи на диск изменений, выполненных этими запросами. Опция async указывает серверу не ждать записи информации на диск, что повышает производительность, но понижает надежность;
  • wdelay/no_wdelay — установка задержки записи на диск (установка задержки/отключение задержки, этот параметр не действует при включенной опции async);
  • hide/nohide — не отображать/отображать нелокальные ресурсы (например, примонтированые с помощью mount --bind);
  • all_squash/no_all_squash — подмена запросов от ВСЕХ пользователей на анонимного uid/gid (либо на пользователя, заданного в параметре anonuid/anongid) запрет подмены uid/gid;
  • anonuid=UID и anongid=GID — (явная) установка UID/GID для анонимного пользователя (может быть полезно, если какой либо каталог экспортируется для конкретного пользователя, заведенного в системе).

Примечание: Единственный параметр, который следует обязательно указать — это no_subtree_check или ``subtree_check`.

Имя узла (узлов) может задаваться в следующей форме:

  • один узел — FQDN-имя (которое сможет разрешить сервер), имя узла (которое сможет разрешить сервер) или IP-адрес;
  • IP-сеть — используется запись вида a.b.c.d/z, где a.b.c.d — адрес сети, а z — префикс. Также допускается формат a.b.c.d/netmask, где a.b.c.d — сеть, а netmask — маска сети (например, 192.168.100.8/255.255.255.0);
  • набор узлов — узлы определяются знаками подстановки (символ * или ?) или могут содержать списки классов символов в [квадратных скобках]. Знаки подстановки не должны использоваться в IP-адресах;
  • сетевые группы — задаются в виде @group-name, где group-name — имя сетевой группы NIS;
  • анонимный узел — задается одним символом * и будет соответствовать всем клиентам.

Для применения изменений, внесённых в файл /etc/exports необходимо выполнить команду:

bash
exportfs -ra

или перезапустить NFS-сервер:

bash
systemctl restart nfs

Запуск NFS под systemd ​

Запустить NFS-сервер и включить его по умолчанию:

bash
systemctl enable --now nfs.service 
systemctl status nfs.service

Если все команды прошли успешно и не выдавали ошибок, то сервер можно считать работающим. Дополнительно можно запустить команду exportfs, которая выведет текущие настройки на данный момент. В случае нормальной работы она должна вывести на экран записи из файла /etc/exports:

bash
exportfs
/home         	192.168.0.0/24
/exports      	192.168.0.0/24

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

Подключение к NFS-серверу можно производить вручную, а можно настроить автоматическое подключение при загрузке.

Монтирование NFS-ресурса ​

Команда монтирования:

bash
mount -t nfs -o <опции> <сервер>:/remote/export /local/directory

Где:

  • <опции> — разделённый запятыми список опций;
  • <сервер> — IP-адрес или имя NFS-сервера;

/remote/export — каталог, экспортируемый с сервера (каталог, который будет примонтирован); /local/directory — локальный каталог (каталог, в который будет примонтирован каталог, экспортируемый с сервера).

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

bash
showmount -e 192.168.0.199

Примечание: При запуске данной команды можно получить ошибку:

bash
showmount -e 192.168.0.199
clnt_create: RPC: Unable to receive

Это может происходить потому что по умолчанию rpcbind слушает только локальные запросы:

bash
ss  -tnlup | grep rpcbind
# udp   UNCONN 0      0          127.0.0.1:111        0.0.0.0:*    users:(("rpcbind",pid=4248,fd=6))      
# udp   UNCONN 0      0              [::1]:111           [::]:*    users:(("rpcbind",pid=4248,fd=8))      
# tcp   LISTEN 0      4096       127.0.0.1:111        0.0.0.0:*    users:(("rpcbind",pid=4248,fd=7))      
# tcp   LISTEN 0      4096           [::1]:111           [::]:*    users:(("rpcbind",pid=4248,fd=9))

Разрешить rpcbind прослушивать входящие соединения из сети:

bash
control rpcbind server
systemctl restart rpcbind.service
bash
ss  -tnlup | grep rpcbind
# udp   UNCONN 0      0            0.0.0.0:111        0.0.0.0:*    users:(("rpcbind",pid=4130,fd=6))      
# udp   UNCONN 0      0               [::]:111           [::]:*    users:(("rpcbind",pid=4130,fd=8))      
# tcp   LISTEN 0      4096         0.0.0.0:111        0.0.0.0:*    users:(("rpcbind",pid=4130,fd=7))      
# tcp   LISTEN 0      4096            [::]:111           [::]:*    users:(("rpcbind",pid=4130,fd=9))

Пример команды монтирования (каталог /mnt/nf должен существовать:

bash
mount -t nfs -o nfsvers=4  192.168.0.199:/home /mnt/nfs

Для проверки успешности монтирования можно использовать команду:

bash
mount | grep nfs
# ...
# 192.168.0.199:/home on /mnt/nfs type nfs4 (rw,relatime,vers=4.2,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.177,local_lock=none,addr=192.168.0.199)

Команда выдаст строку (строки) с информацией о примонтированном ресурсе (ресурсах).

Монтирование с записью в fstab ​

Для автоматического монтирования к NFS-серверу при загрузке необходимо добавить следующую строку в файл /etc/fstab:

bash
192.168.0.199:/home  /mnt/nfs   nfs   intr,soft,nolock,_netdev,x-systemd.automount    0 0

где:

  • intr — позволяет прервать процесс при необходимости;
  • soft — предотвращает от зависания в случае недоступности удалённой машины.

Кроме того, стоит убедиться, что сервис netfs запускается при старте системы.

Прежде чем изменять /etc/fstab, попробуйте смонтировать вручную и убедитесь, что всё работает.

Протокол ftp ​

Настройка FTP ​

  • Установить пакеты:
    • vsftpd
    • anonftp
  • Сделать изменения в файле /etc/xinetd.d/vsftpd
bash
disable = no      #включает сервис
  • Проверить глобальные настройки xinetd в файле /etc/xinetd.conf, обратить внимание - необходимо написать либо сеть, либо адреса, у которых будет доступ к серверу:
bash
only_from = 192.168.0.0
  • Перезапустить сервис
bash
systemctl enable --now xinetd
  • Проверить, что нужное приложение (в данном случае xinetd) слушает порт:
bash
ss -tlpn | grep "LISTEN.*:21"

Настройка межсетевого экрана для FTP, правила iptables:

bash
$IPTABLES -A INPUT -p tcp --dport 21 -j ACCEPT
$IPTABLES -A INPUT --match state --state RELATED,ESTABLISHED -j ACCEPT

Облегчающий жизнь модуль ядра (разрешает RELATED): Прописывается в /etc/net/ifaces/default/fw/iptables/modules

bash
modprobe ip_conntrack_ftp

Протокол iSCSI ​

https://www.opennet.ru/base/sys/iscsi_fedora.txt.html

Для тестов используем две машины: vm01, которая будет экспортировать раздел /dev/xvda5, и vm02, на которой настроим инициатор.

Настройка iSCSI Target ​

Для начала устанавливаем пакет scsi-target-utils и запускаем демон tgtd:

bash
apt-get install scsi-target-utils
systemctl enable --now service tgt

Теперь создаем наше целевое устройство. В качестве имени я выбрал share.server:disk1

bash
tgtadm --lld iscsi --op new --mode target --tid 1 -T share.server:disk1

В моем случае я добавляю к целевому устройству новый раздел /dev/xvda5:

bash
tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b /dev/xvda5

Теперь разрешим доступ хосту vm02 с IP-адресом 192.168.0.109:

bash
tgtadm --lld iscsi --op bind --mode target --tid 1 -I 192.168.0.109

Проверяем:

bash
tgtadm --lld iscsi --op show --mode target

Под конец не забудьте прорубить "дырку" в брандмауэре для порта 3260/tcp, который используется по умолчанию.

Настройка iSCSI Initiator ​

Устанавливаем пакет iscsi-initiator-utils и запускаем демон iscsi:

bash
apt-get install iscsi-initiator-utils
systemctl enable --now iscsi
systemctl status iscsi

При запуске мы получаем совершенно справедливое сообщение, что не сконфигурирована ни одна из целей. Запускаем процесс обзора для поиска целей на хосте vm01 c IP-адресом 192.168.0.100:

bash
iscsiadm -m discovery -t sendtargets -p 192.168.0.100:3260

В итоге будут созданы две поддиректории с информацией о цели и хосте:

bash
ls /var/lib/iscsi/nodes/
# share.server:disk1
ls /var/lib/iscsi/send_targets/
# 192.168.0.100,3260

Просмотреть информацию можно командой:

bash
iscsiadm -m node -T share.server:disk1 -p 192.168.0.100:3260
# node.name = share.server:disk1
# node.tpgt = 1
#   ...

Теперь, используя содержимое /var/lib/iscsi/nodes/ и /var/lib/iscsi/send_targets/, демон iscsi при каждом перезапуске будет подключать наши ранее обнаруженные цели.

Также процессом подключения/отключения можно управлять при помощи утилиты iscsiadm:

bash
iscsiadm -m node -T share.server:disk1 -p 192.168.0.100:3260 -l
# Login session [iface: default, target: share.server:disk1, portal:  192.168.0.100,3260]

Теперь команда fdisk покажет наш раздел /dev/sda, экспортированный с vm01:

bash
fdisk -l
# Disk /dev/xvda: 17.1 GB, 17179869184 bytes
# 255 heads, 63 sectors/track, 2088 cylinders
# Units = cylinders of 16065 * 512 = 8225280 bytes
# ...
# Disk /dev/sda: 1011 MB, 1011677184 bytes
# 32 heads, 61 sectors/track, 1012 cylinders
# Units = cylinders of 1952 * 512 = 999424 bytes
# Disk /dev/sda doesn't contain a valid partition table

После команды

bash
iscsiadm -m node -T share.server:disk1 -p 192.168.0.100:3260 -u
# Logout session [sid: 2, target: share.server:disk1, portal: 192.168.0.100,3260]

в выводе fdisk мы увидим только /dev/xvda. Однако, после рестарта демона iscsi, цель снова появиться в списке устройств. Для удаления всей информации о цели воспользуйтесь командой:

bash
iscsiadm -m node -T share.server:disk1 -p 192.168.0.100:3260 -o delete
ls /var/lib/iscsi/nodes/

Если у вас несколько целей, то вы не можете заранее знать, под каким именем после следующей перезагрузки/рестарта сервиса будет доступна конкретная цель. Для того, чтобы каждая цель всегда была доступна под одним и тем же именем устройства, вы можете написать соответствующее правило udev или воспользоваться монтированием по метке и UUID файловой системы. При монтировании файловых систем не забывайте использовать опцию netdev.

Конечно! Ниже представлены практические задания по темам DNS и SSH в контексте GNU/Linux. Задания ориентированы на реальные сценарии администрирования и включают работу с конфигурационными файлами, утилитами командной строки и безопасностью.

Практические задания по DNS и SSH в GNU/Linux ​

Часть 1: Практика по DNS ​

Цель: Научиться настраивать и диагностировать разрешение имён в Linux, понимать работу резолвера, NSS и DNS-запросов.

Задание 1.1: Анализ текущей конфигурации DNS ​

  1. Выведите содержимое файла /etc/resolv.conf:
    bash
    cat /etc/resolv.conf
  2. Определите, какие DNS-серверы используются системой.
  3. Проверьте, является ли файл симлинком:
    bash
    ls -la /etc/resolv.conf
  4. Если используется systemd-resolved, выведите статус DNS:
    bash
    systemd-resolve --status
    или (в новых версиях):
    bash
    resolvectl status

❓ Вопрос: Какой DNS-сервер используется по умолчанию? Откуда он берётся (DHCP, статическая настройка, NetworkManager)?

Задание 1.2: Работа с nslookup, dig и host ​

  1. Установите dnsutils (если не установлен):
    bash
    sudo apt install dnsutils    # Debian/Ubuntu
sudo dnf install bind-utils  # Fedora/CentOS
  2. Выполните запрос к домену google.com с помощью:
    bash
    nslookup google.com
dig google.com
host google.com
  3. Найдите A-запись и AAAA-запись для yandex.ru.
  4. Определите MX-записи для gmail.com:
    bash
    dig gmail.com MX

❓ Вопрос: Какой из инструментов предоставляет наиболее подробную информацию? Что означает поле ANSWER SECTION в выводе dig?

Задание 1.3: Локальное разрешение имён через /etc/hosts ​

  1. Добавьте в файл /etc/hosts запись:
    bash
    192.168.1.100   myserver.local
  2. Проверьте, как система разрешает имя:
    bash
    ping myserver.local -c 3
getent hosts myserver.local
  3. Удалите строку после проверки.

❓ Вопрос: Почему getent hosts — более правильный способ проверки, чем ping?

Задание 1.4: Настройка nsswitch.conf ​

  1. Откройте файл /etc/nsswitch.conf:
    bash
    cat /etc/nsswitch.conf | grep hosts
  2. Убедитесь, что строка выглядит так:
    conf
    hosts: files dns myhostname
  3. Измените порядок: поставьте dns перед files:
    conf
    hosts: dns files myhostname
  4. Проверьте, как это повлияло (добавьте конфликтующую запись в /etc/hosts и проверьте ping).
  5. Верните обратно.

❓ Вопрос: Что произойдёт, если files будет после dns? Когда это может быть полезно?

Задание 1.5: Настройка локального DNS-кэша (systemd-resolved) ​

  1. Включите и запустите systemd-resolved:
    bash
    sudo systemctl enable systemd-resolved
sudo systemctl start systemd-resolved
  2. Убедитесь, что /etc/resolv.conf указывает на 127.0.0.53:
    bash
    cat /etc/resolv.conf
  3. Настройте использование DNS-серверов, например, Cloudflare: Отредактируйте /etc/systemd/resolved.conf:
    ini
    [Resolve]
DNS=1.1.1.1 8.8.8.8
FallbackDNS=9.9.9.9
Domains=~.
  4. Перезапустите службу:
    bash
    sudo systemctl restart systemd-resolved
  5. Проверьте работу:
    bash
    resolvectl query google.com

❓ Вопрос: Как systemd-resolved помогает ускорить разрешение имён?

Часть 2: Практика по SSH и туннелированию ​

Цель: Освоить безопасное подключение по SSH, аутентификацию по ключам и настройку SSH-туннелей.

Задание 2.1: Установка и настройка SSH-сервера ​

  1. Установите OpenSSH-сервер:
    bash
    sudo apt install openssh-server    # Debian/Ubuntu
sudo dnf install openssh-server    # Fedora
  2. Запустите и включите службу:
    bash
    sudo systemctl enable ssh
sudo systemctl start ssh
  3. Проверьте статус:
    bash
    sudo systemctl status ssh
  4. Убедитесь, что сервер слушает порт 22:
    bash
    ss -tuln | grep :22

❓ Вопрос: Какой процесс отвечает за SSH? Как проверить, открыт ли порт извне?

Задание 2.2: Подключение по SSH и аутентификация по ключу ​

  1. Сгенерируйте SSH-ключ на клиенте:
    bash
    ssh-keygen -t ed25519 -C "student@lab"
  2. Скопируйте публичный ключ на удалённый сервер:
    bash
    ssh-copy-id user@remote_host_ip
  3. Подключитесь без пароля:
    bash
    ssh user@remote_host_ip
  4. Убедитесь, что вход происходит без запроса пароля.

❓ Вопрос: Где хранится публичный ключ на сервере? Почему приватный ключ нельзя передавать?

Задание 2.3: Локальное проброс портов (Local Port Forwarding) ​

Сценарий: На удалённом сервере запущен веб-сервер на порту 8080. Вы хотите получить к нему доступ через localhost:9000.

  1. Установите nginx на сервер и настройте его слушать 8080:
    bash
    sudo apt install nginx
sudo systemctl start nginx
# Настройте nginx на порт 8080 (в конфиге /etc/nginx/sites-available/default)
  2. Создайте SSH-туннель:
    bash
    ssh -L 9000:localhost:8080 user@remote_host_ip
  3. Откройте в браузере: http://localhost:9000
  4. Убедитесь, что видите страницу сервера.

❓ Вопрос: Что означает localhost:8080 в контексте удалённого сервера? Что будет, если указать 127.0.0.1 вместо localhost?

Задание 2.4: Удалённое проброс портов (Remote Port Forwarding) ​

Сценарий: На локальной машине запущен веб-сервер (например, Python http.server), и вы хотите, чтобы коллега на удалённом сервере мог к нему подключиться.

  1. Запустите локальный сервер:
    bash
    python3 -m http.server 8000
  2. Создайте удалённый туннель:
    bash
    ssh -R 8888:localhost:8000 user@remote_host_ip
  3. На удалённом сервере выполните:
    bash
    curl http://localhost:8888
  4. Убедитесь, что получен ответ от вашего локального сервера.

⚠️ Если не работает: проверьте GatewayPorts yes в /etc/ssh/sshd_config и перезапустите SSH.

❓ Вопрос: Почему по умолчанию удалённые туннели доступны только с localhost на сервере?

Задание 2.5: Динамическое проброс портов (SOCKS-прокси) ​

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

  1. Создайте SOCKS-прокси:
    bash
    ssh -D 1080 user@remote_host_ip
  2. Настройте браузер (Firefox / Chrome) на использование SOCKS5-прокси:
    • Адрес: 127.0.0.1
    • Порт: 1080
  3. Перейдите на https://iplocation.net — убедитесь, что IP-адрес совпадает с IP удалённого сервера.
  4. Отключите прокси и проверьте снова.

❓ Вопрос: В чём разница между -L, -R и -D? Когда уместно использовать SOCKS-прокси?

Задание 2.6 (дополнительное): Автоматизация SSH через ~/.ssh/config ​

  1. Создайте или отредактируйте файл ~/.ssh/config:
    conf
    Host myserver
    HostName 192.168.1.100
    User admin
    Port 22
    IdentityFile ~/.ssh/id_ed25519_lab
    LocalForward 9000 localhost:8080
  2. Подключитесь сокращённой командой:
    bash
    ssh myserver
  3. Убедитесь, что туннель поднимается автоматически.

❓ Вопрос: Какие ещё полезные опции можно задать в ~/.ssh/config? (Например, ServerAliveInterval, Compression)

Контрольные вопросы (для самопроверки) ​

  1. Как работает NSS при разрешении имён?
  2. Чем отличается dig от nslookup?
  3. Зачем нужен systemd-resolved?
  4. Как работает SSH-туннель? Почему он безопасен?
  5. В чём разница между локальным и удалённым пробросом портов?
  6. Почему SSH-ключи безопаснее паролей?

✅ Выполните все задания и ответьте на вопросы.
После завершения вы сможете уверенно настраивать DNS и использовать SSH для безопасного доступа и туннелирования в GNU/Linux.

Готово! Этот блок можно использовать как лабораторную работу или самостоятельную практику для студентов/администраторов.

Контакты: bystrovno@basealt.ru

© 2025 – настоящее время, Никита Б. Разработано на VitePress.