BYOIP з менш ніж 256 адресами: що працює нижче /24

Жоден хмарний або хостинг-провайдер не приймає через bring your own IP менше за /24, і жоден не зміг би. Мережі по всьому інтернету відкидають маршрути, менші за /24, тож /25, анонсований окремо, не дійшов би майже ні до кого. Якщо вам потрібні власні адреси, але менше ніж 256, є три способи, що працюють, і три, що не працюють.

Чому /24 є нижньою межею

Кожна мережа в інтернеті тримає таблицю маршрутів, і щоб ця таблиця залишалася керованою, майже всі вони приймають маршрути IPv4 не менші за /24 і мовчки відкидають усе довше. До /25, /28 або однієї адреси можна дістатися лише як до частини /24, яку якась мережа анонсує цілком.

Саме тому BYOIP жодного провайдера не йде нижче /24 (посібники за провайдерами); Alibaba Cloud починає ще вище, з /23. Це не комерційний вибір, який провайдер міг би зробити для вас інакше. Менший блок просто не був би досяжним з більшої частини інтернету.

Варіант 1: взяти весь /24

Якщо вам потрібна сотня адрес, повний /24 часто менш надмірний, ніж здається, і це чистіше рішення. Ви приносите його своєму провайдеру через його звичайну процедуру BYOIP, він анонсується, як будь-який інший блок, і у вас є запас для зростання. Оренда позбавляє капітальних витрат на купівлю, а наші ціни на оренду опубліковано (ціни). Azure вимагає, щоб блок був зареєстрований на ваше ім’я, а список прийнятних статусів Oracle Cloud не містить ASSIGNED PA, звичайного статусу орендованого простору IP, тож щодо цих двох спершу уточніть у нас.

Недолік очевидний: ви платите за 256 адрес, а використовуєте менше.

Варіант 2: тунель доставляє рівно стільки, скільки потрібно

Мережа, що анонсує повний /24, може передати меншу його частину вашому серверу через тунель: /29, /28 або одну адресу. Трафік для цих адрес доходить до мережі, що анонсує блок, проходить через тунель GRE або WireGuard до вашого сервера, а ваш сервер використовує адреси так, ніби їх налаштовано локально (як працює тунель).

Що це вам дає:

• Будь-який провайдер. Це працює там, де BYOIP узагалі не пропонують, наприклад у Hetzner Cloud (Hetzner), бо провайдер має лише пропускати тунель.
• Адреси залишаються вашими. Коли ви переїжджаєте, тунель переїжджає разом із сервером, а адреси, їхня репутація і кожен allowlist, у якому вони є, переходять з вами.
• Жодного ASN, жодної роботи з ROA з вашого боку. Блок анонсує мережа на іншому кінці.

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

Варіант 3: додаткові адреси самого провайдера

Більшість провайдерів продає додаткові IPv4-адреси зі своїх пулів як failover, floating або elastic IP. Їх швидко додати, і вони працюють одразу. Але вони належать провайдеру: залишаються, коли ви йдете, allowlist ваших партнерів доводиться змінювати, і ви успадковуєте ту репутацію, яку на них залишив попередній користувач.

Це підходить для адрес, які мають просто працювати, в одного провайдера, наразі.

Що не працює

• Самостійно анонсувати /25 або менше через BGP. Його відфільтрують майже всюди, хоч би якими добрими були ваша сесія і ваш ROA.
• Просити хмару прийняти /26. BYOIP кожного провайдера приймає /24 або більше, тож менший блок відхиляють ще до початку налаштування.
• Розділити /24 між двома хмарами через BYOIP. У більшості провайдерів діапазон водночас перебуває лише в одному місці. Тунель може обслуговувати частини блоку в кількох місцях; BYOIP загалом ні.

Що вибрати

Де тут RTM Networks

Ми робимо обидва перші варіанти. Ми здаємо в оренду /24 і більші блоки для BYOIP, з ROA, записом у реєстрі і листом авторизації, налаштованими для вашого провайдера, і доставляємо менші блоки через GRE або WireGuard на сервер у будь-якого провайдера, аж до однієї адреси (GRE-тунелі та WireGuard). Скажіть нам, скільки адрес вам потрібно і де ваші сервери, і ми підкажемо, який із двох варіантів підходить.