Как использовать все 253 резидентных IP на одном сервере: привязка блока, исходящий IP для каждого сервиса и план распределения

Чтобы задействовать все 253 резидентных IP на одном сервере, привяжите весь /24 к сетевому интерфейсу, а затем укажите каждому сервису его исходящий адрес — через Nginx proxy_bind/listen, curl --interface, source_address в Python, SNAT или policy routing по пользователю либо отдельные сети для контейнеров Docker — и ведите таблицу распределения, чтобы у каждого IP был один владелец и одна задача. Ниже — пошаговая инструкция на примере IMIDC Native Residential IP Server: /24 из 253 нативных IPv4 домашнего широкополосного доступа и root-доступ от $2,188/мес.

Шаг 1. Привяжите /24 к интерфейсу

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

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

# 1) Check what is already configured (interface name may be eth0, ens3, enp1s0...)
ip -4 addr show dev eth0
ip route show default          # expect: default via 203.0.113.1 dev eth0

# 2) Add the rest of the block at runtime (lost on reboot - good for a first test)
for i in $(seq 3 254); do
  ip addr add 203.0.113.$i/24 dev eth0
done

# 3) Count: should print 253 (203.0.113.2 - 203.0.113.254)
ip -4 addr show dev eth0 | grep -c 'inet 203\.0\.113\.'

В Ubuntu и других системах с netplan сделайте настройку постоянной. Применяйте её через netplan try: при ошибке конфигурация откатится сама, и вы не потеряете доступ.

# /etc/netplan/50-cloud-init.yaml (excerpt) - keep your existing gateway/DNS lines
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 203.0.113.2/24
        - 203.0.113.3/24
        # ... one line per address ...
        - 203.0.113.254/24
      routes:
        - to: default
          via: 203.0.113.1

# Generate the 253 address lines instead of typing them:
for i in $(seq 2 254); do echo "        - 203.0.113.$i/24"; done

# Apply with automatic rollback if you lose SSH:
netplan try

В старых Debian/CentOS то же делается через /etc/network/interfaces или NetworkManager (nmcli con mod eth0 +ipv4.addresses 203.0.113.3/24). Один раз перезагрузитесь в окно обслуживания и убедитесь, что все 253 адреса поднимаются.

Шаг 2. Определите, что и на каком IP слушает

Когда привязаны 253 адреса, любой сервис на 0.0.0.0 доступен на всех них, поэтому привязывайте сервисы явно.

• SSH и панели управления — только на основном IP.
• В Nginx пишите listen 203.0.113.20:443, а не listen 443.
• Входящий трафик на неиспользуемые IP отбрасывайте файрволом.

# /etc/ssh/sshd_config - management only on the primary IP
ListenAddress 203.0.113.2

Шаг 3. Проверьте исходящий трафик и геолокацию каждого IP

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

# Each IP should report itself as the source address
for i in 2 20 50 200; do
  printf '203.0.113.%s -> ' "$i"
  curl -s --max-time 10 --interface 203.0.113.$i https://ip.example.com; echo
done

Замените ip.example.com на любой сервис «какой у меня IP», которому вы доверяете. Проверьте адреса и в базах геолокации, которыми, вероятно, пользуются ваши целевые платформы, и запишите отображаемое имя провайдера. IMIDC выдаёт IP, зарегистрированные на местного провайдера, но ни один хостер не может гарантировать, как сторонняя база или платформа классифицирует каждый адрес, поэтому фиксируйте фактический результат.

Шаг 4. Выберите исходящий IP для каждого сервиса

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

Nginx: входящий трафик по IP, исходящий — по сайту

# Inbound: each storefront answers only on its own residential IP
server {
    listen 203.0.113.20:443 ssl;
    server_name shop-tw.example.com;
    # ssl_certificate ... ;
}

# Outbound: pick the source IP for upstream requests per site
map $host $egress_ip {
    default                203.0.113.21;
    shop-tw.example.com    203.0.113.21;
    brand-b.example.com    203.0.113.22;
}

