Изменения в «LecturesCMC/LinuxNetwork2013/HomeWork»

Импорт виртуальных машин

• Установить VirtualBox.

• Удалить старые виртуальные машины «nano» и «naniclient» (если были)

• Скачать архив с образами виртуальных машин, распаковать и импортировать их. Импорт из командной строки: VBoxManage import Nano.ovf или в GUI: «Файл → Импорт конфигураций → Nano.ovf»; то же самое для «клиентской» машины NanoClient.ovf.

ЗУН
Знать принципы организации стека протоколов TCP/IP и базовую терминологию

Ethernet: свойства носителя

• Интерпретировать выдачу такой команды (enp0s3 — это название устройства, подключённого к среде ПД):

  • [root@uneex ~]# ethtool enp0s3

Последовательный порт

• Интерпретировать результаты работы команды

  • [root@uneex ~]# stty -a < /dev/ttyS0

• Посмотреть в документации и обратить внимание на значение полей baud, cstopb, parenb, parodd и csN:

  • [root@uneex ~]# man stty | egrep -C1 'baud|cstopb|parenb|parodd|csN'

• (Часть задания выполняется на хост-системе, в журнал не входит). Посмотреть на скорость передачи можно так: настроить ВМ таким образом, чтобы COM1 перенаправлялся в создаваемый при старте сокет («настройки ВМ → COM-порты» «Порт1 → хост-канал» + «создать канал» + какое-нибудь имя, например, nano)

  • [root@uneex ~]# stty 300 < /dev/ttyS0
    [root@uneex ~]# cal > /dev/ttyS0

    И на хост-системе поглядеть в этот сокет:

    $ socat UNIX-CONNECT:nano1 -

ЗУН
Знать принципы работы в командной строке shell; иметь представление о кодировании и передаче информации; владеть первичными навыками работы в командной строке

Ethernet

• С помощью ip link узнать имена сетевых интерфейсов

• Сколько их?

• С помощью ethtool посмотреть параметры Ethernet-интерфейсов. обратить внимание на различие скорости

  [root@uneex ~]# ethtool enp0s3  | grep 100
  [root@uneex ~]# ethtool enp0s8  | grep 100

• С помощью ifdown enp0s8 «опустить» интерфейс. Что изменилось?

  [root@uneex ~]# ip l show dev enp0s8
  [root@uneex ~]# ifdown enp0s8
  [root@uneex ~]# ip l show dev enp0s8

  • ifdown — это сценарий. Какой командой «опускается» интерфейс?

• заглянуть внутрь трафика:

  • (NB: вы можете использовать несколько консолей для работы, они переключаются по ALT-F1, ALT-F2 и т. д; также можно несколько раз подключиться по ssh)

  • # socat TUN:192.168.255.1/24,up,tun-type=tap - | hexdump -C

    • Посмотреть с другой консоли на созданный виртуальный сетевой интерфейс:

      [root@uneex ~]# ip l show dev tap0

  • # ping 192.168.255.2 (также с другой консоли)

    • (трудно отчитаться) Наблюсти в выдаче MAC-адрес интерфейса tap0, широковещательный адрес ff ff ff ff ff ff и IP-адрес

    • Это какого уровня трафик?
ЗУН

Знать основную терминологию протоколов канального уровня, принципы работы протокола ethernet, иметь представление о формате фрейма, особенностям WiFi; иметь базовый навык в использовании команд ip link и ethtool; уметь находить сетевые интерфейсы Linux и изучать их параметры.

IP: адресация и маршрутизация

• Какие адреса выдаёт команда ip a?

  • Что умеет ip addr (краткий список: ip a help)

• Как устроена таблица маршрутизации (ip r)?

  • Каков адрес маршрутизатора по умолчанию?

  • Какой интерфейс ведёт в интернет?

• Что можно узнать из команды whois 158.250.10.1?

  • в частности — номер автономной системы (ASномер). Что выдаёт команда whois этот_номер?

ARP

• Сколько машин показывает ip n?

  • [root@uneex ~]# ip n
    [root@uneex ~]# ip n | wc -l

• Добиться, чтобы выдача ip n менялась после ping чего-нибудь

• Сеанс работы протокола ARP

  • убедиться, что в ip n на клиенте пропал адрес сервера

  • Выполнить

    • [root@uneex ~]# tcpdump -v -n -i enp0s8 arp

      [root@uneexclient ~]# ping -c1 srv

  • пронаблюдать сеанс заполнения ARP-таблицы в выдаче tcpdump

ICMP

• Сеанс работы traceroute

  • запустить

    • [root@uneex ~]# tcpdump -v -i enp0s3 host www.ru or icmp

      [root@uneexclient ~]# traceroute -q1 -w1 www.ru

  • пронаблюдать работу traceroute. Обратить внимание на увеличивающиеся значения ttl

Настройка сети

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

  • ip r, ip a

  • ls /etc/net, ls /etc/net/ifaces

  • find /etc/net/ifaces/[el]* -type f -print (эта команда рекурсивно просматривает соответствующие каталоги и находит в них файлы)

  • find /etc/net/ifaces/[el]* -type f -print -exec cat {} \; (эта командавыводит не только имена файлов, но и их содержимое)

  • (вариант предыдущей команды, в которой find только выдаёт имена файлов, а выводом занимается sh): find /etc/net/ifaces/[el]* -type f -print | while read f; do echo "     ====== $f"; cat $f; done

  • каких привычных настроек сети не задано явно в текущей конфигурации etcnet и почему?

• Настройка DHCP:
  • Настройки сервера:

    • [root@uneex ~]# cat /etc/dhcp/dhcpd.conf

  • Посмотреть сеанс настройки клиента по DHCP:

    • [root@uneex ~]# tcpdump -v -n -i enp0s8 port bootps or port bootpc

  • Перезапустить сеть на клиенте, чтобы этот сеанс произошёл:

    [root@uneexclient ~]# service network restart

• Настройки сети на клиенте
  • См. настройки на сервере.

  • ip rule (обратить внимание на пока пустую нестандартную таблицу "back")

  • cat /etc/iproute2/rt_tables

  • В файле /etc/net/ifaces/enp0s3/ipv4route расскомментировать по одной строчке (остальные должны быть закомментированы), посмотреть, что изменится после service network restart

    • В частности, выполнить команды ip r и ip route get 217.76.32.61

    • Обратите внимание на то, что записей вида default в таблице может быть несколько; если не заданы приоритеты, побеждает первая (она же последняя добавленная)

Целевая маршрутизация

• Настройка и работа Policy routing

  • На клиенте раскомментировать в enp0s3/ipv4route только строку default via 10.0.2.2 table back (она заполняет таблицу "back"), перезапустить сеть

  • ip route list table back

  • ip r get from 10.30.50.1 iif enp0s8 217.76.32.61

    • что делает эта команда?

    • чем её результат отличается от ip r get 217.76.32.61 и почему?

  • Пронаблюдать процесс целевой маршрутизации:

    • Выяснить ip-адрес клиента в сети 10.30.50.0/24:

      • [root@uneexclient ~]# ip a

    • [root@uneexclient ~]# tcpdump -ni enp0s3 port 80

    • [root@uneex ~]# ip r add 217.76.32.61/32 via ip-адрес-клиента

    • [root@uneex ~]# ip r get 217.76.32.61; ip r get 217.76.32.60

    • [root@uneex ~]# echo -e "QQ\n\n" | netcat 217.76.32.61 80

• Закомментировать обратно все строки в enp0s3/ipv4route на клиенте и на сервере, а то работать будет не так, как надо

TCP

• Посмотреть TCP-трафик

  • На сервере запустит tcpdump:

    [root@uneex ~]# tcpdump -KlSnni enp0s3 tcp and port 80 

    • на клиенте — сходить куда-нибудь по 80-му порту, например:

    [root@uneexclient ~]# date | netcat linux.org.ru 80

  • Наблюсти TCP-сеанс. Обратить внимание на флаги [S] (syn) [P] (payload) и [F] (fin), возникающие в сеансе, а также на использование двух нарастающих seq (туда и обратно)

• Наблюсти тот же сеанс, убрав S и nn из ключей tcpdump

UDP и ICMP

• На сервере посмотреть трафик по 53-му и 123-му портам и протоколу ICMP

  • [root@uneex ~]# tcpdump -Klvnni enp0s3 port domain or port ntp or icmp

• На клиенте:

  • пингануть что-нибудь (например ping -c3 linux.org.ru)

  • обновить время (ntpdate ru.pool.ntp.org)

  • выполнить traceroute (traceroute -N1 -q1 -n linux.org.ru)

  • Наблюсти на сервере
    • DNS-трафик (от ping, ntpdate и т. п.). Где в нём DNS Query ID?

    • ICMP-трафик (для ping — id. для traceroute — увеличивающиеся ttl, UDP и ICMP)

    • NTP-трафик (Transmit Timestamp и Originator Timestamp в ответе)

FTP и его непростой выбор портов

• На сервере запустить tcpdump -i enp0s8

• На клиенте выполнить

  • [root@uneexclient ~]# ftp 10.30.50.1 
    …
    Name (10.30.50.1:root): ftp
    …
    ftp> ls
    …
    ftp> passive
    …
    ftp> ls
    …
    ftp> exit

