Транспортный уровень: трансляция адресов

Долги за прошлую лекцию

(Пропала примерно половина прошлой лекции, но, возможно, всё равно надо оставить две темы)

Другие варианты транспорта?

А ещё?

• DCCP

  • Порядок / поток нужен
  • Цельность желательна, но не полученные вовремя пакеты уже не важны (напр., видео или синхронизация игровых вселенных)
  • (also, DCCP+UDP для очень старых сетевых устройств)

• SCTP:

  • Несколько потоков в одном сеансе (порядок потоков не важен)

  • двусторонняя готовность к сеансу (4-way handshake вместо 3-way — для отсечения syn flood)
  • multihoming (наконец-то из ID транспортного уровня открутили IP: абоненты рассказывают все свои адреса, а ID служит т. н. «association» и порт)

• ECN

  • Дешёвая (не порождающая паразитного трафика) / управляемая / прогнозируемая защита от забивания канала

• RSVP (IPv6)

  • Резервирование объёмов / пропускной способности / других свойств на всём маршруте
• …

Netcat и Socat

• Netcat — приём-передача данных по сети на стандартный В/В

  • Установление TCP-подключения / Однократный приём подключения на TCP-порту
  • Установление и приём UDP-«подключения»
    • Проблема «окончания сеанса» (нет никакого сеанса, просто поток датаграмм, так что убивать руками)
  • немножко умеет в Unix Domin сокеты (сокеты в файловой системе)

• Socat — приём-передача данных по сети самыми разнообразными способами

  • руководство, есть статьи попроще ☺

  • Полезный текст про UDP (отсюда)

  • Главное — не бояться ☺

NAT

Network address translation — что такое и зачем нужно.

NAT без транспортного уровня

Идея замены конкретного IP другим конкретным IP (и обратно) — например, если «внутренний» IP из интернет-диапазона.

Это всё уже не работает, потому что не нужно

Табличная подмена IP

• Работает только 1:1
• Actuallyy, не работает

NAT с идентификацией потока

Динамическая подмена IP на основании «состояния»

• Таблица: пара IP + идентификатор «состояния»

  • в документации

  • Кстати, документация по сетевым sysctl

• Может работать N:1, M:N
• Destination NAT (например, для отдельного веб-сервера)
• Идентификаторы — всё, что можно извлечь из пакетов
  • TCP: 2 порта + 2 IP (+ initial SeqN?)
  • DNS (UDP): DNS Query ID (поле прикладного уровня!) + 2 порта + 2 IP
  • NTP (UDP): Originator Timestamp (поле прикладного уровня!) + 2 порта + 2 IP
  • ping: ICMP-serial (поле сетевого уровня) + IP
  • …
• Проблема коллизий SEQN / портов / идентификаторов в вариантах N/1 и M/N:
  • Два хоста (A и B идут на один и тот же порт хоста C через NAT):
  • У них могут совпасть порты отправителя:
    • A:1234 → C:80; B:1234 → C:80

    • => коллизия

  • Оок, введём в идентификатор ещё seqn:
    • A:1234, seqn 4321 → C:80; B:1234, seqn 34234 → C:80

    • => вероятность коллизии?

Примеры SNAT и DNAT

• SNAT — при отсылке «наружу» (например, из intranet-диапазона)

  • Кстати, MASQUERADE — это на случай динамического IP, при формировании conntrack-а всякий IP раз запрашивается у интерфейса

• DNAT — при приёме (например, межсетевой экран на одной машине, а веб-сервер — внутри сети, на другой)

  • Т. н. «проброс портов»

Syn flood атака и SYNPROXY

• Суть: на каждый SYN в ядре выделяется приличная структурка. Можно заDOS-ить большин потоком безответственных SYN-ов.
• Решение: разделить МЭ и сервер, и до сервера доносить только «хорошие» SYN-ы, точнее — SYN-SYNACK-ACK-и всей пачкой (частичное проксирование)
  • Требует более сложной логики
  • Требует подмены SEQN (потому что мы всё ещё не знаем, какую SEQN выберет сервер, но уже «проиграли» для него 3WH)

Д/З

TODO