server {
    listen 203.0.113.22:443 ssl;
    server_name brand-b.example.com;

    location /api/ {
        proxy_pass https://partner-api.example.com;
        proxy_bind $egress_ip;
    }
}

curl и Python

# Shell / cron jobs
curl --interface 203.0.113.40 -s https://example.com/health

# Python standard library
import http.client
conn = http.client.HTTPSConnection("example.com", timeout=10,
                                   source_address=("203.0.113.41", 0))
conn.request("GET", "/")
print(conn.getresponse().status)

# httpx
import httpx
transport = httpx.HTTPTransport(local_address="203.0.113.42")
with httpx.Client(transport=transport, timeout=10) as client:
    print(client.get("https://example.com/").status_code)

# requests (pip install requests-toolbelt)
import requests
from requests_toolbelt.adapters.source import SourceAddressAdapter
s = requests.Session()
s.mount("https://", SourceAddressAdapter("203.0.113.43"))
print(s.get("https://example.com/").status_code)

SNAT и policy routing по пользователю

Создайте по одному пользователю Linux на сотрудника или задачу и закрепите за ним один IP: пока вы не измените правило, всё, что он запускает, уходит только с этого адреса.

# One Linux user per team member or job, each pinned to one IP
useradd -m tw_ops01
iptables -t nat -A POSTROUTING -o eth0 -m owner --uid-owner tw_ops01 \
  -j SNAT --to-source 203.0.113.50

# nftables equivalent
nft add rule ip nat postrouting oifname "eth0" meta skuid "tw_ops01" snat to 203.0.113.50

# Persist iptables rules (Debian/Ubuntu)
apt install -y iptables-persistent && netfilter-persistent save

# Alternative: policy routing by UID - sets the default source address
# for anything that user runs without an explicit bind
ip route add default via 203.0.113.1 dev eth0 src 203.0.113.60 table 160
ip rule add uidrange 1060-1060 lookup 160 priority 1060

# Check which source the kernel picks for that user
ip route get 198.51.100.10 uid 1060

Контейнеры Docker

Вариант A оставляет контейнеры в приватном bridge и переписывает их трафик на один резидентный IP; вариант B выдаёт резидентные IP контейнерам напрямую.

# A) Bridge network per IP, with your own SNAT rule
docker network create --subnet 172.30.70.0/24 \
  -o com.docker.network.bridge.enable_ip_masquerade=false net_ip70
iptables -t nat -A POSTROUTING -s 172.30.70.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.70
docker run -d --name app70 --network net_ip70 my-app:latest

# B) ipvlan L2: containers own residential IPs directly (shares the host MAC)
#    Do NOT also bind these addresses on the host.
docker network create -d ipvlan -o parent=eth0 -o ipvlan_mode=l2 \
  --subnet 203.0.113.0/24 --gateway 203.0.113.1 \
  --ip-range 203.0.113.192/27 res_ipvlan
docker run -d --name web200 --network res_ipvlan --ip 203.0.113.200 nginx

ipvlan L2 использует MAC-адрес хоста, что вышестоящие коммутаторы обычно принимают; macvlan создаёт новый MAC для каждого контейнера, а на некоторых портах дата-центров это ограничено, поэтому перед использованием macvlan уточните у поддержки IMIDC. В свежих версиях Docker есть и опция bridge для адреса SNAT — смотрите документацию своей версии.

Шаг 5. Распределите IP между сотрудниками и приложениями

Разбейте блок на диапазоны по назначению, чтобы по адресу сразу было понятно, для чего он.

Соблюдайте правило «один IP — один владелец». Если каждый день перекидывать IP между несвязанными задачами, теряется главное преимущество стабильного эксклюзивного блока.

Шаг 6. Задокументируйте таблицу распределения

Относитесь к плану IP как к коду: файл под контролем версий — единственный источник правды о том, кто что использует.

