Как работают IPv4-прокси в сетях с NAT64: технические ограничения и кейсы применения

NAT64 и IPv4-прокси: странная парочка

NAT64 — технология-переходник. Позволяет IPv6-клиентам стучаться в IPv4-мир. Прокси поверх этого — отдельный цирк с конями.

Механизм простой: DNS64 синтезирует AAAA-записи из A-записей. Клиент шлёт пакет на IPv6-адрес, шлюз NAT64 выкусывает IPv4-адрес из суффикса, делает трансляцию. IPv4-прокси внутри такой сети — дополнительный слой абстракции.

Если ты втыкаешь обычный HTTP/HTTPS-прокси в сеть с NAT64 — работает. Но с сюрпризами. Особенно когда прокси требует прямой IPv4-связности. Или когда приложение не умеет работать с прокси, а только с сокетами.

Как это выглядит на практике

Возьмём типовую схему: провайдер выдал только IPv6. На CPE стоит NAT64-шлюз. Внутри сети — IPv6-клиенты.

Клиент шлёт запрос к `proxy.example.com`. DNS64 возвращает IPv6-адрес. Пакет летит к NAT64-шлюзу. Тот транслирует в IPv4 и шлёт на реальный прокси.

Прокси получает запрос, видит IPv4-адрес NAT64-шлюза. Отвечает обратно. NAT64 транслирует обратно в IPv6.

Всё работает. Пока не упрёшься в ограничения.

Главные грабли

**MTU и фрагментация**. NAT64 режет пакеты. Прокси-трафик часто летает с MSS выше 1280 байт. Если на пути стоит NAT64 без PMTUD — получаешь чёрные дыры.

Проверяется просто:

```bash

ping -M do -s 1472 proxy.example.com

```

Если не отвечает — MTU-проблема.

**TCP keepalive**. NAT64-шлюзы имеют таймауты на трансляцию. Обычно 5-10 минут. Если прокси держит соединение дольше — NAT64 забывает о нём. Пакеты летят вникуда.

Решение — настраивать keepalive на клиенте:

```bash

echo 60 > /proc/sys/net/ipv4/tcp_keepalive_time

```

**UDP-трафик**. DNS через прокси — отдельная боль. NAT64 не дружит с UDP-фрагментацией. Если DNS-ответ больше 1232 байт — всё, труба.

Реальные кейсы: когда без прокси никак

**Кейс: старый софт, который умеет только IPv4**

Бывает legacy-приложение. Писано под IPv4. Требует прямого доступа к IPv4-ресурсам. NAT64 его спасает не всегда — приложение может использовать raw-сокеты или специфичные протоколы.

Тут прокси — палочка-выручалочка. Ставишь HTTP-прокси на NAT64-шлюзе. Приложение шлёт запросы через прокси. Прокси уже сам ходит в IPv4-мир.

```python

import requests

proxies = {

'http': 'http://192.0.2.1:3128',

'https': 'http://192.0.2.1:3128'

}

response = requests.get('http://ipv4.example.com', proxies=proxies)

print(response.text)

```

**Кейс: обход блокировок по протоколу**

Некоторые NAT64-шлюзы режут трафик по портам. Например, блокируют 25-й порт (SMTP). Прокси на другом порту решает проблему.

**Кейс: тестирование IPv6-приложений**

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

Технические ограничения: цифры и факты

Параметр | NAT64 без прокси | NAT64 + прокси

---------|------------------|----------------

MTU | 1280 байт (минимальный) | 1500 байт (если прокси не режет)

Задержка | +1-3 мс | +5-15 мс (из-за дополнительной обработки)

Количество одновременных соединений | Ограничено ресурсами шлюза | Ограничено прокси (обычно выше)

Поддержка UDP | Частичная | Полная (если прокси умеет)

Прозрачность для приложений | Высокая | Средняя (нужна настройка прокси)

Задержка на NAT64-шлюзе — это не шутки. Каждый пакет проходит трансляцию. Плюс прокси добавляет свою обработку. Итого на ровном месте теряешь 10-20 мс.

Как выбрать прокси для NAT64-сети

**Требования к прокси-серверу:**

