Аднаму Azure VM патрэбен тунель: кліент у гасцявой сістэме ці VPN-шлюз?

Адна працоўная нагрузка ў адной Azure VM мусіць дасягнуць прыватнай сеткі праз тунель. Пытанне, якое вызначае архітэктуру, не ў тым, які прадукт VPN лепшы; яно ў тым, ці спатрэбіцца гэты шлях калі-небудзь іншай машыне. Адкажыце на гэта першым, і рэшта архітэктуры звычайна выбіраецца сама. Памыліцеся, і атрымаеце ў спадчыну VM, якая ціха стала маршрутызатарам, якога ніхто не дакументаваў.

Дзве працы, якія выглядаюць аднолькава

VM можа быць канчатковым пунктам або транзітным пунктам, і розніца не ў праграмным забеспячэнні, якое вы ўсталёўваеце, а ў тым, хто спажывае тунель. Як канчатковы пункт, гасцявая сістэма запускае кліент для ўласных працэсаў. Як транзітны пункт, яна перасылае пакеты іншых нагрузак, і таму становіцца часткай вашай сеткавай тапалогіі.

Большасць запытаў для адной 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 і хто ўсталёўвае абнаўленні тунеля. Калі ўсе тры адказы паказваюць на адну нагрузку, кліент у гасцявой сістэме — гэта сумленная архітэктура. Калі хоць адзін з іх паказвае на падсетку, праектуйце сеткавы ўзровень ужо цяпер.