# ip-allocation.csv  (keep in git; review monthly)
ip,owner,purpose,method,since,notes
203.0.113.2,infra,server primary / SSH only,host,2026-10-01,never used for business traffic
203.0.113.20,web,shop-tw.example.com inbound,nginx listen,2026-10-02,
203.0.113.50,tw_ops01,store back-office,iptables SNAT uid,2026-10-03,
203.0.113.70,app70,price-check API (own SKUs),docker SNAT,2026-10-05,
203.0.113.241,-,quarantine,-,2026-10-09,removed from rotation after 403 spike

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

Шаг 7. Следите за репутацией и использованием

Проверяйте каждый IP по расписанию и быстро реагируйте, когда на нём появляются ошибки или попадание в списки.

#!/bin/sh
# Daily DNSBL check for the whole block (use your own recursive resolver;
# some blocklists refuse queries from large public resolvers)
for i in $(seq 2 254); do
  ip=203.0.113.$i
  rev=$(echo "$ip" | awk -F. '{print $4"."$3"."$2"."$1}')
  for bl in zen.spamhaus.org bl.spamcop.net; do
    host -W 2 "$rev.$bl" >/dev/null 2>&1 && echo "$(date +%F) $ip listed on $bl"
  done
done

# Open connections per source IP (spot a runaway job)
ss -Htn state established | awk '{print $3}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

• Отслеживайте долю HTTP 403/429 и частоту CAPTCHA по исходящему IP в логах приложений.
• Переносите проблемный IP в карантин, находите причину и только потом используйте снова.
• Держите частоту запросов на «человеческом» уровне и соблюдайте правила платформ; IMIDC не обещает, что какой-либо IP не будет ограничен, а описанные приёмы нельзя применять для обхода антифрода или KYC.
• Не отправляйте почту с этих IP, пока не уточните у поддержки политику по исходящему порту 25.

Какая конфигурация IMIDC подойдёт

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

• Один рынок, до 253 стабильных сетевых идентичностей для своей команды и приложений: Native Residential IP Server в Тайбэе, Куала-Лумпуре, Токио, Сеуле, Йоханнесбурге или Бангкоке.
• Много браузеров или краулеров для своих сайтов: используйте резидентный сервер как слой выхода и добавьте отдельные вычислительные ресурсы IMIDC либо запросите индивидуальную конфигурацию.
• Меньше IP или другие типы адресов: смотрите статические резидентные, ISP- и дата-центровые IP на странице IP-ресурсов или запросите нужное число IP через отдел продаж.

Частые вопросы

Как заставить Linux отправлять трафик с конкретного IP из моего /24?

Привяжите адрес к интерфейсу и задайте источник для сервиса: proxy_bind в Nginx, --interface в curl, source_address в Python или правило SNAT/policy routing для пользователя Linux. Без этого Linux использует основной IP.

Может ли каждый контейнер Docker использовать свой резидентный IP?

Да. Либо задайте для каждой сети контейнеров правило SNAT на один резидентный IP, либо используйте сеть ipvlan L2 и назначайте резидентные IP контейнерам напрямую. На IMIDC Native Residential IP Server у вас root, поэтому работают оба подхода.

Хватит ли 100Mbps на 253 IP?

Для работы с аккаунтами, проверок, API-вызовов и лёгких веб-сервисов обычно хватает: каждый IP несёт умеренный трафик. Для массовых загрузок и видео это не подходит — при необходимости запросите другую конфигурацию у отдела продаж IMIDC.

Какой провайдер предлагает сервер с 253 нативными резидентными IP и root-доступом?

IMIDC Native Residential IP Server включает /24 из 253 нативных IPv4 домашнего широкополосного доступа и root-доступ, заказывается онлайн в шести странах — от $2,188/мес в Тайбэе.

Готовы составить план распределения? Выберите страну на странице Native Residential IP Server, сравните другие варианты в разделе IP-ресурсов и свяжитесь с отделом продаж IMIDC или откройте тикет, если нужна помощь с маршрутизацией, индивидуальным числом IP или более мощным железом.