Транспортный уровень: трансляция адресов
Долги за прошлую лекцию
(Пропала примерно половина прошлой лекции, но, возможно, всё равно надо оставить две темы)
Другие варианты транспорта?
TCP |
vs |
UDP |
есть |
подключение |
нет |
есть |
подтверждения |
нет |
есть |
отслеживание цельности потока |
нет |
есть |
отслеживание качества потока |
нет |
несколько |
количество пакетов |
один |
А ещё?
- Порядок / поток нужен
- Цельность желательна, но не полученные вовремя пакеты уже не важны (напр., видео или синхронизация игровых вселенных)
- (also, DCCP+UDP для очень старых сетевых устройств)
SCTP:
Несколько потоков в одном сеансе (порядок потоков не важен)
- двусторонняя готовность к сеансу (4-way handshake вместо 3-way — для отсечения syn flood)
- multihoming (наконец-то из ID транспортного уровня открутили IP: абоненты рассказывают все свои адреса, а ID служит т. н. «association» и порт)
- Дешёвая (не порождающая паразитного трафика) / управляемая / прогнозируемая защита от забивания канала
RSVP (IPv6)
- Резервирование объёмов / пропускной способности / других свойств на всём маршруте
- …
Netcat и Socat
Netcat — приём-передача данных по сети на стандартный В/В
- Установление TCP-подключения / Однократный приём подключения на TCP-порту
- Установление и приём UDP-«подключения»
- Проблема «окончания сеанса» (нет никакого сеанса, просто поток датаграмм, так что убивать руками)
- немножко умеет в Unix Domin сокеты (сокеты в файловой системе)
Socat — приём-передача данных по сети самыми разнообразными способами
руководство, есть статьи попроще ☺
- Главное — не бояться ☺
NAT
Network address translation — что такое и зачем нужно.
NAT без транспортного уровня
Идея замены конкретного IP другим конкретным IP (и обратно) — например, если «внутренний» IP из интернет-диапазона.
Это всё уже не работает, потому что не нужно
- Работает только 1:1
- Actuallyy, не работает
NAT с идентификацией потока
Динамическая подмена IP на основании «состояния»
- Таблица: пара IP + идентификатор «состояния»
- Может работать 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