1. Поддержка IPv6 на входящем интерфейсе. Прокси должен принимать соединения по IPv6.

2. Поддержка IPv4 на исходящем интерфейсе. Иначе смысл теряется.

3. Настройка MTU. Прокси должен уметь фрагментировать пакеты для NAT64.

4. Логирование. Без него не отследишь проблемы с трансляцией.

**Настройка Squid для NAT64:**

```bash

http_port 3128

acl localnet src ::1/128

acl localnet src fe80::/10

http_access allow localnet

forwarded_for on

```

**Настройка 3proxy:**

```bash

proxy -p3128 -6 -n -a

```

Флаг `-6` включает IPv6 на входящем интерфейсе. `-n` — не транслировать адреса.

Когда прокси ломает NAT64

Бывают ситуации, когда прокси только мешает.

**Double NAT**. Прокси делает свою трансляцию. NAT64 — свою. Получается двойная трансляция. Пакеты теряются на ровном месте.

**Проблемы с SNI**. HTTPS-прокси может не передавать SNI. NAT64 без SNI не понимает, куда форвардить запрос.

**TCP RST**. Прокси может слать RST при ошибках. NAT64 это не всегда корректно обрабатывает.

Решение проблем: конкретные шаги

**Проблема: пакеты не доходят**

Проверяем MTU:

```bash

ping -M do -s 1452 -c 5 2001:db8::1

```

Если не пингуется — снижаем MTU на интерфейсе:

```bash

ip link set dev eth0 mtu 1280

```

**Проблема: медленные соединения**

Смотрим логи NAT64:

```bash

tcpdump -i nat64_iface -n port 3128

```

Ищем пакеты с флагом `[S.]` без ответа — это потерянные SYN.

**Проблема: DNS не резолвится**

Проверяем, что DNS64 работает:

```bash

dig AAAA proxy.example.com @dns64_server

```

Если ответ пустой — DNS64 не синтезирует записи. Меняем DNS-сервер.

Практический пример: поднимаем всё вместе

Ставим NAT64 на Linux:

```bash

apt install tayga

```

Конфиг `/etc/tayga/tayga.conf`:

```

tun-device nat64

ipv4-addr 192.168.255.1

prefix 64:ff9b::/96

dynamic-pool 192.168.255.0/24

data-dir /var/spool/tayga

```

Поднимаем:

```bash

tayga --mktun

ip link set nat64 up

ip addr add 192.168.255.1/24 dev nat64

ip route add 64:ff9b::/96 dev nat64

```

Ставим 3proxy:

```bash

apt install 3proxy

```

Конфиг `/etc/3proxy/3proxy.cfg`:

```

nscache 65536

nserver 8.8.8.8

nserver 8.8.4.4

config /etc/3proxy/3proxy.cfg

monitor /etc/3proxy/3proxy.cfg

log /var/log/3proxy.log D

logformat "- +_L%L.%d %H:%M:%S %N.%p %E %U %C:%c %R:%r %O %I %h %T"

rotate 30

auth none

allow * * * * 80-88,8080-8088 * * * *

proxy -p3128 -6 -n -a

```

Запускаем:

```bash

systemctl start 3proxy

```

Теперь клиенты с IPv6 могут ходить через прокси на 3128 порту. Прокси сам форвардит запросы в IPv4-мир через NAT64.

Итоги: стоит ли овчинка выделки

NAT64 + IPv4-прокси — рабочая схема. Но не панацея.

Если у тебя чистый IPv6 и нужно достучаться до IPv4-ресурсов — ставь прокси. Если приложение не умеет работать с прокси — используй NAT64 напрямую.

Главное — не забывай про MTU, keepalive и таймауты NAT64. Иначе будешь долго искать, почему соединения рвутся.

На lexic.ml уже 9 лет решают такие задачи. IPv4-прокси в IPv6-сетях — их хлеб. Если не хочешь возиться с настройкой NAT64 — бери готовое решение.

Помни: любая трансляция — компромисс. NAT64 жрёт производительность. Прокси добавляет сложность. Но иногда это единственный способ заставить старый софт работать в новой сети.