Една Azure VM се нуждае от тунела: клиент в госта или VPN шлюз?
Три условия решават дали една Azure VM трябва да пуска собствен VPN клиент, или връзката принадлежи на мрежовото ниво.
Едно работно натоварване в една Azure VM трябва да достигне частна мрежа през тунел. Въпросът, който определя дизайна, не е кой VPN продукт е по-добър, а дали някога друга машина ще се нуждае от този път. Отговорете първо на това и останалата архитектура обикновено се избира сама. Сбъркате ли, наследявате VM, която тихо е станала рутер, който никой не е документирал.
Две задачи, които изглеждат еднакво
Една VM може да бъде крайна точка или транзитна точка и разликата не е в софтуера, който инсталирате, а в това кой консумира тунела. Като крайна точка гостът пуска клиент за собствените си процеси. Като транзитна точка той препраща пакетите на други натоварвания и така става част от мрежовата ви топология.
| Задача | Какво прави VM | Кой отговаря за маршрутизацията |
|---|---|---|
| Крайна точка на натоварване | Пуска поддържан клиент за собствените си процеси | Маршрутите на госта избират одобрените дестинации |
| Транзитно устройство | Препраща други натоварвания към връзката със сайта | Таблици на маршрутите в подмрежата, препращане на NIC, политика на госта и обратни пътища |
Повечето заявки за една VM са първата задача в езика на втората. Някой казва „VM е нашият VPN“, когато има предвид, че едно приложение върху нея трябва да достигне база данни от другата страна.
Условие първо: има ли нещо друго, което се нуждае от далечната страна?
Ако отговорът е не, инсталирайте клиента в госта и спрете да проектирате. Нищо в този избор не изисква управлявания шлюз и нищо в него не прави VM шлюз за съседите ѝ. Добавяте маршрут в една операционна система.
Ако отговорът е да, или вероятно да в рамките на година, третирайте го като мрежов дизайн още сега. Други VM достигат транзитна VM само когато таблицата на маршрутите в подмрежата ги изпрати там и NIC приеме препратения трафик, така че работата е таблици на маршрутите и разрешения за препращане, а не поредна инсталация на клиент.
Условие второ: можете ли да запазите административния път?
VPN клиент, който инсталира широк маршрут, може да прихване пътя, по който администрирате VM. Ако списъкът с дестинации на тунела се припокрива с управляващата мрежа, SSH или RDP сесията ви прекъсва в момента, в който клиентът се свърже, и поправката трябва да се приложи през серийната конзола или чрез пресъздаване.
Проверете преди и след. В Linux ip route get <management-ip> показва кой интерфейс и източник би използвало ядрото в момента; сравнете това с отговора, докато тунелът е активен. Разделен тунел с явен списък с дестинации се защитава по-лесно от маршрут по подразбиране и обикновено е това, което натоварването наистина иска.
Условие трето: кой прилага корекциите в полунощ?
Клиентът в госта е вашата операционна система, вашата версия на клиента и вашите сертификати. Това е добре, когато вече управлявате VM и нейния цикъл на обновяване. Това е лоша сделка, когато VM съществува само да държи тунела. Пребройте часовете за обновяване, преди да наречете клиента в госта по-евтин. Обновяване на клиент, което изисква рестарт, е престой, който сте планирали за машина, която съществува, за да поддържа тунела.
Управляваният шлюз премества тази поддръжка към платформата. Вие все още притежавате самоличността, оторизацията и мрежовите пътища зад него, но не рестартирате машина, за да приложите обновяване на клиент.
Какво управляваният шлюз не прави
Azure VPN Gateway е услуга за свързаност на VNet със собствени схеми сайт-към-сайт и точка-към-сайт. Тя не е правило, което забранява VPN софтуер в госта, и не е готова замяна на клиент, от който едно приложение се нуждае.
Тя дава връзка на мрежовото ниво, достъпна за много натоварвания чрез маршрутизация. Тя не дава тунел, който използва само един процес на една VM и който е ограничен до самоличността на този процес. Това ограничение не е недостатък, за който да се извиняваме; то е смисълът на дизайна с клиент в госта. Едно приложение, един маршрут, един набор от идентификационни данни, без влияние върху другите VM в подмрежата.
Сравнението следователно не е управлявано срещу софтуер. То е свързаност в обхвата на мрежата срещу свързаност в обхвата на процеса, и второто е законно, когато само един процес се нуждае от него.
Планирайте пътя за растеж, преди да ви потрябва
Ако изискването нарасне от една VM до подмрежа, преработете дизайна, вместо да разширявате разрешените префикси на клиента. Повторното използване на удобна сесия като недокументиран рутер обвързва всеки консуматор с живота на тази VM, нейните идентификационни данни и нейния прозорец за обновяване.
Правилната отправна точка, след като връзката е в обхвата на мрежата, а не на натоварването, е прегледът на Azure VPN Gateway.
Преди да изберете, напишете три реда: какво се нуждае от далечната страна, кой администрира VM и кой обновява тунела. Ако и трите отговора сочат едно натоварване, клиент в госта е честният дизайн. Ако някой от тях сочи подмрежа, проектирайте мрежовото ниво сега.