Звідки насправді виходить інтернет-трафік вашої керованої VPN

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

Простежте одну публічну адресу призначення на кожен майданчик

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

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

Три схеми виходу і що кожна концентрує

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

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

Фільтрація, перетворення та шифрування мають різних власників

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

Широкий маршрут за замовчуванням імпортований у контекст приватної маршрутизації заслуговує на таку саму перевірку, бо імпорт — це усвідомлена домовленість, а не нешкідлива зручність. Розділ 11 RFC 4364 розбирає кілька схем доступу до інтернету для мереж BGP/MPLS VPN і трактує обмін маршрутами між контекстом VPN і контекстом передавання за замовчуванням у постачальника саме як таку домовленість. Запитайте, що заважає публічному трафіку випадково піти приватним шляхом, і отримайте відповідь поруч із політикою маршрутів, а не на слайді.

Два сценарії відмови, про які треба домовитися до підписання

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

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

traceroute -n 203.0.113.10
curl -s https://example.net/ip

Прив'язуйте зобов'язання щодо доступності до виміряного сегмента, а не до назви послуги. Місцевий канал, магістраль постачальника і спільний шлюз несуть окремі зобов'язання та окремі команди ескалації. Літери L2VPN, L3VPN і MPLS описують механізм передавання, а не гарантію від краю до краю.

Докази сильніші за прикметники в пропозиції

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

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