• Найти:
  • в passive режиме (по умолчанию):

    • в выводе FTP: предложение сервера подключиться для передачи данных к случайному порту (представлен в побайтно-десятичном виде сразу после адреса, например 234.12 — это 234*256+12 = 59916

    • подключение к этому порту (в tcpdump) с клиента на сервер

  • в active режиме (после команды passive)

    • в выводе FTP: предложение клиента подключиться для передачи данных к случайному порту

    • подключение к этому порту (в tcpdump) с сервера на клиент

Запуск сетевых служб

• Посмотреть список зарегистрированных служб:

  # chkconfig --list

  • Обратите внимание на то, что команда chkconfig управляет и запуском служб посредством sysvinit, и метадемоном xinetd

• Остановить службу dhcpd и посмотреть, что изменилось (можно также проверить с клиента, что DHCP недоступен):

  # netlist > full
  # service dhcpd status
  …
  # service dhcpd stop
  …
  # netlist > no_dhcp
  # diff -u full no_dhcp 
  …
  # service dhcpd start
  …

  • Что делает утилита netlist?

• Посмотреть выдачу утилиты rpcinfo без параметров, с ключом -s и с ключом -p. Что эти команды делают?

Метадемон xinetd

• Посмотреть настройки xinetd на сервере:

  # cat /etc/xinetd.conf
  …
  # ls /etc/xinetd.d/
  …
  # cat /etc/xinetd.d/bftpd-tcp 
  …
  # grep disable /etc/xinetd.d/*
  …

  • Обратите внимание, как выключаются зарегистрированные inetd-фильтры

• (пример уже воспроизведён). Воспроизвести пример «Обслуживание прикладного уровня в Linux» из учебника (подключаться с клиентской машины с помощью netcat вместо telnet)

• Посмотреть самодельный xinetd-файл и проверить его работу:

  •   [root@uneex ~]# chkconfig --list calendar

      [root@uneex ~]# cat /etc/xinetd.d/calendar

      [root@uneexclient ~]# netcat srv 26000

DNS

• Посмотреть настройку сети: [root@uneex ~]# cat /etc/net/ifaces/enp0s3/options

• Что лежит в /etc/resolv.conf на сервере и на клиенте?

• Создать DNS-запрос на клиенте и посмотреть, как его разрешает сервер (напоминаю, что подсказка в начале показывает, на какой машине давать команды):

  [root@uneex ~]# tcpdump -i enp0s3 port 53
  …
  [root@uneexclient ~]# dig cmc.msu.ru
  …
  [root@uneex ~]# tcpdump -i enp0s8 port 53
  …
  [root@uneexclient ~]# hostinfo 10.30.50.13
  …
  [root@uneexclient ~]# hostinfo host17
  …

• Заглянуть в настройки BIND на сервере:

  • прямую и обратную зоны: /var/lib/bind/zone/* (в т. ч. для localhost)

  • настройки: /var/lib/bind/etc/options.conf (обратите внимание на поле forwarders) и /var/lib/bind/etc/local.conf

NFS

• посмотреть работу NFS:

  [root@uneex ~]# tcpdump -i enp0s8 not port 53 
  …
  [root@uneexclient ~]# showmount -e srv
  …
  [root@uneexclient ~]# mount srv:/home /mnt
  [root@uneexclient ~]# find /mnt
  …
  [root@uneexclient ~]# umount /mnt

  • Обратите внимание на premission denied. Отчего это?

• Посмотреть DNS-трафик при ls /mnt/net/home с клиента (используются анонсированные через DNS службы)

Zeroconf

• Работа Avahi:

  • # avahi-browse -at

  • Посмотреть анонсирующую настройку:

    [root@uneex ~]# cat /etc/avahi/services/nfs-home.service
    …

• посмотреть трафик работы zeroconf:

  [root@uneexclient ~]# tcpdump -i enp0s8
  …
  [root@uneex ~]# ping uneexclient.local
  …
  [root@uneex ~]# tcpdump -i enp0s8
  …
  [root@uneexclient ~]# ls /mnt/net/Homes
  …

Открытая передача учётных записей в старых протоколах

• Убедиться в небезопасности FTP (login: "user", password: "user"):

  [root@uneex ~]# dsniff -i enp0s8
  …
  [root@uneexclient ~]# ftp srv
  …
  Name (srv:root): user
  …
  Password: user
  …

SSL-сертификаты

• создание самоподписанного сертификата

  • короткая команда: [root@uneex ~]# cert-sh generate lighttpd (это просто небольшой сценарий)

  • посмотреть, какими командами генерируется самоподписанный сертификат:

    [root@uneex ~]# rm -rf tmp/test; mkdir -p tmp/test/{private,certs}
    [root@uneex ~]# SSLDIR=tmp/test sh -x cert-sh generate lighttpd 2>&1 | egrep '^[+] (openssl|cat|ln)'

    должно быть четыре стадии: создание ключа, создание запроса на подпись этим ключом, подпись самим собой и склеивание подписи с ключом

  • перезагрузить http-сервер: [root@uneex ~]# service lighttpd restart

• проверка разных сертификатов:

  • [root@uneexclient ~]# openssl s_client -verify on -connect srv:443 < /dev/null

  • [root@uneexclient ~]# LC_ALL=C lynx https://www.uneex.org

  • [root@uneexclient ~]# LC_ALL=C lynx https://uneex.ru

  • [root@uneexclient ~]# LC_ALL=C lynx https://srv

Netcat

• Поговорить с самим собой с помощью netcat:

  [root@uneex ~]# nc -l 12345 
  …
  [root@uneexclient ~]# nc srv 12345 
  …

  • Для того, чтобы закрыть поток В/В, достаточно нажать "Ctrl+D"

Secure shell

• Зайти с клиента на сервер по ssh, почитать отладочную диагностику и обнаружить там имена файлов с ключами:

  • [root@uneexclient ~]# ssh -v root@srv

• Сгенерировать ключ (защищённый кодовой фразой "123456"):

  • [root@uneexclient ~]# rm -rf /root/.ssh/id_dsa && ssh-keygen -P123456 -t dsa -f /root/.ssh/id_dsa

    • Повторять эту команду до тех пор, пока ASCII-арт отпечатка не покажется красивым

    • удалить файл .ssh/known_hosts и снова зайти на сервер. Увидеть диалогThe authenticity of host 'srv (10.30.50.1)' can't be established и в нём отпечаток (обращаю внимание, что отвечать надо yes, а не y). В отладочной информации увидеть, что предложенный ключ был отвергнут

• Скопировать открытый ключ на сервер (надо будет ввести кодовую фразу):

  [root@uneexclient ~]# ssh-copy-id srv

  • ssh-copy-id — это простой сценарий, запустить sh -x ssh-copy-id srv и посмотреть, какими командами что копируется

• Ещё раз зайти на сервер (теперь вместо пароля надо будет вводить кодовую фразу)

• Запустить ssh-агент (обратите внимание, что команда ssh-agent генерирует все остальные команды, их просто надо скопировать, и числа там будут другие)

  [root@uneexclient ~]# ssh-agent
  SSH_AUTH_SOCK=/root/tmp/ssh-XIglJWV12040/agent.12040; export SSH_AUTH_SOCK;
  SSH_AGENT_PID=12041; export SSH_AGENT_PID;
  [root@uneexclient ~]# SSH_AUTH_SOCK=/root/tmp/ssh-XIglJWV12040/agent.12040; export SSH_AUTH_SOCK;
  [root@uneexclient ~]# SSH_AGENT_PID=12041; export SSH_AGENT_PID;

  • Вместо всего этого можно было выполнять такую команду:

  [root@uneexclient ~]# eval `ssh-agent`  

• Добавить в него ключ, посмотреть на ключ и зайти наконец-то без пароля!

  [root@uneexclient ~]# ssh-add -l
  The agent has no identities.
  [root@uneexclient ~]# ssh-add   
  Enter passphrase for /root/.ssh/id_dsa: 
  Identity added: /root/.ssh/id_dsa (/root/.ssh/id_dsa)
  [root@uneexclient ~]# ssh-add -l
  1024 5c:5f:59:eb:97:ec:e0:fc:f7:18:1f:10:89:dd:f4:90 /root/.ssh/id_dsa (DSA)
  [root@uneexclient ~]# ssh srv
  Last login: Fri Nov 29 14:16:39 2013 from host13.class.altlinux.org

• Пробросить подключение с клиента на uneex.ru:80 на порт сервера 8001:

  [root@uneexclient ~]# ssh srv -R8001:www.ru:80  
  Last login: Fri Nov 29 14:25:26 2013 from host13.class.altlinux.org
  [root@uneex ~]# netlist | grep 8001
  root     14358 sshd     8 tcp       127.0.0.1:8001          0.0.0.0:0     LISTEN
  [root@uneex ~]# links http://localhost:8001
  …

  • С помощью tcpdump убедиться, что трафик идёт так: сервер(localhost):8001 → клиент(ssh-тоннель):22 → www.ru:80

GnuPG

• Импортировать открытый GPG-ключ и проверить его отпечаток:

   [root@uneex ~]# rm -rf $HOME/.gnupg
   [root@uneex ~]# gpg --list-keys
   [root@uneex ~]# gpg --recv-keys 7C10D900
   [root@uneex ~]# gpg --fingerprint 
   /root/.gnupg/pubring.gpg
   ------------------------
   pub   1024D/7C10D900 2003-10-17
         Key fingerprint = D01B B410 C69D AE98 8EB0  16F0 E1F0 3D6E 7C10 D900

• Проверить подпись этого файла:

  [root@uneex ~]# curl 'https://uneex.ru/LecturesCMC/LinuxNetwork2013/09-SecurityAndTools?action=AttachFile&do=get&target=signed.txt' > signed.txt
  [root@uneex ~]# gpg --verify signed.txt

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

• Сгенерировать учёбный ключ (ВНИМАНИЕ!. Учётные данные в этом ключе менять не надо, они исползуются для формирования отчёта. Вы можете нагенерировать ещё ключей, но этот надо оставить).

  [root@uneex ~]# echo "
       Key-Type: DSA
       Key-Length: 1024
       Name-Real: Joe Tester
       Name-Comment: with stupid passphrase
       Name-Email: joe@foo.bar
       Expire-Date: 0
       %commit
  " | gpg --batch --gen-key -

  • При появлении надписи (если вдруг) "Not enough random bytes available." придётся зайти в соседнюю консоль и нажимать на все подряд клавиши клавиатуры. В VirtualBox с энтропией плоховато.

• Подписать ключ 7C10D900 и снова проверить подпись

  [root@uneex ~]# gpg --sign-key 7C10D900
  …
  [root@uneex ~]# gpg --verify signed.txt
  …

Межсетевые экраны

• (задание по МЭ в отчёт можно не включать) Следующая команда выдаёт ошибку. Почему?

  [root@uneex ~]# iptables -A POSTROUTING -d 217.76.32.61 -j REJECT
  iptables: No chain/target/match by that name.

• (задание по МЭ в отчёт можно не включать) В следующих примерах для проверки связности запускать команду

  # echo -e "GET / HTTP/1.0\nHost: linux.org.ru\n" | netcat linux.org.ru 80

  с клиента и с сервера и просматривать сами правила с помощью

  [root@uneex ~]# iptables-save 

  • Добавить фильтрующее правило:

    [root@uneex ~]# iptables -A FORWARD -d 217.76.32.61 -j REJECT

  • Удалить фильтрующее правило:

    [root@uneex ~]# iptables -D FORWARD -d 217.76.32.61 -j REJECT

  • Добавить фильтрующее правило:

    [root@uneex ~]# iptables -A OUTPUT -d 217.76.32.61 -j REJECT

  • Удалить фильтрующее правило
  • Посмотреть на соединения, обслуживаемые conntrack:

    [root@uneex ~]# cat /proc/net/nf_conntrack        

TCP/IP за 40 минут

Введение

Первая вещь -- пощупать руками передачу данных между компьютерами.

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

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

Предполагается, что у вас будет установлен VirtualBox. Он сравнительно прост в настройке и использовании, и прост для целей моделирования простейших топологий. Офсайт virtualbox.org

Вы могли заметить, что на сайте uneex.ru уже лежит образ размером 70 мегабайт, этот образ надо распаковть, проимпортировать в VirtualBox и вы получите тоже самое, на чем лектор будет делать свои примеры.

Этим этот курс будет отличаться от курсов 2004 и 2008 года, а также курса 2010 года для NetCracker. Для NetCracker было все наоборот -- люди по rdesktop смотрели на действия лектора, производимые на его машине.

Зовут лектора Георгий, лектор является сотрудником лаборатории программного оборудования. Кажется, раньше так назывались стойки, куда совали перфокарты. Занимается это лаборатория в значительной части техподдержкой факультета. Спецкурс кафедры АСВК, математический.

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

Есть много компьютеров в разных местах.

Задача -- надо передавать между ними информацию.

С чего начать?

• Имена компьютеров? нет
• Протокол? нет
• Канал связи? Да. Надо подумать, будем ли мы возить жесткие диски на самосвалах между деревнями. Между прочим, есть RFC на tcp/ip по голубиной почте.

1. Среда передачи данных

Какие подзадачи видятся, когда мы говорим об организации среды передачи данных? Мы пока даже не думаем о компьютерах, только о том, как передавать.

Логичное предложение -- оцифровать.

В этом случае возникают две задачи.

1. Описать среду передачи данных -- провода,скрученные провода, воздух, почтовых голубей(чтоб не дохли, как московские). Описать параметры носителя. Допустим изобрели провода, по которым можно передавать.
2. Что является данными внутри проводов? Как кодировать данные? Кодировать можно по разному. Нолик -- отсутствие напряжения, единица -- наличие. Но что значит много ноликов за секунду? Это много ноликов или мышка провод перегрызла? Сколько раз в секунду замерять напряжение? 300, 1200, 4800, 9600 раз в секунду?

На этом остановится нельзя. Теперь надо воткнуть провод в компьютер.

2. Подключение к среде передачи данных

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

Означает ли целая секунда нулей на проводе 19200 нулей или означает, что никто ничего не передает?

Как определять

• что это вообще данные
• кому они предназанчены, если компьютеров много

Вторая подзадача понятна -- дисциплина использования среды. А первую лектор не помнит. Назовем это

1. процесс передачи
2. дисциплина использования

Недостаточно описать как выглядят данные, надо описать и процесс передачи. Что из наблюдаемого в среде передачи является данными, что нет. Как выясняется, что передача данных закончена. Описать дополнительные условия и соглашения, которыми будут пользоваться компьютеры при использовании среды. Вот здесь возникает понятие протокола. По проводам бегают нолики и единички, но это не только полезные данные. но и обозначение того, как идет процесс передачи. Например, чтобы отличить шум от данных мы договримся, что данные всегда начинаются конкретной последовательностью. И устройства приема вообще не будет реагировать на наблюдаемую в проводах ерунду, пока не увидит маркер начала передачи. Этот маркер не превращается в пользовательские данные. Появляются понятия пейлоада и оверхеда. Маркеры, адреса, контрольные суммы -- это системные данные, оверхед. Пейлоад -- это пользовательские данные.

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

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

Здесь помимо математического описания как кодировать данные и в какие метаданные они заворачиваются мы должны описать повдения абонентов в разных ситуациях. То есть протокол это не только формат но ещё и опсиание поведения абонентов.

Вопрос с подковыркой. Решили ли мы задачу передачи данных? Казалось бы решили -- идентификация, начало передачи, окончание, вплоть до сообщения об ошибках. Все компьютеры теперь знают когда можно передавтаь данные, а когда нельзя. Данные можно передавать, правила как друг другу не мешать существуют. Почему тем не менее мы говорим, что дальше будут возникать какие-то задачи. Какой главный момент не учтен совсем.

Целостность? Это можно решить на уровне интерпретирующих инструментах и часто так и делается.

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

3. Объединение различных СПД

Этап три -- различные среды передачи данных объединить в единую сеть. Надо научиться передавать из одной в другую, минуя самосвалы, голубей и вайфай.

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

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

1. идентификация
2. обеспечение возможности доставки данных от отправителя к получателю. В рамках одной СПД это подразумевается по умолчанию. Но в случае нескольких СПД это неочевидно. На сайте написано "планирование доставки данных", но это эвфемизм слова маршруты. Задача довольно сложная. Тем не менее, если мы хотим чтобы данные передавались, мы должны описать правило, согласно которому данные от абонента А могут дойти до Б. Если у нас есть полная карта сети где-то, то это где-то может посмотреть и решить как передавать. Проблема в том, чтобы хранить всю карту. И второй недостаток -- интернет большой, и у заплонированного маршрута какое-нибудь звено может отвалиться. Другой вариант -- не знать как именно дойдут данные до адресата, но знать, кому их следующему переслать. Динамическое построение маршрута. Правда, так данные тоже могут не дойти, ну что ж.

4. Работа с потоками данных

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

• а все что посередине нас не волнует. Нас волнует только то, чтобы складываемое и забираемое было одинаковым. Назовем это проблемой доставки, имея в виду две вещи:
  1. одинаковость попавшего и вылезшего, чтобы передающая и принимающая сторона не заботилась, не попортились ли данные по дороге. Целостность +. Есть ещё всякие интересные моменты, например,
  2. проверка наличия абонента, контроль ошибок в потоке данных. Короче говоря, организация потока данных.

Допустим мы передаем различные данные одновременно. Грузим картинку и шлем почту. Фактически, три разных потока данных, которые бы очень хотелось не смешивать по дороге. Тем самым вводится понятие поток данных как таковой. Более тонкие вещи связанные с потоком данных -- не факт, что принимающая сторона сможет принимать данные с той же скоростью, с которой их отправляют. С одной стороны сервер с гигабитом, а на другом пользователем с адслем. Если ему фигачится фильм со скоростью 3 мегабита, а у него 64 килобита, то куда все девается? Накапливается посередине интернета? Нет. Но могут постоянно срабатывать механизмы контроля целостности. Но лучше бы чтобы у потока данных было известно, с какой скоростью по нему можно передавать. Еще одна проблема -- джиттер, неравномерность скорости передачи. Хочется по мере возможности сделать гарантированную пропускную способность, хотя просто так предоставить такие гарантии в интеренет нельзя. Все это так или иначе относится к управлению потоками.

5. Интерпретация данных

Ну и наконец последний пункт. Что мы передаем и зачем? Здесь до сих пор не написано, что это были за данные? А мы и не знаем, нас на тех уровнях это не интересовало. Далее идет интерпретация данных, ради которой все и затевалось. Теперь можем говорить -- все ребята, мы сделали все что могли. Какие бывают проблемы интерпретации? Это проблемы проотоклов.

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

Совершенно очевидно, что у нас две проблемы, большая и не очень. Не очень большая -- доставить данные до приложения, которое их будет интерпретировать. Мы не сможем сделать железяку, которая будет реализовывать все протоколы. Можем купить железяку, которая будет реализоваавть достаточное количество протоколов первых четырех уровней.

Связывание и интерпретация.

Связывание -- до прикладных протоколов.

Интерпретация -- пережёвывание данных приложениями. Если хватит времени, поговорим про аспекты интерпретации, которые есть везде, например DNS -- протокол прикладного уровня, но без него никуда.

Вот вам уже совсем готовая схема, как может функционировать компьютерная сеть.

Готовая схема

Давайте посмотрим на уже совсем готовую схему, и те, кто уже слушал предыдущий курс -- компьютерные сети, давайте приложим этот механим к той самой модели ISO/OSI. Уровни:

1. аппаратный
2. канальный
3. сетевой
4. транспортный
5. сеансовый
6. уровень представления данных
7. прикладной

Как это все расклдывается в нарисованную схему. Первые три уровня матчатся напрямую. Дальше сложнее.

С точки зрения ISO/OSI транспортный уровень обеспечивает надежную доставку пакетов и более ничего. Управление потоками данных это уже пятый, сеансовый уровень. Они говорят, что в завсисмости от приложений потоки данных могут быть сильно разными, и они вообще то правы.

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

Вспоним модель TCP/IP, у неё следующие уровни:

1. аппаратный;
2. интерфейсный; Cisco "считает", что уровня четыре, объединяя аппаратный и интерфейсный. Лектор и "все остальные" "считают", что уровней пять.
3. сетевой;
4. транспортный;
5. прикладной.

Заметим, что то, что мы изобрели сейчас ничем не отличается от того, что изобрели не мы. Потому что это логично. Хотя существуют случаи, когда эта схема неудобна. Как и за всякое ограничение, за нее надо платить.

Типичный пример когда нам не хватает инструментария TCP/IP -- это пресловутое шифрование. Если у вас на сайте включен ssl, то если у вас один ip-адрес, то у вас может быть только один сертификат. А это очень неудобно, потому что сайтов может быть много. Потому что шифрование происходит на неудоном уровне. В ssl третьей версии сделали костыль на эту тему. Осталось только распространить этот костыль по всему миру и все будут счастливы.

Если кто не понял, за эти 40 минут лектор рассказал TCP/IP как оно есть.

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

Две вещи, которые несомненно нужно рассказать, когда мы говорим про сети.

Независимость уровней

Первое -- уровни сетевые про которые мы говрим не зависят друг от друга практически. Когда мы решаем задачу на уровне N, мы не заморачиваемся тем, как она решена на уровне N-1. Задачи предыдущих уровней просто считаются решенными. Когда мы присваиваем компьютеру айпи-адрес, нам все равно, какой у него мак-адрес.

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

Посмотрим например на Ethernet. Их много разных -- 10-мегабитный, 100-мегабитный. Хотя вообще по витой паре можно и не только ethernet гонять. Может случится так, что на одной стороне сетевая карта поддерживает и 100 мбит и 1 гбит, а на другом только 100 мбит. И внезапно эти карты договвариваются общаться на скорости 100 мбит. Хотя это явное пропускание информации со второго уровня на первый, потому что чтобы договориться на какой скорости общаться, они должны сначала как-то общаться. В случае проводов и устройств, кторые подключают эти провода к компьютеру, смешение уровней происходит очень часто, именно поэтому наверное компания циско считает их одним.

Инкапсуляция пакетов верхнего уровня пакетами нижнего уровня

Второе -- инкапсуляция пакетов. Если у нас есть СПД, которой пользуются сразу несколько абонентов, возникает вопрос, как сделать так, чтобы они могли ей пользоваться "одновременно". Если СПД это полный граф из проводов, то все отлично. Но это неоправданно большое количество проводов. Значит у СПД есть максимальная пропускная способность, и не все абоненты одновременно могут ей воспользоваться. Далее есть два решения.

• Коммутация каналов, как при телефонном звонке. Звоните из Нагатино в Долгопрудный. Ещё несколько человек могут сделать такэже, пока не кончатся каналы на какой-то из задействованных телефонных станций.

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

• Второе решение -- резко ограничиваем акт передачи данных маленьким кусочком такого размера, что его можно затолкать в СПД и он дойдет до адресата. Такой кусочек называется фрейм. Абонент, в тот момент когда ему можно посылает не все данные, а один пакет. В следующий момент когда ему можно, посылает еще пакет. И так пока не закончатся данные. Так происходит фрагментация данных, а на

стороне получателя складывание этих кусочков в единое целое.

Понятие пакет есть на всех уровнях, кроме аппаратного, где непонятно что называть пакетом.

Какие данные надо навесить на пакет кроме пользовательских?

1. отправитель
2. получатель
3. номер в потоке если есть потоке
4. итд

Здесть возникает одно забавное явление, которое в случае с коммутацией пакетов хорошо объяснимо, но плохо понимаемо народом. Инкапсуляция.

Смотрите как все устроено. На самом верхнем уровне есть файл. Файл невозможно целиком затолкать в дырочку, поэтому он режется на части и по частям засовывается на транспортный уровень.

На транспортном уровне мы смотрим на его размер. Если он слишком большой чтобы пролезть на сетевом уровне, мы снова его режем на куски. Здесь на части уже режутся пользовательские данные + метаинформация. Нарезание на куски называется фрагментация. Заворачивание в пакеты более низкого уровня называется инкапсуляцией.

Так все путешествует до уровня проводов.

По проводам до соседней машины.

Соседняя машина вынимает данные из проводов, отрезает маркерв начала и конца, собирает фрейм -- пакет второго уровня. Дальше она ничего с ним не может делать, собирает пакет сетевого уровня и смотрит, нам этот пакет или не нам. Тут выясняется что мы маршрутизатор, и нам надо только передать этот пакет дальше. Мы снова режем его на куски, возможно другого формата, если надо в другую СПД, там оно снова превратилось в провода или в воздух, и так далее, пока пакет не дойдет до адресата. На адресате собирается пакет сетевого уровня, и выясняется что он нам. Из пакетов сетевого уровня собирается пакет уровня транспортного. Мы проверям что пакеты друг другу подходят, следуют друг ха другу, то мы транспортные пакеты собираем вместе и приложение получает исходный файл.

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

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

Все остальное про эти ваши сетевые протоколы -- это подробности вот этого.

Заключение

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

Кодирование, компорт, комстрока

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

На первом этапе, когда мы придумываем сеть, мы должны решить как выглядит среда передачи данных. Задача складывается из двух подзадач. Первое -- выдумать носитель данных. С помощью чего данные будут передаваться, что там вообще есть. Мы приводили пример, как можно специфировать ноли и единицу. Вариантов таких договренностей может быть много. Таквот, носитель данных может быть какой угодно, лишь бы он умел это делать и подключаться к компьютеру. Почтовый голубь вполне хорошая спд, только могут возникнуть проблемыс подключением потока голубей к компьютеру. Но такия экзотические спд мы рассматривать не будем. Очевидно, что параметры носителя типа толщины кабеля или количество витков на метр это параметры физического уровня. понятно, что ту же витую пару можно использовать разными способами. Несмотря на то, что это ниэжний уровень, а способ кодирования сигнала это более высокий уровень -- одно без другого не существует. И когда мы говорим, что выбираем способ кодирования, мы всегда должны помнить, какой носитель мы используем.

Есть напряжение -- нолик, нет напряжения -- единичка. Такой простейший способ кодирования. Сразу видим две проблемы, которые необходимо решить прежде чем радостно связывать два компьютера таким проводом. Должны понять -- данные это или нет. Перегрызла провод мышь, там всегда нули -- значит ли это, что нам всегда передают нули?

Сколько раз в секунду замерять напряжение?

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

Кодирование и синхронизация

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

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

Что касается синхронизации можем предусмотреть еще один провод и по нему просто слать тики, каждый раз когда пришел тик замеряем на втором проводе напряжение. Если вы внимательно почитаете спецификацию последовательного канала, который 25-проводной, то там как-то так и напсиано. С другой стороны, конечно, тянуть очередной провод это значит понижать надежность системы во столько раз, сколько проводов у нас есть. В частности довольно забавно вышли из положения люди , которые делали эзернет. Можнопридумать такой тип кодирования, чтобы он же ещё и синхронизировал. Если идет по проводу перепад с нолика на единичку, то это нолик, а перепад наоборот это единичка. Другой вариант -- смена напряжения единичка если ничего не меняется, то нолик. Это называется манчестерское кодирование -- когда увеличивается в два раза частота и делается синхронизация.

Тогда же ещё была проблема -- а правильно ли мы воткнули провода.

Дифференциальный манчестерский код -- если перепад на такте один -- то это нолик, а если другой -- то единичка.

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

К чему хитрости? Казалось бы. проблему синхронизации решили. Вторая проблема это шум.

Шум

Шум означает ошибки. Передали мы одну информацию, а получили совсем другую. Передавали мы вот так, а получили вот так. Что в этом случае делать?Очевидно нам надро как-то контролировать тот факт, что ошибка вообще произошла. Чтобы это делать нужна избыточность, нужно передавать проверочную информацию. Самое простое на каждые 8 бит добавлять бит проверки четности.

Что тем самым мы можем определить? Что этот самый октет был передан с ошибкой.

Здесь мы вдаемся в еще большую область, которая называется кодирование информации, и это довольно таки большая область математики.

Нам важен принцип -- спд ненадежны, мы это контроллируем за счет передачи избыточной информации.

Можно ли восстанавливать испорченную информацию? Разумеется можно, только надо передавать ещё больше. Самый простой способ -- повторить три раза.

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

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

1. Коррекция ошибок
2. Коррекция искажений среды

Пресловутый компорт

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

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

Ethernet

Эзернет заранее требует, какое кодирование должно быть на проводе. Каждый из видов езернета использует свой формат кодирования. На самом деле конечно с точки зрения ос соверешенно все равно, какие цвета у оболочки жилы. Что такое витая пара? Это скрученные провода, один сигнал один земля. Почему так? Потому что наводки так меньше. Таких вот витых пар может быть в одном кабеле сколько угодно, правда в современности чаще всего используются провода, в которых таких пар четыре.

Приходит ко мне представитель повайдера проводить интернет. Протягивает кабель. Главная фишка была -- весь кабель бесплатный. Приходят, достают обжимные устройства.. И видит там лектор что-то очень странное. Разводяшие говрят, что у них специальная разводка, чтобы никто не мог врезаться в сеть. А как проверяете рабочесть? Ну как, лампочка говорит, занчит все ок. Для справки, если скрутить два сигнала, то качество сигнала очень сильно упадет.

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

ethtool

eth0

Здесь вы увидите, какой носитель с той стороны -- например, коаксиальный кабель, или полудуплексный интерфейс.

Если вам интересно посмотреть на компорт, вы можете написать

stty -a < /dev/ttyS0 

Там будет много параметров не связанных с физическими.

Еще на сайте есть упражнение -- как вообще прокинуть компорт наружу в хост систему.

Несколько слов про виртуальную машину и примеры

Что касается виртуалбокс -- это такая система управления виртуальными машинами.

Где-то пять лет назад, работа с виртуальными машинами сопрягалась с резким понижением производительности. В пять раз, и тому подобное. После того, как задача масштабируемости встала в полный рост, появилась поддержка виртуализации на уровне процессора, и накладные расходы свелись к около 20-30 процентам.

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

Немаловажное для наших целей свойство виртуальную -- простота импорта чужих виртуальных машин.

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

Базовые вещи

Для иллюстрации работы будем пользоваться интерфейсом командной строки. Интерфейс командной строки устроен очень просто -- это текстовый пошаговый интерфейс. Как пошаговая стратегия.

Пользователь составляет сообщение для интерпретатора командной строки.

Система анализирует эту строку и что-то делает.

Интерпретатор командной строки выдает результат. Как правило результат выодится в тоже окно, в которое вводилась команда.

Ползователь это дело читает, принимает решение и вводит соответствующую команду.

Если вы хотите получить какие-то данные, то они выводятся на экран, и сообщения об ошибке выводятся на тот же экран.

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

ls -a -l путь

l, a -- это флаг, или модификатор выполнения. Чаще всего ключи начинаются на минус, потому что так принято, чтоб не путаться. Сами флаги бывают двух видов -- минус-буква или минус-минус-слово. Первое проще написать, второе проще понять и запомнить. Если вы посмотрите документацию по ls вы увидите, что практически все буквы заняты.

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

Еще две вещи про интерфейс командной строки.

man man

Еще одна вещь -- как вообще происходит работа пользователя с этим самым линуксом в командной строке.

Вы подключаетесь к терминалу и видите приглашение

login:root
password:root

При вводе пароля никаких звездочек не рисуется, не думайте что клавиатура сломалась.

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

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

Вы должны иметь в виду, те из вас, кто начнет знакомстов с линукс вот с этого -- так не надо делать. Это чисто иллюстративный пример.

В Ethernet используется асинхронная передача данных в общей среде передачи данных. Проблемы:

1. Устройство захотело передавать данные, а вэто врем ядругое устройство их уже передавало. Получилась каша. Плохая идея. Устройство должно иметь мозг, слушать что происходит в спд и пока спд занято ничего не передавать. Это называется cs, определение занятости среды. В этом простом казалось бы факте -- давайте научим устройство определять занята среда или нет, есть два подводных камня. Процессоры, особенно те, которые на сетевых карточках работают не бесконечно быстро. Определили, что среда свободна, и решили начать предавать. А другое устройство начало этот же процесс на миллисекунду раньше и тоже начало передавать, за счет рейс кондишна. Эта ервая проблема, которая решается введением понятия collision detection -- определение коллизий. Даже если мы видим, что спд свободна, мы должны быть готовы к тому, что кто-то одновременно с нами начнет передавтаь. Для этого тоже должен быть какой-то мозг, который будет это определять.
2. Вторая проблема чуть более хитрая. Допустим, мы реализовали определение коллизий и прослушивание среды. Хотим передать данные, а среда занята. Что мы длаем дальше? Ждем, когда она будет свободна? Плохая идея. Есть 20 абонентов, и один все время поливает остальных данными. И все ждут-ждут когда он закончит, а потом все 19 вместе хлобысть, и начинают передавать. Эту проблему решили в Ethernet достаточно остроумно, приделав функцию ожидания случайного интервала времени. Каждое из устройств, которое заметило коллизию ждет случайный промежуток времени, а потом начинает передачу. Более того, чтобы еще проредить delay store это ожидание устроено таким спосбом -- увидели что среда занята, подождали, снова занята, увеличили время в два раза. И так пока время ожидания не станет совсем уж большим, и тогда мы диагностируем нерабочесть Ethernet. В силу этого остроумного но изобретенного на голом месте инструмента, Ethernet сеть загруженная на 30 процентов начинает заметно проседать по производительности. Потому что примерно каждый третий фрейм чего-то ждет.

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

Забегая далеко вперед -- из этого же следует простой и лобовой способ достижения времени передачи. Что позволяет гарантировать всем 1 мбит в секунду? Надо завести среду с передачей данных 100 Мбит в секунду. Тогда вероятность что оно будет не работать будет достаточно низкой. Об этом будем говорить в следующем семестре, когда будем говорить о пропускаемой через интернеты мультимедии.

Не буду сейчас вам рисовать Ethernet-фреймы, но давайте определимся с терминологией.

MAC -- Media Acces Control. Стандарт, описывающий как нам идентифицировать устройство в сети. С ним связано понятие MAC-адрес. Он сотоит из 6 октетов. 3 из них это идентификатор вендора, оставшиеся три -- идентификатор учтройства. Лектор встречался два раза с одинаковыми мак адресами в сети. Один раз это были волшебные китайские карточки, и там видимо просто не знали, что они должны быть разные. В другой раз это был волшебный скрипт, назначивший всем одинаковые мак-адреса. Сеть в которой две машины с мак-адресом работает забавно -- работает то одна машина, то другая, почему это так -- погворим в следующий раз.

Как интерпретируется мак-адрес? Каждая сетевая карта знает свой, и на аппаратном уровне отсеивает только те фреймы, которые предназначены её мак-адресу.

Есть два исключения из этого правила

1. мак-адрес FF:FF:FF:FF:FF:FF является широковещательным, его пропустит любая карточка.

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

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

Какие ещё бывают часто используемые среды передачи данных?

Вайфай. Получаем еще две задачи, связанные с дисциплиной использования среды -- авторизацию и шифрование.

WiFI

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

Различия начинаются сразу же, с аппаратного уровня. Уровень зашумления несоизмеримо выше, чем при передаче сигнала по проводам. Режим и способ кодирования совершенно другие. Применяется существенная избыточность. И невозможность разделения воздуха на всех -- каналы.

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

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

В новых используется алгоритм orthogonal frequence division modulation. frequence division modulation это когда мы передаем на одной частоте и используем как несколько каналов, в зависмочти от фазы. Слово ортогональный ри этом вот зачем -- в принципе мы можем сказать, каждый нулевой скачок принадлежит абоненту номер ноль, каждй первый номеру один, и так далее. Ортогональный означает, что кодирование для разных абонентов будет происходить на базе ортогональных векторов. Идея состоит в том, что в пачке сигналов каждый из абонентов может выделить именно предназанченный ему. Если кому-то интересно, посмотрите, как устроен cdma, он устроен наиболее просто.

Через iwconfig можно понаблюдать все эти параметры. Или через кнопочку advanced вашего ройтера.

Что касается авторизации. Авторизация неравзрывно связана с шифрованием, потому что абсолютно бесполезно авторизовываться открытм ключом.

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

Итак, у нас есть точка доступа и абонент. В отличие от Ethernet , где все одинаковы, тут есть точка доступа. На абоненте есть ключ. Он подсединяется к точке дочтупа и говорит, у меня есть ключ, он твой, я им буду шифровать трафик, а ты работай. Трафик шифруется этим ключом, и сторонний человек, его не зная, не может расшифровать и все хорошо. Обратная ситуация -- нам не надо логиниться, нам надо предъявить занние пароля.

Какая проблема? Проблема в том, что мы знаем, что за траффик здесь бегает. Это типа Ethernet фреймов, с четкой структурой. Поэтому сколько не шифруй одинаковым ключом, рано или поздно мы сможем его подобрать. Чем структурированней шифруемая информация, тем проще восстанавливается ключ. В случае файфайного траффика мы ограничены и размером пакета и его содержимым. Поэтому долгое время алгоитмы шифрования вайфая были подвержены атакам на восстановление пароля. Поэтому современный вайфай как правило устроен так, что этот ключ первоначальный и довольно быстро абонент и точка доступа постоянно перегенируют общий ключ. Предполагается что за время жизни ключа его не успеют проиндексировать.

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

Что еще интересно знать про вайфай? Для удобства пользователей кажда точка доступа наводняет пространство специальными информационными фреймами со словами "я точка доступа". Не делают этого только скрытые точки доступа. В этих информационных сообщениях есть идентификатор ESSID, это собственно имя этой точки. Обратите внимание на то, что уникальным идентификатором является именно essid, а не канал, который был выбран для передачи данных. В неокторых случаях оно может по каналам даже прыгать, если на выбранном канале оказалось слишком шумно.

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

КАкие еще бывают интерфейсные уровни передачи даных?

l2tp

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

Протоколов канального уровня столько же, сколько сред передачи данных.

Проблемы, которые решаются при подключении среды передачи данных к компьютеру проблемы всегда одни и те же. Ethernet b[ bkk.cnhbhetn достаточно хорошо, а те которые не иллюстрирует Ethernet иллюстрирует вайфай.

Лектор как-то видел авторизацию через wpa-supplicant для Ethernet.

Что касается Linux.

Несколько раз уже упоминалось здесь понятие сетевого интерфейса.

Самый простой способ посмотреть список интерфейсов

    ip link

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

Другие сетевые карты будут называться по другому. Исторически Ethernet назывался eth0, но возникла проблема когда оказалось, что сетевые карточки можно втыкать, вытыкать, менять, итак далее. Номера начинают прыгать. Особенно странно бывает, когда в зависимости от расположения пятен на солнце карточки могут распознаваться в разном порядке, и мы можем получить произволбно менющиеся местами названия карточек. Поэтому есть альтернативный способ -- есть шины данных и есть pci с номерами шин. И сейчас именование выглядит так -- enp#s#

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

ip link может не показать мак-адреса, если интерфейс не езернет. Бывают сетевый интерфейсы у которых мак адреса нет. Помимо мак адреса там есть всякие флаги -- интерфес может быть поднят, может быть опущен и штука под названием mtu. Это размер пейлоада во фрейме.

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

Из интеренсого расскажу про tun/tap -- механизм создания виртуаьных интерфейсов. Этот сетвой интерфес поднимается в случае, елси какая-нибудь прикладная программа открывает устройство. Важно что поднятие такого интерфейса сопровождается запуском программы, котора получает все данные. которые вы в этот интерфейс запихиваете. Фактически носителем куда идет траффи к является программа. с использованием такого интерфейса можно реализовать любой протокол передачи чегго угодно куда угодно. Программа может распечатывать трафик на бумажке и роботами приклеивать к лапкам голубей. В домашнем задании будет пример, где вы глазами будете смотреть трфик руками. Тун отсылает трафи куровня 3, тап отсылает трафик уровня 2.

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

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

Эта задача порождает специфику подхода к проблеме, в частности то, что мы не должны решать все задачи сразу.

Сосредоточимся на двух подзадачах: 1. Идентификация (адресация) 1. Обеспечение возможности доставки (маршрутизация)

На этом уровне не заморачиваемся надежностью.

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

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

Как решить задачу идентификации? Если бы компьютеров было 50, можно было бы дать каждому имя, которое понравилось бы хозяину,а потом упорядочить.

Компьютеров не 50, но все равно выдается каждому уникальный номер. Как и кем поговорим попозже. Лектор думает, что никого не удивит, если расскажет, что ип адрес состоит из 4 байтов или 32 битов.

Эти 32 бита делятся на 2 части -- адрес сети и адрес абонента в сети.

Нужно это для того, чтобы организовывать маршрутизацию.

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

Чтобы отличать адрес компьютера от адреса сети вводится понятие сетевая маска. Это такие 32 бита, которые состоят из единиц в том месте где у ип-адреса адрес сети и нулей в том месте, где адрес абонента.

Все единицы -- аналог широковещательного адреса в эзернете.

Тут возможны хитрости. Если у вас адрес абонента 10.0.1.255 -- может ли он быть таким? Зависит от того, какая маска подсети. Если маска /24 или /23, то нет, потому что это будет широковещательный адрес. Если же /16, то вполне может быть.

В старых учебниках были классификации сетей A B C D E, в зависимости от первых бит. В реальной жизни все перешли на бесклассовую систему. Но у этой схемы есть один выхлоп -- если адрес начинается с 1110, то это мультикастовый адрес -- такие пакеты получают несколько абонентов.

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

Где мы можем увидеть эти самые адреса в линуксе?

ip addr

127.0.0.1/8 всегда присваивается лупбэк интерфейсу. Иногда можно на нем несколько адресов создать.

Если у интерфейс поднят, то добавить ему ип адрес можно

    ip a dev ... add adress

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

Что за волшебный образ, которым перенумеровываются все компьютеры в интернете.

Этот способ административный. Есть контора под названием IANA, которая занимается буквально этим -- раздает диапазоны адресов всем желающим. Приходит провайдер, говорит - у меня столько клиентов, столько планируется. дайте мне столько адресов. Провайдер проверяют и дают ему сеть класса А. Провайдер приходит к свои клиентам и начинает спрашивать -- ну что, никому не нужна сеть /17? Отдам почти задаром. Дальше они передоверяют другим организациям и так далее и так далее.

Это именно диапазоны ип-адресов, которые мы должны зарегистрировать и использовать. Поскольку ип-адресов уже не хватило, то диапазон могут отобрать -- мы вам выдали сеть класса Б, а вы используете три компьютера. отдавайте обратно, народ хочет. Какого размера может быть сетевая маска? 30. При 31 -- остается только маска и мультикаст. 32 -- может быть, означает что это просто ип-адрес, поговрим позже.

Как принимать решение о том чтобы смаршрутизировать наши пакеты?

Мы можем нарисовать карту абонентов на 0 абонентов и жестко прописать как именно маршрутизировать.

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

Какой есть выход из этого положения? Не видеть ничего дальше собственного носа. Принимать решения о маршрутизации на основании только ближайших видимых спд.

Для нас это означает две вещи. При добавлении адреса на интерфйс автоматически запоминается что вся эта подсеть находится за этим интерфейсом передачи данных.

ip a 1.2.3.4/16 dev eth0

Означает, что когда мы захотим послать на 1.2.111.111, мы отправим туда.

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

В таблицу маршрутизации добавляются записи вида "такая то сеть доступна за таким то маршрутизатором"

    0.0.0.0/0 -> 1.2.3.1
    4.3.0.0/16 -> 1.2.3.100

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

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

ip route

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

Именно ради того чтобы переписать работу с маргрутизацией Кузнецов переписал очень много в этой части ip.

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

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

На следующий раз обещана история рашн впн, она же корбина нетворк.

Маршрутные таблицы заполняются автоматом при добавлении адресов на интерфейс.

В приницпе маршрутные таблицы можно заполнять с помощью специальных протоколов. Вы не знаете, за кем находится адрес, но знаете того, кто знает, и дложен вам про это рассказать. Для этого разработано несколько специальных протоколов. МСамый известный имеет говорящее название RIP. В нем нашлось бездна уязвимостей, сделали RIP2... Насколько механизм используется сегодня лектор не знает. Известно только одно -- при передаче такой информации необходимо убедиться, что передающая машина не передаст вам какой-нибудь треш, который превратит ваш маршрутизатор в тыкву.

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

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

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

Автономных ситсем несколько тысяч, возможно десятки тысяч. Построить карту можно, такие решения есть у больших операторов. стоят специальные сервера, которые отследивают это фулвью.

Постоянно отслеживается не пропала ли связность, и сколько стоит тот или иной путь (стоит как в понятии денег, так и других -- загруженности канала например) Ещё одна особенность border gateway protocol, что оно представляет интернет как граф, а не как дерево.

В лекциях есть табличка разных специальных ип адресов.

127.0.0.1 -- лупбэк

224.х.х.х -- мультикастовый

Что ещё есть интересного? Интранет адреса. Адреса которые вообщен нельзя маршрутизировать наружу. Прошел год с тех пор как был делигирован последний диапазон. Как так получилось, что адресов всем еще хватает? Есть три класса адресов, которые не уникальный

10.0.0.0/8
192.168.0.0/16
172.16.0.0/12 

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

169.254.0.0/16

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

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

В предыдущем изложении есть один пробел.

Предположим мы описываем процесс передачи пакета от одного компьютера к другому.

Внимание вопрос -- а как я узнаю мак адрес получателя?

Когда у нас полносвязная сеть, у нас есть просто провод, по которому мы посылаем. В случае езернета общая шина, и про мак адреса мы ничего не знаем. Чтобы выяснить у кого из абонентов мак такой-то, нужно послать арп- запрос. Это широковещательный эзернет фрейм,в уотором написано -- вот такой айпишник, он чей?

Традиционно таблица соответствия ип и мак адресов называется арп таблицей. В терминах утилиты ип это таблиуа соседей.

ip neigh.

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

Могут выдать этот ипшник кому-нибудь еще.

Поэтому таблица соседей держится очень недолго и у нее есть три стадии, после прохождения трех стадий запись удаляется. Если запись удалена, то снова происходит арп-запрос.

Протокол ICMP

Это договоренность о том, как абоненты интернета сигнализируют друг другу о том все так или не так.

Для чего используется icmp. Посылаете кому-то пакет, а для него маршрутизация невозможна.

Path mtu discovery -- во всех случаях при отправлении пакета ставится флажок, что его нельзя фрагментировать. Если он попадает в спд, куда он не пролезает, маршрутизатор не будет пытаться его дальше проотолкнуть, а вернет ицмп сообщение -- что нужно фрагментировать и сказать, сколько байтов могло бы пролезть. Процедура когда мы сначала посылаем пакет с запрещенной фрагментацией, а потом ловим ошибки называется path mtu discovery.

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

Про ипв6 гораздо большихше чем способен рассказать лектор можно найти в интернетах.

В ipv6 горахдо лучше разработаны механизмы мультикаст и эникаст. И то и другое -- результат договоренности и построения деревьев доступности абонентов. Зато можно организовывать распределение нагрузки, что весьма сложно реализуется для ипв4.

В ипв6 нету фрагментации, контрольной суммы в пакете

ipsec. Поначалу ипв6 включал в себя обязательное шифрование. Но потом шифрующие устройства перегрелись и его сделали необязательным.

У нас сегодня продолжение разговора про сетевой уровень тцпип в линукс.

Это продолжение должно носить более практический характер.

Вместо последней лекции будет демонстрационное решение всех домашних заданий.

Сегодня про разные разности связанные с третьим сетевым уровнем.

Начну с рассказа про рашн впн. Пржде чем, давайте немножко поговрим про то, что такое впн.

Немножко, потому что множко будет в следующем семестре.

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

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

Много современных провайдеров предоставляют доступ к интернету таким способом -- вам в квартиру приходит провод, и даже если вы не заплатили за интернет вы можете пронаблюдать трафик который бегает по нему. Еще вм и ип адрес выдадут. Этот адрес будет интранет. И вы сможете увидеть блок локальных сетей, внутри которых безлимитный трафик, файлопомойка, вирусы, все удовольствия. А чтобы получить интерент вы должны настроить впн. при этом словом впн провайдер может называть что угодно. Начиная от банального пптп (peer to peer transfer protocol).

Идея пптп. У вас есть впн-сервер, от него уходят специального вида пакеты. Они попадают в конце концов на впн клиент. После применения к этим пакетам нужного протокола у вас появляется еще один интерфейс, например, tun0. На нем у вас появляется еще один айпишник, маршрут, и весь интернет трафик ходит через тун0. Принимаете езернет пакеты, декапсулируете до прикладного уровня. Натуральная виртуальная локальная сеть, с маршрутизатором в интернет. Впн соединение как правило требует логин-пароль, и управлять такого рода соединениями легче, чем банальным интернетом.

Лектор видал это в очень многих ипостасях, вплоть до пск-авторизации через езернет.

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

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

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

Что будет, если впн не будет лежать в локальной сети? У вас адрес 10.1.2.3, а у впн-сервеа 10.100.0.1. Эта схема немедленно сломается. Дефолт роут вас вел в 10.1.21.1/24. Вы устанавливаете подключение к впн серверу, у него адрес типа 123.45.67.8 и маршрут по умолчанию 123.45.67.1. Пакеты до впн сервера будут тыкаться в этот новый дефолт роут и ничего не находить.

Как починить? Пропишем роут с более высоким приоритетом.

10.100.0.1 -> 10.1.2.1

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

Но проблемы только начинаются. Адреса впн-серверов меняются динамически. Что делает народ? Собирает огромные таблицы всех возможных впн-серверов и пробивает их всез в дефолт маршруты.

Корбина говорит. нам все надоело, вот вам днс сервер, спрашивайте у него. Но днс сервер тоже лежит не в локальной сети...

В принципе, написание небольшой примочки, которая бы смотрела какой приехал маршрут по умолчанию и прибивала бы его до 10.0.0.0/8, что бы все что в интернет ходило бы в впн. а по локальной сети -- через старый маршрут, в приницпе решает проблему.

Почему при этом что-то работает в том же виндовсе лектор не знает.

Версия 1 -- в виндовсе есть соответствующий хак.

Вторая гипотеза -- что при настройке езернета приезжают нестандартные параметры дхцп.

Лектор только знает, что dlink dr600 со старой прошивкой в корбине не работает. Вы идете на форум, и там узнаете о существовании специальной прошивки, у которой рядом с пунктом впн есть пункт рашн впн, вы его выбираете и все начинает работать.

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

Это было отступление на тему прошлого раза.

Простая маршрутизация по принципу нормального алгоритма Маркова.

Вообще говря для просто настройки интернета нужно 2 вещи. ип адреса и ип роуты.

ip addr add ....
ip route add default...

Хорошо ли, что для настройки интернета надо говорить командочки от рута? Плохо.

Можно написать стартовый сценарий, который бы от рута все это говорил.

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

Показательно устроена эта настройка в альт линукс. Изначально схема была разработана для прошивки небольших нестандартных маршрутизаторов у одного белорусского провайдера. Называется etcnet. Главный принцип -- систематизировать все сетевые настройки, а с другой стороны как можно меньше менять. Идея етцнет состоит втом, что прямо куски команд ип аддр ип роут разложить по иерархии файлов вида /etc/net/ifaces/enp0s1/ipv4addr.

Точно также етцнет настраивает фаерволл, тунели, вайфаи, практически все что можно настроить при старте системы.

Достоинство -- даже если вы встретились с нестандартной конфигурацией сети, который недоступен етцнету, то поскольку он просто пачка скриптов на шелле, он легко подвержен модификации.

Главный недостаток всех аналогичных систем инициализации сети состоит в том, что они статические. Не в том смысле, что они статические адреса получают.

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

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

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

Кстати сказать, etcnet сопровождается обильной документацией с примерами (правда, там проблемы с простыми примерами...)

В /etc/net/scripts лежат все пачки скриптов, которые этим занимаются

Способность быть маршрутизатором включатеся и выключается, за это отвечает параметр ядра.

Есть три варианта действий -- воспользоваться командной sysctl, которая лезет в ядро. Например,

sysctl net.ipv4.ip_forward  = 1

Второй вариант

    /proc/sys/net/ipv4/ip_forward 

Туда можно сказать эхо 1. sysctl тоже ходит в тот же файл.

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

Скоре всего ваша система настройки сети сама читает конфиг, в котором написано, надо ли это включить.

Это все хорошо, но лектор вот на своем компьютере сеть не настраивает, она сама настраивается.

Reverse ARP

Помните протокол арп? рарп это проотокол не преобразования одного адреса в другой, а получение ип адреса в ответ на мак. Как космонавт в песне.

Почему он не исопльзуется? Потому что настроить только ип недостаточно, надо настроить еще маршруты.

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

BootP

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

Примерно из этого состоит начинка протокола BootP.

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

DHCP

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

Процедура такая. Сначала он кричит "ребята, никто не хочет меня это, отконфигурировать?" -- dhcp discover. Ему несколько дхцп серверов (лучше бы один), посылают оффер -- так настроиться, или вот этак настроиться.

Клиент их рассматривает и посылает выбранному серверу dhcp request. Дальше сервер посылает acknowledgement.

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

Обратите внимание, что здесь неспецифицировано, какие настройки будут приезжать в оффере. А их много. До 50 стандартных, и все что хотите в экстеншенах, лишь бы ваш клиент их понимал.

В домашнем задании будет пример готовой настройки дхцп сервера.

PXE

PXE -- загрузка компьютера средствами сетевой карты. Поддержка BootP и tftp. Это комплект по, который позволяет грузитькомпьютер по сети. Такой биос.

Осталось рассказать про одну вещь.

Целевая маршрутизация

У нас есть стандартный алгоритм маршрутизации, о котором мы говорили в прошлый раз.

Таблица маршуртизации и в ней записи практически одного вида подсеть в маршрутизатор.

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

Все это здоров, пока мы реаем абстрактную задачу обеспечения воможности доставки пакета.

Но иногда некоторые пакеты не доставлять. Или пакеты от некоторых ипшников не доставлять. Итд.

Есть интернет медленный и дешевый или дорогой и быстрый. И вы хотите чтобы одни пользователи ходили через быстрый, а другие через медленные.

Задача -- на основании ип пакета принять решение о маршрутизации. Стандартная маршрутизация пользуется только адресом получателя. Хотелось бы пользоваться еще как минимум адресом отправителя.

С этим тоже справляется линуксовый ип-стек, для этого служит командочка ip rule.

Три таблицы маршрутизации.

main, которая выдается ip route list table main. В ней в простейшем случае две записи -- маршрут по умолчанию и маршрут на локальную сеть. На самом деле при обеспечении доставки в локальную сеть надо гораздо больше информации иметь, эта информации хранится в табличке local -- какой бродкаст, итп. Еще есть табличка default, она пустаю. Просматриваются в порядке local-main-default. При этом маршрут по умолчанию лежит в табличке main.

Вам ничего не мешает создать свою собственную табличку маршрутизации за каким-нибудь номером.

    ip rule from boss_ip table 200 

И дальше с помощью ip route заполнять эту табличку.

В результате все решения для маршрутизации с этих ипшников будет происходить с использованием не таблички main, а таблички 200. Если попроавить один конфиг, то можно присвоить этой табличке названия.

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

Это была попытка написать фаерволл сетевого уровня, но это, конечно, не так интересно и большая часть хитрых функций фаерволла находится уровнем выше.

Домашнее задание.

Будет две машины.

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

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

Транспортный уровень решает три задачи. Целостность и надежность и работа с потоками данных.

Давайте представим, какой объем задач надо решать на этом уровне.

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

Какой объем задач хотелось бы решать.

Целостность

Первый пункт -- хорошо бы убедиться что то, что мы отправли это то, что мы приняли -- Целостность.

Обратите внимание, что у нас данные фрашгментированы. Мы нарезаем пользовательске данные на куски и ими обмениваемся. Сами куски отлично доезжают, но, данное которое мы передавали больше одного куска. Важно, чтоб ы мы вели учет кусков, отслеживали ситуацию когда этих кусков больше чем нужно или меньше чем нужно. И мы должны проверить что отправленные пакеты пришли в правильном порядке. Точнее, нам неважно как они пришли, лишь бы мы их могли переупорядочить в правильном порядке. Нумерация и учет дело транспортного протокола.

Сам объект может быть бесконечного размера (интернет радио) поэтому в произвольном порядке куски посылать нельзя.

Накладывается ограничение -- пакеты нумеруются и прийти они должны в правильном порядке. Если 4-ый пришел до 3-го, то 4-ый мы не принимаем.

Заботиться об этой последовательности имеет смысл только если данные разблись на несколько пакетов.

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

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

Управление процессом передачи

Было бы недурно проверить, идет ли передача. Существует ли получатель. Как ни смешно, это отдельный момент сетевых протоколов, который есть далеко не во всех протоколах. В терминах тцп это называется установление соединения.

Еще было бы неплохо принимать от абонента подтверждение о доставке, а также об ошибке, а также, например о том, что пакет зажевали посередине.

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

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

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

Еще один пункт -- управление пропускной способностью и параметрами потока.

Помните пример, когда с одноой стороны хороший интернет, а с другой плохой. Вливает фильм со скоростью мегабит, а с с другой стороны адсл с 160 килобит.

Регулировка параметров канала

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

Два представления данных на Транспортном уровне -- поток и датаграмма.

Выглядит довольно очевидным, что либо все есть, либо нет. Наконец, последняя группа задач, которую надо решать --

Идентификация потоков данных (или датаграмм)

Мы уже решали этот вопрос, как в том анекдоте, когда бизнесмен торговал секундными стрелками и повидлом по смешной цене, потому что они в одном вагоне ехали и перемешались. У нас недостаточно информации на сетевом уровне чтобы различить несколько потоков данных, у которых отправитель и получатель совпадают. зашли на вебсервер, там хтмл и картинки, и то и другое вы скачиваете с одного ип адреса надругой п адрес, как сделать чтобы это были разные потоки данных?

адрес отправителя, адрес получателя и что-то езё, уникально идентифицирующее поток данных.

Недолго думая разработчики тцп/ип придумали такую штуку как порт. Порт отправителя и порт получателя. Слово возникло по аналогии с хардвар терминологии --- последовательный порт, параллельный порт и так далее. Как когда вы пишите программу на ассемблере у вас есть ин и аут и специальный адрес, куда ин и куда аут. Так и здесь -- две дыры, помимо того, что они расположены на каких-то ип-адресах, эти дырки адресуются портами п1 и п2. Такая четверка уникально идентифицирует поток.

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

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

Порт, по которому осуществляется соединение по протоколу прикладного уровня заранее зарегистрирован.

Вы можете повесить хттп на 25 порт, но непонятно чего вы этим добьетесь.

Отклоняться от этих рекомендаций не рекомендуется. Но, налицо некоторая проблема.

Если мы зашли н вебсервер, то у нас 3 числа из 4 фиксированы. Значит, для каждого сеанса передачи данных ос должна выбрать порт отправителя, так чтобы поток данных стал уникальным. Под это зарезервированы порты от 32768 от 65535.

Как следствие получается что процесс этот строго ассиметричен. Всегда есть клиент, который инициирует соединение и сервер, который его принимает. Те, кто писал практикум на втором курсе про это помнят.

Немного про TCP

Как происходит установление соединения?

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

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

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

C - SYN1 -> S
C <- ACK1 + SYN3 - S
C - ACK2 + DATA1 -> S

Пакетами ак-дата они и продолжают обмениваться пока кому-то это не надоедает и он не решает закрыть соединение.

c - ACK2 + FIN1 -> S
C <- ACK1+FIN2 - S
C - ACK2 -> S

Что из этого видно? Если этот оверхед становится большим, надо переходить на UDP.

В этой последовательности есть одна дырка, из-за которой злоумышленник может заставить сервер выделить очень много памяти. Если послать серверу бесконечно много SYN, то на каждый раз сервер заведет буфер под тцп соединение. Это называется SYN flood атака. Борятся с этим обычно межсетевыми экранами.

SeqN генерируется слуайно в первый раз, но затем к нему прибавляется размер переданных данных. Если абонент получил пакет 5, а в нем данных меньше, чем SeqN - Seq(N-1), то пакет 4 он не получил.

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

У этого процесса есть одно тонкое место. Оно связано с ситуацией качества среды. Что, если у нас годный канал и ошибки встречаются редко? Тогда полная синхронизация нам мешает. Еще больше мы начинаем страдать от ситуации, когда наблюдаемые канал хороший, а перемешивание пакетов сильное -- провайдер разбрасывает пакеты по разным каналам. И мы не сможем послать новый пакет пока не получим старый.

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

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

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

UDP

Первое свойство -- весь сеанс обмена данных это одна датаграмма. Именно в этом случае использовать удп выгодно. еще его выгодно использовать когда у вас очень хорший канал связи, то есть операция по обработке ошибок на прикладном уровне возникает крайне редко, а объемы данных настолько велики, что ни одно тцп соединение по человечески с таким соединением не справится.Типичный пример -- файловые системы, например NFS.

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

Третье свойство udp -- его можно использовать для мультикаст вещания.

Примеры использования udp в реаллайфе:

1. NFS. Там, на самом деле не так просто. Это stateless протокол. На уровне приложения никогда не отслежваются состояния потока. Просто идут запросы.
2. DNS.
3. SNMP, NTP
4. traceroute
5. RNTP, протоколы вещания видео в сетях.

NAT

Из каких соображений мы сделаем подстановку внутреннего адреса? Подменяется не только ip адрес, но и порт. И мы можем запомнить, что тцп соединения с нашего порта 40000 идет с такого-то хоста, а 40001 с другого.

Вопрос на разминку. Если это DNS запрос, он может пройти чере трансляцию сетевых адресов. Как вообще устроен днс запрос -- отсылаем датаграмму серверу. Как поймем, что сервер ответил именно нам? У днс запроса есть на прикладном уровне уникальный идентификатор.

FTP

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

Работает он так. У вас есть 21 порт, управляющий. Клиент присоединяется к серверу и спрашивает что есть. Сервер рассказывает. Клиент говорит "хочу файл, пожалуйста, передай его мне на такой-то порт". После этого сервер инициирует соединение клиенту на порт порт.

Как этому пройти через NAT? Проковыривать дырочки, отслеживая на сервере получения команд о передаче файла и его пробрасывать. Тем паче, что соединение с любой внутренней машиной на проивзольный порт обычно не практикуется.

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

По этой причине протокол фтп стремительно устаревает. Кроме того у него есть главна проблема -- клиент и сервер передают пару ип-порт. А если они за натом, то все это нужно по ходу модифицировать, и упражнений там существенно больше чем толку.

Прочее

DCCP -- можно использовать как разделение udp трафика на разные потоки.

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

Как контролируется забитие интернета траффиком? Сбрасыванием окна. Никому не кажется странным, что с забитием боремся увелиением количества трафика?

ecn -- early connection notification. Если сервер видит, что скоро заткнется, он заранее начинает рассылать предупреждения, что мол схлопывайте ваши окна прямо сейчас, или уменьшайте их размер.

rspp -- я собираюсь передавать данные, мне нужно не меньше мегабита, есть? Работает только в ипв6.

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

Эту задачу надо решать.

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

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

Вопрос как осуществляется доставка контента до приложения остается открытым.

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

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

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

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

C ltvjybxtcrjq ceoyjcnm. ,skb cdzpfys курьезные проблемы, история о проклятии почтового сервера особо ярыми пастырями.

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

С тех пор сохранились некоторые методы управления демонами. Стандартные ввод-вывод не годятся, надо заклинания читать. Поэтому обычно общаются, посылая сигнал командой kill. Например hangout перезапускает демон, так пошло со времен терминальных линий.

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

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

1. Просто берем и в определенном порядке запускаем все нужные нам демоны. Единственное что важно -- пресловутый определенный порядок. И это все. Достаточно доовориться о последовательности запуска. Самая известная и очень старая схема по запуску служб таким образом называется sysvinit. У сисвинита был один недостаток, который надо было преодолеть для пущей прозрачности самой процедуры запуска. Поскольку мы должны строго соблюдать последовательность загрузки служб, то ничего более умного чем присвоить каждой процедуре запуска демон номер придумать нельзя. Долго так и поступали, но возникает вопрос, кто вообще эти номера придумывает? Линукс это сообщество, делается многими людьми. Служб чертова прорва и они все должны договориться кто за кем идет, что в принципе слабо возможно.
2. Как это дело обходить? Да очень просто, ввести понятие зависимости. LSB, openrc итд. С точки зрения сети те демоны, которые запускаются, запускаются абы когда, но к моменту выхода на штатную работу. У этого способа есть слепое пятно. Процедура запуска демона занимает определенное время. Когда мы запускаем какую-то службу мы вынуждены выносить логику в сценраий на шелле, и он сам будет вызывать стартовые процедуры для проверки, убеждаться в запуске и так далее. Если же мы хотим писать все таки конфигурационный файл, то описание условий при которых у нас происходит запуск и его способ должны отражаться в конфигурационном файле. Здесь появляется еще одно средство запуска.
3. systemd создание ситуации когда писать сценарии не надо. Добавляются условия запуска, и возможность запуска не демона. В чем главный недостаток такого дела? Всех под одну гребенку не подравняешь, для сложных демонов придется все равно писать шелл скрипт. Но в большинстве случаев можем сказать, что вот сервис, стандартный вывод у него идет в стдерр, и прежде чем его стартовать надо проверить то-то и это. Тем самым сэкономить время при старте. Для нас с вам важно то, что конфигурационный файл описывает условия запуска и возможность активизации сценария без демонизации.

Итого, либо щапускаем все демоны подряд, либо по дереву ависимости, либо зависимости + условия запуска + возможность запуска не демонов.

Запускается демон. Как обеспечить факт доставки трафика до этого демона. Вариант первый -- сам демон написан таким способм, что он занимается установкой сетевого соединения, создает сокет и нчинает его слушать.

Про сокет мы в прошлый раз говорили -- это объект который описывает, как устроен тцп или удп соединение.

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

Что бывает, когда подключение заканчивается? Есть несколько вариантов.

1. демон выключается. Например, потому что его потом запустит другой демон. Можно вообразить такую извращенную реализацию фтп -- управление принимает один демон, а данные другой.
2. Что делать после закрытия соединения? Надо начинать опять слушать сокет или вообще не прекращать его слушать. Обычно отдельный процесс или тред вешается на прослушивание соединения, и по необходимости создаем тред обслуживающий соединение, а сами продолжаем слушать дальше.
3. обслуживание нскольких соединения. Кстати не всегда надо, иногда надо отказывать соединениям, если одно уже активно. Если надо обслуживать несколько соединений, то другая проблема -- а если их 100500? Помимо обслуживания нескольких соединений необходимо подумать, как их ограничивать.

Метадемон

Метадемон это как раз и есть сетевая обвязка интерпретатора который работает со стандартным вводов, выводом выводм ошибок. inetd xinetd.

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

Что мы должны надежно представлять?

1. Конечно же возможности по определнию сколько каких подключений мы можем позвоить у нас ограничены, потому что лезть в прикладной трафик на уровне инетд мы не можем.
2. Второй недостаток, хотя его наверно можно преодолеть.. Вот у вас есть интерпретатор прикладного протокола -- такая мощная животина. И увас 10 000 подключений в секунду,, и это нормально. В случае если мы написали собственный демон, и в нем один процесс слушает на этом порту и на каждое подключение запускает интерпретатор из файла да еще и организовывает канал, то получается большая нагрузка на систему.

Что можно себе вообразить еще на эту тему?

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

У системд есть сокет активация. Заранее создаем сокет, кстати, он не обязан быть сетевым. Сокет активация

1. запуск демонов
2. запуск интепретаторов
3. запуск сетевых служб без демонизации

Часто приходится добавлять специальную систему для управления демонами.

Например, надо остановить вебсервер. Надо послать сигналы процессаМ, которые относятся к вебсерверу и только к нему. Как определить эти процессы без доп информации -- непонятно.

Помимо всего прочего сложные демоны должны поддердживать сами процедуру управления собой.

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

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

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

Мы говорили о ситуации когда задача связывания трафика на сетевом уровне и на прикладном уже решена. Мы уже знали к какому порту адо подключиться чтобы получить обслуживание со стороны ос. Для этого есть пачка зарегистрированных портов за определенными службами. Это отражено в файле /etc/services. Но, есть три проблемы, связанные с статической регистрацией определенных служб с определенными портами.

1. мы можем захотеть не определенный проотокол, а определенной функцией в протоколе или не в проотоколе. Это немножко в стороне от общих сетевых технологий, скорее возникло в распределенных вычислениях. Но сути это не меняет, вмест о обслуживания по какому то проотколу мы хотим получить какую-то функцию, причем мы сами картируем функции удаленных компьютеров, после чего кним обрааемся сообразно картированию. Мы получаем невозможность зарегистрировать все службы один раз и мы не имеем возможность сделать этостатически. У нас проблема с
   1. нерегистрацией
   2. динамическая привзяка к порту. Порт получателя перестал быть жестко привязанным.
   3. у функции могут быть разные версии. проверка наличия функции на компьютере и его версии
   4. анонс
   RPC это технология сводящаяся к вышеописанному.Есть некий протокол, позволяющий картировать, проверять, версионировать и описывать формат передаваемых данных. В чем идея рпц? Запускаете специальный демон rpc mapper и он занимается картированием. Каждая служба ходит и говорит "я служба такая-то, отдаю функцию такую-то". Перечислены в файле /etc/rpс. На 111 порту сидит портмаппер. И дальше она начинает раздавать порты. Помимо номера и имени сервиса в портмаппере регистрируются также версии.

Соответственно командочка rpcinfo вам расскажет довольно много о том на каких портах какие функции обслуживаются в вашей системе.

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

Проблемы анонсирования мы обсудим в следующий раз.

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

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

Когда нужна и активация по сокету, и работа демона с сокетом, это решается новомдными системами запуска типа systemd.

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

Чего не хватает в нашем супе? Можем ли мы с помощью перечисленного пользоваться интернетом? Ответ нет нельзя, потому что мы ничего не говории о днс.

Если у нас компьютеров в сети 12 штук, мы можем взять и запомнить 12 адресов.

Если у нас компьютеров 100, запомнить все сложно, но можем сделать специальный файл /etc/hosts со строчками вида адрес - имя. И положить этот файл на 100 компьютеров.

Чем наличие второго слоя именования усложнило задачу? Ваша программа не обязана знать про файл с соответствиями.

В программном смысле все должны использовать libresolve чтобы пользоваться вместо адресов именами.

Какой бонус? На прикладном уровне адресация отвязана от уровня сетевого. Когда вы пишите uneex.ru или uneex.org -- они соответствуют одному и тому же ип-адресу.

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

В чем недостаток файла?

1. Сам компьютер хочет решать какое у него имя. Брезжит проблема, которая заключается в следующем -- никто не может единолично написать всех адресов и имен в интернете, потому что решения об именовании принимается многими людьми -- администраторами. Решением проблемы является анонсирование. Анонсирование очень древний прием -- аппл ток, и прочие. Многие протоколы, особенно в локальной сети, имели возможность анонсирования.
   1. Её никто не может раздать по всем компьютерам, она слишком быстро меняется.
   В чем недостатки анонсирования?
   1. Нужен какой-то порядок анонсирование.
   2. Если компьютеров слишком много, вместо анонсирования вы получите флуд.
   Надо вводить систему, которая обеспечивала бы адекватное превращение имен в адреса. Она должна быть распределенная и привязка адресов к имени должна управлятся со стороны администраторов, а не большого дяди. С другой стороны как же без большого дяди.

На волне этого возникла DNS.

Какие проблемы мы должны решать?

1. децентрализация, потому что никто не знает всех имен
2. централизация -- должно быть место, куда вы идете, чтобы узнать ответ на вопросы.

Решением является распределенная иерархия.

Именно с этим связано понятие домена. Что это такое? Это из феодальных времен. Когда люди уже стали жить достаточно хорошо, и рабов стали использовать как людей, но необходимость вертикальной власти все еще сохранялась, изобрели такой строй -- есть лендлорд, он хозяин земли, у него есть крестьяне, которые пользуются землей (как мы пользуемся некоторыми лицензионными продуктами). Чтобы управлять конгломератом должен быть еще один человек, который хозяин. Хозяин хозяев король, хозяин королей бог. Там еще очень весело деньги перераспределялись.

Конгломераты назывались доменами. Отношения назывались отношениями вассала и сюзерена.

Чтобы разделить имена никаких технических инструментов не надо.

Когда государство берет на себя функции раздачи имен более мелким пользователям, оно делает так -- организует несколько больших доменов. А дальше некоторая большая организация говорит -- хочу получить поддомен msu.ru. государство говорит ок, но внутри себя будешь отвечать само.

Когда хочется понять, какой домен, идется сначала к корневому днс. Если оно не знает адрес, то оно спрашивает, где сервер имен для msu.ru.

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

Конечно, с любым адресом к корневым серверам не ходят. Полную такую процедуру должны мочь делать не все.Каждому дается ип-адрес локального днс-сервера.

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

Есть у записи в базе данных такая штука, как время жизни. Сервер запоминает табличку ровно на это время.

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

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

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

Упомяну, что эти 2-3-4 неймсервера у зоны не могут быть равноправными. Вы добавляете руками хост сначала в одну. Получается одна главная, другие неглавные.

Как получать обновления? Сушествует куча протоколов для поддержания актуальности реплик. Такая ситуация у бинд. На самом верху там все хитрее.

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

Итак у нас получается достаточно забавная распределенная база данных, которая хранит в себе распределенное преобразование доменных имен в адреса. Запись типа а рассказывает адрес. Запись типа ns преобразует доменное имя в адрес или доменное имя неймсерверов соответствующего домена. Запись типа mx рассказывает куда посылать почту. cname -- когда у вас несколько имен у одной машины -- алиасы на какое-то центральное имя.

SOA -- относится к блоку имен, и там указаны много разных числовых характеристик.

Отдельный интерес представляют SRV и TXT.

TXT позволяет хранить в днсе все. Зачем? Удобная же вешь распределенная база данных.

Зачем нужна SRV? Мы с вами почти сделали структуру для хождения по интернету. Есть еще некие ограничения -- обычно, например, рекурсивные запросы только для своих клиентов.

Задача анонса еще не решена.

Мы хотим анонсировать разное -- например принтер или файловую помойку.

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

Можно делать это с помощью днса, введя туда специальный тип записей SRV. Правда придется научить днс-сервер менять таблицу по запросу. Возникает много проблем с безопасностью. Протокол называется DynDNS.

Запись типа срв позволяет анонсировать через днс некоторые службы.

У имени чем ближе к началу, тем конкретнее, у адреса наоборот.

По этой причину нейм-сервер который занимает бэкрезолвом хранит октеты ип-адреса в обратном порядке.

В чем недостаток анонса через днс? Юзабилити версус секьюрити.

Хотелось бы чтобы каждый мог анонсировать что хотел, но это бы согласвывалось с анонсированным товарищами.

Что еще бывает в автоматической настройке? Например присвоить ип-адрес, если его никто не выдает. Самонастройки и их анонс.

По результатам самонастройки можно выяснять чужие настройки. Локальный днс по результатам анонса.

Ну и собственно анонсирование служб как таковых.

Раньще особенно виндоус постоянно устраивали перевыборы космонавтов и всякое такое.

zeroconf и его реализация avahi значительно проще.

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

Что будет у вас на машине? Демон на порту 5353 и мултикаст.

У вас будет авахи демон, avahi browse. у него есть прекрасный ключик -t, terminate. Когда вы говорите browse было бы хорошо, чтобы он когда-нибудь перестал смотреть. Но учитывая, что никто не знает что соседи заанонсировали, надо уметь его останавливать.

Есть возможность самому анонсировать доступность служб с помощью avahii publish, либо если это какой-то системный анонс, то вы тогда делаете описаолов, которое при старте он его съедает и все описатели анонсирует. Конкретные примеры на странице лекции.

К этому надо пришпандорить два замечания. Что не хватает? Не хватает главного, что означают волшебные буквы, вывещивающияся в анонсе.

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

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

Второе замечание про все в целом.

libresolve управляется nsswitch.conf -- управление работой с пространствами имен. Именно в нем указывается, как будут обрабатываться преобразования.

NFS

Network File system

Какие можно вообразить проблемы при создании сетевой фс?

Когда возникла необходимость хранить данные в сети?

Тогда сети быти тухлые и хотелось минимизировать и ускорить ходяший по ним трафик.

Протоко работает по udp или по tcp,

Разрабатывался SUN, когда та ещё занималась RPC. Он построен на нем весь. Напоминаю, что это такой способ динамического анонсирования доступных портов.

Будем считать, что порт 2049.

Забота о быстродействии привела создателей nfs к идее создания фс без сохранения состояний. Идемпотентный протокол. Можете взять и послать на нфс сервер несколько датаграмм, открывающих файл, и никто ругаться на это не будет.

В этом смысле UDP особенно удобен для реализация Идемпотентных функций. Одна операция -- одна датаграмма.

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

Помимо этого есть несколько недостатков. Несколько компьютеров открывают файл и начинают писать. Кто последний записал, того и тапки.

Зато такой фс можно пользоваться как обычной фс с помощью mount и unmount

Есть команда showmount -e

Файлик /etc/exports

Помимо нфс есть пресловутый цифс.

mount проводится от рута, а доступ на запись получает пользователь. На каком основании разрешать или не разрешать монтировать? На основе ип в файла экспортсс.

Если специально не прицелиться в ногу, то от рута в нфс записать не получится, зато от любого другого пользователя вполне.

Что касается самбы.

Помимо того, что это протокол для передачи всего. common internet file service, которая ничего из этого. Это не ip-based аутентификация, а user-base. Чтобы там что то делать, нужны логин и пароль.

nfs4 правда умеет работать по керберосу, но для этого керберос надо ещё сначала настроить.

В домашнем задании будет autofs. Это пример того как можно воспользоваться анонсом серверов через авахи и через днс.

Подбираемся к вопросам безопасности. Мегаупрощенное введение.

Для начала не стоит забывать, что безопасность это штука как минимумм двоякая. Боюсь дать хорошее определение, н в любом случае речь идет о жвух вещах сразу, о надежности и о секретности.

Вопросы надежности сети, в особенности интернета очень интересны, и этим также занимаются в большом объеме, мы поговорим об этом немножко.

Интернет сам по себе не надежен. На разных уровнях ддля контроля целостности используются контрольные суммы. В случае tcp контролируется целостность потока.

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

Повышение связности является решением этой проблемы и протоколы, которые отслеживают связность.

Хотелось бы быть уверенным в том, чтобы соответствующая пропускная спосбоность была бы достаточно чтобы передавать эти данные.

Задача гарнтированной пропускной способности может решаться двумя основными способами:

• оверпровайжонинг. нуден килобайт, резервируем мегабайт. Примерно так обыно и делается, несколько порядков. Хотя в силу природы интернета даже это ничего не гарантирует. Сколько порядков -- зависит от цены вопроса.
• внедрить некую информацию о желаемых параметрах прямо в сетевой протокол. Это немножко из серии мечтателей. Но можно разработать протоколы и соответствующие им условия использования, чтобы можно было что-либо гарантировать. В частности такое есть в ipv6. Мы с вами сталкивались с проотолоклом ecm -- когда маршрутизатор предупреждает предыдущий маршрутизатор о том, что канал перегружен.

Что такое секртеность? Это защита данных от разного рода атак на них. Тут возникает два вопроса, как мне кажется слегка отвязанных друг от друга.

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

Атакой может являться много что, вплоть до непреднамеренного форматирования винчестера. Мы должны смотреть на то, что у нас испортилось, а с другой стороны на то, что у нас скомпрометировалось.

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

Атака типа dos, когда злоумышленник делает так, чтобы наш сервис не работал.

Идея в том, что злоумышленник не имеет отношения к тем данным, которые портит.

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

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

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

Последние виды атаки, когда акующий получает доступ на чтени данных или вообще на модификацию

Если была возможность модификации, то под подозрением все подверженные данные, потому что вы не знаете, где и как установлена закладка.

Список для двух целей -- даже с точки зрения чисто технической соблюдение иформационной безопасности не является стройной теорией. Например объектом атаки может являться сам пользователь лично -- запудрить ему мозг и он сам все сделает. Типичный пример -- фишинг.

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

История, связанная с тем, как в сетевых протоколах вообще появлялось понятие об их безопасности

Когда делался уровень ноль, ни о какой защищенности сетевых протоколов речи даже не шло. telnet, rsh, pop, ftp.

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

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

• логин и пароль могут волновать некоторых людей.

Но университетская среда и дух кудесников в белых халатах не посзволил вовремя окститься.

В общем man dsniff , там несколько строк протоколов, которые передают учетные записи в открытом виде.

Потом до народа стало жоходить, что простейший тцпдамп показыавет логин-пароль.

Люди начинают изобретать доморощенные средства шифрования данных. htcp basic authoritahion -- security through obscurity -- наивные методы шифрования.

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

• трафик. Если отследили -- сможете.

Доступ по x11 с mit magic cookie. Куки не пересылается а кладется в специальный файл, а клиент дожен иметь к нему доступ и его предъявить серверу. Когда он его показывает из процесса показа можно выковырять

• куки. Да и вообще вопрос как он его получает.

На следующем этапе стали использовать теорию шифрования и встраивать соответствующие штуки в проотоколы прикладного уровня.

В основном это было шифрование паролем.

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

pop, smtp так устроены, что внезапно с процессе диалога клиент может скаать start tls и установить безопасное соединение.

Если встраивать шифрование на прикладном уровне, необходимо изменять прикладной протокол. Кроме того возникают подробности реализации, что надо обращаться к сторонним билиотекам.

С другой стороны если мы шифруем на уровне сокета, то мы теряем возможность модифицировать параметры шифрования в зависимости от свойств прикладного проотокола.

Типичная ситуация -- если пользоваться tls по https, то вы заходите а вам говрят -- сертификат плохой, на другое доменное имя. Будете пользоваться? Почему так? Когда устанавливается соединеие между

• отправителем и получателем, мы знаем только ип. Если два сайта на одном ип мы не можем обоим сделать валидный сертификат.

А вот если встроить тлс выше, то мы можем показывать сертификаты в зависимости от домена.

Диффи-Хеллман-Маркель

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

Ривест-Шамир-Адлеман

Monkey-in-the middle

Два замечания.

Типичный способ атаки -- сам процесс безупречен, но вы должны убедится в аутентичности открытых ключей.

Как это обеспечить? Подписать их. Правда, получается сказка про белого бычка. На этом можно сделать бизнес по внедрению своих клюбчей в разные продукты и потом продавть подписывание этими верифицированными ключами. Verisign и ко делают как раз это. На этом начал делать деньги Майкл Шаттлворт.

Инструменты, которые нам встречались.

telnet

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

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

Когда изобрели интернеты, то есть когда связаться через тцп ип стало удобней чем с помощью модема и компорта, задумались о перенесении всего этого в сеть. Основная потребность -- выполнять команды на удаленном компьютере. Первым был rsh. Он приводил к тому, что те команды, которые вы к нему складывали, он запускал на удаленной машине. Запуск посредством подключения по сети шелла на удаленной машине и передачу ввода-вывода с удаленной машины к вам. Атака Митника была осуществлена именно на рсх -- беспарольный, удаленный из пор рута.

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

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

Такой же механизм решили разработать и для подключений по интернету. Это был телнет.

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

По сравнению с рсх в протокол телнет ввели полезные для удаленной работы вещи как тип терминала. Это штука еще не окончательно канувшая в вечность, но сегодня достаточно экзотичная ситуация когда вы с этим сталкивались, но вте времена терминалы были экзотичными. Производители производили электронные печатные машинки и иногда изобретали совершенно удивительные вещи. Поэтому важно, чтобы когда вы подключаетесь удаленная машина знала тип вашего терминала. Даже клавиша перевода строки могла возвращать не тот символ, который у всех. Когда терминал подключен проводами, можно прописать в соотв строчке getty тип терминала на таком то компорте. А вот по телнету так сделать нельзя, поэтому происходил обмен информацией о некоторых переменных среды, например $TERM.

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

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

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

rsh

netcat

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

• netcat www.ru 80

И начать туда вводить команды GET и так далее.

Большинство старых протоколов FTP, HTTP, SMTP -- текстовые, и ими можно пользовтаься так.

Это подключени к порту в качестве клиента.

• netcat -l 12345

netcat может цепляться и к сокетам, работать по UDP.

Просто так взять иначать писать в сокет с помощью перенаправления ввода-вывода нельзя, а вот с помощью нетката -- можно.

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

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

-i -- задержка между отправляемыми строками

-w -- отключаться, если заданное время нет активности

Для большинства случаев когда вам нужно просто сделать что-то с сетью нетката вполне хватает.

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

stunnel

Неткат с сслем и разными возможностями делать над этим сслем извращения -- тот сертификат показать, этот показать этот, повесить демона.

Что еще может понадобится? Утилита для добычи информации из интернета

wget

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

curl

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

lftp

ftp на стероидах. Такой шелл. Есть работа с торрентами. Славен еще тем, что у него есть командочка pget -- параллельное скачивание.

tcpdump

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

Умеет превращать трафик, который подглядела в файл и прямо в этот файл записывать.

pcap пользуется и волшебная программа dsniff, которая вынимает логин и пароль из траффика, елси они вдруг там засветились.

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

Образ можно просто проимпортировать.

Что на сайте не написано. Как работает сеть в виртуалбоксе.

Вот у вас есть виртуальная машина. Она совершенно виртуальная. У неё внутри виртуальный сетевой интерфейс.

Запущенная виртуальная машина это программа. Внимание вопрос. Вот виртуальная машина, в ней есть сеть, она ходит интернет. Как обнаружить активность этой машины тцпдампом? Ответ -- вообще говоря никак, потому что по умолчанию весь сетевой трафик это просто активность этой программы.

Как можно еще? NAT. Чем метод NAT хорош -- вам вообще ничего не надо делать для настройки сети. Чем плох? Вы не сможете подсоединиться к этой машине, например, по ссх.

Как преодолеть? При настройке виртуальной машины есть проброс портов. Можно проборосить порт 2201 локалхоста на 22 порт виртуальной машины.

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

Сейчас в дз сеть устроена так -- в каждой машине по два интерфейса, один из которых нат, а другой внутренний. У сервера дефолт роут в интернет, а по второму интерфейсу он раздает дхцп клиенту. Клиент ходит дефолт роутом на сервер.

Шифрование, gpg, ssh

Разговор про гпг имеет достаточно косвенное отношние к сетям, но это довольно часто встречающийся механизм использования электронной подписи.

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

gpg -- gnu реализация pgp.

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

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

Надо понимать, что если есть эцп, то совершенно необязательно сообщение шифровать, это две разные задачи.

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

В случае эцп не так все страшно, елси речь идет о некритичных данных. Используете эцп для переписки. У вас большая группа абонентов, которые так делают. Почти наверняка случится так, что есть люди, в аутентичности ключей которых вы не убедились лично. Что делать?

1. таки добиваться, чтобы люди фингерпринт продиктовали
2. просить тех людей, относительно подписи которых вы уверены подписать этот ключ.

Поскольку речь идет не о сайтах, а о людях, ситуация намного менее печальна. После чего ключ и его подписи публикуются на специальных серверах. Уровень доверия 0 -- вы сами подписали. 1 -- подписал кто-то, кому подписали вы. И так далее.

ssh

10 минут. Почти соревнования моложых отцов по чтению сказок на ночь на скорость.

Как было сказано, телнетд не надо пользоваться вообще.

Пользоваться надо неткатом или ssh.

ссх -- защищенный терминальный сервис. Основная, но не единственная функция которого -- предоставить вам защищенный санс удаленной работы.

Логин пароль, получение шелла, работа, разлогинивание.

Как это устроено?

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

Первое, что встречается на вашем пути -- host key -- ключ машины. Он для каждого запущенного ссхд свой и предназанчен чтобы устанавливать зашифрованное соединение и гарантировать пользователю, что нет атаки человек посередине. При этом первонаальный обмен ключами должен как-то произойти. Подклюаясь, вы получаете некоторый фингерпринт. Вам говорится -- узнаете? вы смотрите и говорите "агааа, узнаю". По большей части из соображений неуловимого джо на проверку все забивабют, но это неправильно.

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

Ключ, правда, тоже надо защищать паролем. Хорошим. Но зато этот пароль один.

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

Проблема -- рут на удаленной машине может ходить вашими ключами.

Есть инструмент ask pass. Если он включен, то каждый акт авторизации и подключения будет выбрасывать оповещательое полотенце с информацией кто куда хочет подключаться и спрашивать "давать или не давать".

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

Еще один выход -- шифрование на отдельной железке.

Еще одна важная функция ссх -- при подключении между клиентом и сервером образуется защищенный тунель. Хотелось бы егокак-то еще утилизировать кроме того тчобы шелл гонять. Что приходит в голову? Запустить неткат с обоих сторон. Делать так не надо, потому что у ссх есть ключики -l и -r -- проброс оттуда сюда и отсюда туда соответственно.

Забанили у вас вконтактик -- а вы говорите -- пробросьте мне 80 на 443

Обратная ситуация -- зафаерволили вас. А вам хочется по ссх ходить. Пишите ssh -r порт на удаленной машине:порт srv

Не забыть сказать port gateway enable sshd.

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

Интерфейсный уровень

мало

Сетевой уровень

Там много интересов сос тороны администратора и разных людей. Развесистая маршрутизация, перенаправление трафика. Или банальная фильрация клиентов по их ип-адресам. Блокировка ботов, подбирающих пароли.

Транспортный уровень

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

Прикладной уровень

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

Как это вообще устроено?

Есть операционная система, в ней есть ядро.

Пакет обрабатывается ип-стеком, и в некоторых местах отдается файерволлу. файервол его пержеёвывает и отдает, или не отдает, или отдает измененный.

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

Русский термин -- межсетевой экран. Файерволл же это перевод слова брэндмауэр.

В лекциях по сетям на факультете все еще любят слово брэндмауэр. Лектор предпочитает термин межсетевой экран.

Собственно межсетевой экран это особая организация ядра.

iptables

Особенности реализации файерволла в линуксе:

• есть ядерная часть и пользовательская утилита
• читая документацию по iptables, можно прочитать следующее: такой то фильтр опеределяет наличие такого то поля. Если он есть, вы можете задать реакцию. Если внимательно посмотреть на описания, то можно
• увидеть, что речь идет о пакетах разных уровней. Чтобы не заморачивать пользователю гоолову информацией о том, на каком уровне происходит взаимодействие. То, на каком уровне он будет обрабатываться
• определяется теми условиями, которые для него прописаны. Если бы смешения не было, было бы хуже.
• описание логики выглядит как список правил "условие-действие". Правила просматриваются начиная с первого, и как только условие подходит, выполняется действие. Если правил несколько, то применяется то правило, чьё условие оказалось первым в списке попадающих. first wins. Бывают еще файерволлы организованные по принципу last wins.
• правила объединены в цепочки, и этих цепочек несколько. Для каждой есть действия по умолчанию, которое происходит, если не одно правило не применилось. Имеется комманда перехода на другую цепочку. Есть фиктивные цепочки вида -j nat или -j drop, которые означают указание произвести над пакетом соответствующей действие.
• цепочки бывают разных типов. Предположим у вас всего 50 правил, по 5 штук в каждой цепочке. Разобраться что делают 50 правил в файерволле, если у них нет структуры, надо обладать жесткой фантазией. Поэтому
  • авторы ввели два структурирующих начала:
  • типы цепочек и типы правил. тип правила должен соответствовать типу цепочки.
  • традиционно, когда вы ассматриваете спислок правил они группируются по типам. Понять из этого как происходит обход пакета невозможно. Есть три пути следования пакета:
    • когда пакет предназначен для вас
    • пакет порожден приложением на вашей машине
    • пакет перекладывается из одного интерфейса в другой.
    Это три разных пути пакета. Пакет пришел из интернета. Он попадает к правилам из таблицы route, находящимся в цепочке prerouting. В ней есть правила трех типов -- для помечания пакетов (route), mangle - преобразование пакета и nat преобразоваие для сетевой транслции адресов. Когда пакет поизвращали и поменяли надо проверить надо ли его отдавать приложению. Если пакет наш, он отдается приложению. Если маршрутизация решила, что его надо передать дальше, то вступает в силу цепочка forward, в которой опять есть правила типов mangle и filter. После того как пакет пожевали, можно опять посмотреть, не переменилось ли решение о маршрутизации. Отправляем на второй этап маршрутизации. После этого попадаем в цепочку postrouting, в которой есть тоже две таблички mangle и nat. Если решение о том, куда отсылается пакет, его можно уже только слегка пощелкать, и если там настоящий нат, то закончить трансляцию. Если пакт порожден приложением он попадает в цепоку output, в которой аж четыре вида правил -- route, mangle, nat, filter. Пакет породился, навешиваем ему метку. Потом жуем его. Потом делаем нат на порождение. Тем не менее обратите внимание на то, что подобным образом структурированный граф решает практически все задачи.

Утилита для обработки iptables называется iptables.

Что с ее помощью можно сделать?

По умолчанию она работает над цепочками.

• -a -- добавить цепочка -r -- заменить цепочка -i -- вставить цепочка -d номер правила цепочка

iptables save которая выдает список всех правил вашего файервола. iptables restore -- загрузить обратно.

contrack

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

helper

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

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

recent

кэшировать и откладывать недавно произошедшие события. "если человек ндавно заходил вот по таки двум портам, то дать ему доступ по 22 порту". Способ организации простого порт кнокинг.

Не рассказали про шейпинг. Поверьте, он есть.

Решение домашних задания для сдачи экзамена

Внимание! Примеры на лекциях чаще всего рассчитаны на работу с правами суперпользователя (входное имя root, пароль root). Это плохой, негодный пароль, не надо в боевой системе использовать такие. Примеры хороших, годных паролей см. в выдаче команд pwqgen и pwgen.

Если вы не большой знаток Linux, редактировать конфигурационные файлы можно с помощью команды mcedit /путь/до/файла. Если вы знакомы с двухпанельными файловыми менеджерами типа «синенькое» (Far Manager, Total Commander и т. п.), можете воспользоваться mc. Символ # в начале строки конфигурационного файла начинает комментарий.

Обе машины — и «сервер», и «клиент» — имеют по два сетевых интерфейса, из которых один смотрит в «интернет» 10.0.2.0/24 (что это за интернет — об этом после), а второй — в невидимую ниоткуда, кроме виртуальных машин, внутреннюю сеть virtualbox 10.30.50.0/24 (очень удобно: внутренних сетей можно наделать сколько хочешь и моделировать любую топологию сети). Различаются только настройки: сервер по умолчанию ходит в интернет через интерфейс с интернетом, а клиент — через внутреннюю сеть посредством сервера.

Сам virtualbox может раздавать сетевые настройки при помощи DHCP, но этим пользуется только сервер (для «интенрентого» интерфейса). Внутренний интерфейс 10.30.50.1/24 в сервере настроен вручную, и по внутренней сети уже сам сервер раздаёт DHCP, а клиент — получает. Адрес 10.0.2.10/24 на «интернетном» интерфейсе клиент настраивает вручную.

Разумеется, при такой конфигурации клиент тоже может работать маршрутизатором для сервера!

Если в примере встречаются команды и клиента, и сервера, я включаю в него приглашение командной строки с именем машины.

Внимание пользователям Windows!. Проверьте настройки межсетевого экрана Windows для VirtualBox: есть сведения, что настройки по умолчанию режут некоторые протоколы (например, не работает traceroute).

Копипаста

Домашнее задание получится значительно быстрее, если работать не в консолях виртуальных машин, а подключаться к ним по SSH (как это было продемонстрировано на демо-лекции). 22-й порт «сервера» отображается на 2210-й порт хост-машины, а 22-й порт «клиента» — на 2211-й. подключение из командной строки:

$ ssh root@localhost -p 2210

лучше работы в консоли тем, что команды можно копировать с этой страницы и вставлять терминальное в окно.

Пользователи VirtualBox под Windows могут воспользоваться PuTTY

Как заполнять журнал

Журнал заполняется сам. Но в некоторых случаях (когда в домашнем задании задаётся вопрос)нужно кое-что предпринять.

• На вопросы вида «что находится в файле таком-то?» отвечать запуском команды cat файл такой-то.

• На вопросы вида «найти», помеченные как , отвечать таким образом, чтобы из ваших действий следовало, что вы действительно что-то нашли :).

  • Как минимум, стоит выполнить команду вида "# otwet na wopros" (с точки зрения командной строки это — комментарий, а в журнал запишется, см. первую команду примера ниже).

  • Более крутой способ — это использовать конструкцию вида: "получить_текстовую_информацию | grep шаблон". Пример: вопрос «как называется служба NFS?» и два варианта ответа:

    [root@uneex ~]# # C.O.: nfs daemon is called "nfs" :)
    [root@uneex ~]# chkconfig --list | grep nfs
    nfs             0:off   1:off   2:off   3:on    4:on    5:on    6:off
    nfslock         0:off   1:off   2:on    3:on    4:on    5:on    6:off

    • Точного соответствия не требуется, даже шаблон не обязан содержать ничего разумного: идея в том, чтобы с помощью grep уменьшить выдачу до небольшого объёма, в котором присутствует ответ.

• На вопросы вида «что делает команда такая-то?» — как минимум, запускать эту команду, а ещё можно демонстративно запускать man команда такая-то (дескать, почитал руководство и теперь всё понял ).

• Задания, помеченные , делать не обязательно (хотя и интересно).

Журнал ведётся для каждого сеанса работы в shell, поэтому включать и выключать виртуалку можно сколько угодно раз. Но не забывайте:

• выходить из всех сеансов перед выключением компьютера
• выключать компьютер с помощью "shutdown -h -P now" (для этого надо снова специально один раз залогиниться)

Какие получать оценки

3. Вы (как-то) сделали больше половины Д/З и у вас получилось отослать мне журнал.
4. Вы честно делали («а я учил…»™) все пункты Д/З, но некоторые (не более 1/4) у вас не получились, и вы не понимаете, почему. А времени понять у вас нет (иначе см. примечание к следующему пункту).

5. Вы успешно сделали все пункты Д/З (+/- 2 элемента списка), за исключением, быть может, тех, что не получились не по вашей вине (см. неудачу с whois на демолекции)

   • Если у вас что-то тупо не выходит, всегда можно спросить у меня (FrBrGeorge).

   • Д/З не обязательно делать в один присест или сразу успешно. Возможен итеративный подход, только сообщайте мне, что именно не сделали или доделали.

Неподписанные, фальсифицированные и решённые менее, чем наполовину журналы не принимаются.

Выставленные оценки

Как отсылать журнал

1. Убедитесь, что всё домашнее задание, которое вы хотели сделать, сделано.
2. Убедитесь, что обе виртуалки запущены.

3. Убедитесь, что адрес второй виртуалки (клиента) действительно 10.30.50.7.

   • Если это не так, то, скорее всего, при импорте виртуалки ей сгенерировали новые MAC-адреса сетевых карточек. Посмотрите MAC-адрес интерфейса enp0s8 на клиенте и поменяйте на сервере в файле /etc/dhcp/dhcpd.conf поле hardware ethernet на этот MAC-адрес. Затем надо сделать service network restart на клиенте. Добейтесь правильного IP-адреса.

4. Если вы не собираетесь подписывать журнал собственным настоящим ключом, убедитесь, что вы проделали домашнее задание по gpg:

   • [root@uneex ~]# gpg --fingerprint 'Joe Tester (with stupid passphrase) <joe@foo.bar>'
     /root/.gnupg/pubring.gpg
     ------------------------
     pub   1024D/00000000 2013-12-22
           Key fingerprint = 0000 0000 0000 0000 0000  0000 0000 0000 0000 0000
     uid                  Joe Tester (with stupid passphrase) <joe@foo.bar>

     Запишите полученный fingerprint (а не эти нули), он вам понадобится.

5. Выполните команду report какое-нибудь-имя на сервере:

   • [root@uneex ~]# report sarumanthewhitenoise
     Gathering info
     Reporting server
     Reporting client
     Merging reports
     Signing report
     Publishing report
     sarumanthewhitenoise-1387714551-uneex.tar.xz.gpg      100%   67KB  66.7KB/s   00:00    

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

6. Напишите мне (см. FrBrGeorge) письмо, упомянув:

   1. ФИО, курс

   2. Какие задания не сделали

   3. имя файла (из выдачи report)

      • копипасту выдачи report, если в ней содержатся ещё какие-то сообщения

   4. finergprint ключа из выдачи gpg --fingerprint

      • Опционально вы можете вытащить файл /tmp/sarumanthewhitenoise-1387714551-uneex.tar.xz (или как он там будет называться), подписать его собственным ключом (настоящим) и прислать подписанный файл и открытый ключ почтой. Вытащить файл можно, например, так:

        • $ scp -P2210 root@localhost:/tmp/sarumanthewhitenoise-1387714551-uneex.tar.xz .

          или с помощью WinSCP в случае Windows.

Домашнее задание

Оценки домашних заданий по курсу «Сетевые протоколы в Linux»