Публічний префікс для VPN-клієнтів: що він насправді ламає

Пул клієнтів, обраний тому що номери виглядають охайно, — це маршрут, що чекає на встановлення. Префікс не мусить бути приватним, щоб VPN працював, і використання блока, що належить комусь іншому, також не розкриває ваших користувачів в інтернеті автоматично. Що він робить — це змушує ці адреси означати інше, поки тунель піднятий, а потім знову означати інше, коли він падає. Пройдіть п'ять перевірок нижче по порядку і зупиніться там, де відповідь «призначено в іншому місці».

Призначення — це не оголошення

Розміщення адреси на інтерфейсі тунелю не оголошує її в інтернеті. Публічна доступність потребує маршруту, авторизованого шляху й провайдера, готового його нести, і ніщо з цього не з'являється тому, що клієнт отримав адресу з пула. Політика міжмережевого екрана й авторизація хоста — знову окремі рішення.

Тому ризик не той, що припускає більшість. Позичений префікс не робить ваших клієнтів доступними; він робить адреси чужого призначення недоступними з ваших клієнтів, а це інша несправність з іншим власником. Ніхто не зазнає атаки, і жодне оголошення не витікає. Користувач просто не може відкрити сайт, який працював учора, і в служби підтримки немає причини підозрювати пул VPN.

Ця різниця важлива при виборі пула. Якби єдиною турботою було розкриття в інтернеті, публічний блок виглядав би безпечно, бо ніщо його не оголошує. Турбота — це локальний маршрут, який клієнт встановлює для цього префікса, і цей маршрут встановлюється незалежно від того, чи бачить його хтось інший.

Що насправді захоплює маршрут клієнта

Коли тунель піднімається, клієнт отримує маршрут для префікса пула, і цей маршрут перемагає маршрут за замовчуванням для кожного призначення всередині нього. Запит до законного хоста в цьому блоці тепер іде до VPN, а не в інтернет. Чи він провалиться, зависне або потрапить на неправильний сервер, залежить від того, що робить ваша сторона.

ip route get 198.51.100.20
ip -br addr show tun0
traceroute -n 198.51.100.20

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

Тому ж знайома IP-адреса не є доказом особи. Зберігайте перевірку сертифіката й імені сервера для справжнього призначення, бо числова адреса, до якої ви дісталися п'ять хвилин тому, тепер може належати іншій розмові.

Порівняйте пул із кожною мережею, яку ви знаєте

RFC 1918 виділяє три блоки для приватного використання: 192.168.0.0/16, 172.16.0.0/12 і 10.0.0.0/8. Мільйони окремих організацій використовують їх повторно, тому «приватний» — це твердження про розподіл і ніколи не обіцянка, що ніхто інший не вибрав ті самі номери.

Порівняйте кандидатний пул з офісними LAN, хмарними VPC, іншими пулами VPN, партнерськими каналами й діапазонами, які віддалені працівники, ймовірно, мають удома. Домашній випадок — не причина вигадувати дивний префікс; це причина тримати пул малим і задокументованим.

Узгодьте розподіл із тим, хто володіє маршрутизацією, і запишіть зворотний шлях у тому самому місці. Пул, до якого ніхто не може маршрутизувати назад, — це пул, який буде виявлено заново під час збою. Помістіть пул у той самий документ, що й діапазони майданчиків, а не в конфігурацію клієнта, яку редагувала лише одна людина. Саме документ робить наступне зіткнення відворотним.

Коли публічна адресація — правильна відповідь

Організації з правильно виділеним глобальним простором цілком можуть побудувати пул VPN з публічними адресами, і деякі роблять це навмисно, щоб уникнути трансляції. Цей дизайн усе одно потребує маршрутизації, перевірки джерела, правил доступу й автентифікації клієнтів; виділення не дає нічого з цього.

Що він дає — це унікальність, властивість, якої бракує позиченому префіксу. Якщо блок належить вам, маршрут, який встановлює ваш клієнт, вказує на адреси, що справді ваші, і сенс не змінюється, коли тунель падає.

Не додавайте NAT автоматично, щоб компенсувати вибір пула. Маршрутизований приватний дизайн з явними зворотними маршрутами чистіший, ніж трансляція, застосована тому що адресація ніколи не планувалася, а IPv6 потребує власного свідомого плану, а не копії припущень IPv4.

Виведіть поганий пул з експлуатації, не втративши доступ

Якщо пул уже розгорнуто, проведіть інвентаризацію перед зміною: резервування адрес, встановлені маршрути, DNS-записи, що розв'язуються в блок, області міжмережевого екрана й застосунки, які від них залежать. Потім заплануйте зміну з такою ж ретельністю, як будь-який інший перехід маршрутизації. Оголосіть її людям, які це помітять, бо їхні сеанси перервуться, коли пул зрушить. Тиха зміна адресації клієнтів породжує звернення до підтримки, які здаються не пов'язаними з роботою.

Збережіть шлях відновлення, що не залежить від пула, який ви видаляєте, бо момент, коли ви його відкликаєте, — це момент, коли ваш віддалений доступ може зникнути разом із ним. Потім перевірте обидва напрямки: заплановані приватні призначення все ще працюють, а інтернет-призначення, які раніше захоплювалися, тепер розв'язуються до своїх справжніх власників.

Ви хочете пул, який мережева команда може виділити, маршрутизувати й вивести з експлуатації як одну зв'язну річ. Формат адреси сам по собі не забезпечує ні безпеки, ні зв'язності.