Як падлічыць адрасную прастору для VPN паміж пляцоўкамі
Транспартныя канчатковыя пункты, унутраныя каналы, абароненыя лакальныя сеткі і падсеткі шлюза — гэта чатыры асобныя бюджэты. Кожны лічыце з тапалогіі, а не з колькасці прылад.
Спытайце, якога памеру павінна быць падсетка VPN, і сумленны адказ будзе такі: у пытанні могуць хавацца чатыры розныя падсеткі. VPN пляцоўкі можа ўключаць транспартныя канчатковыя пункты, пранумараваныя тунельныя каналы, прэфіксы абароненай лакальнай сеткі і, на кіраваных шлюзах, інфраструктурную падсетку, якую рэзервуе пастаўшчык. У канкрэтным праекце існуюць толькі адна-дзве з іх. Разлічваць іх па колькасці офісных прылад — гэта шлях да плана з /24, які нікога не задаволіць.
Назавіце чатыры ролі, перш чым нешта выдзяляць
Транспартныя канчатковыя пункты — гэта адрасы, якія два шлюзы выкарыстоўваюць, каб дасягнуць адзін аднаго праз інтэрнэт або выдзелены канал, і іх колькасць вызначаецца мадэллю шлюза і рэзервавання, а не лакальнай сеткай. Унутраныя тунельныя каналы існуюць толькі там, дзе праект нумаруе інтэрфейс «пункт-пункт», чаго канфігурацыя IPsec на аснове палітык звычайна не робіць. Абароненыя прэфіксы — гэта рэальныя офісныя сеткі або сеткі VPC, якія павінны быць маршрутызуемымі, а зарэзерваваная пастаўшчыком падсетка належыць кіраванаму сэрвісу.
Правядзіце інвентарызацыю таго, што ўжо ёсць, перш чым нешта дадаваць, бо дарагая памылка тут — паўторна выкарыстаць прэфікс, які ўжо маршрутызуецца ў іншым месцы. Старога тунеля з пілотнага праекта дастаткова, каб сапсаваць план. Запішыце інвентарызацыю з датамі, бо памяць пра выведзены з эксплуатацыі канал жыве даўжэй за сам канал.
ip -br addr show ip route show | head -40
Гэтыя дзве каманды даюць лакальную карціну падключаных сетак і маршрутаў, якія дасягаюць усяго за іх межамі. Паўтарыце інвентарызацыю на кожнай пляцоўцы, бо план, пабудаваны па вывадзе адной пляцоўкі, сутыкнецца з вывадам наступнай. Збярыце вывады, перш чым выдзяляць хоць адзін блок.
Лічыце каналы і тапалогію, а не прылады
Праект з васьмю суседствамі «пункт-пункт» выдаткаўвае восем блокаў, а не адзін. Пры /30 кожны блок выдаткаўвае чатыры адрасы, каб злучыць два вузлы, таму план нясе трыццаць два адрасы на шаснаццаць прыдатных канчатковых пунктаў, і менавіта гэтую лічбу мусіць вытрымаць бюджэт. Платформа, якая падтрымлівае каналы /31, выдаткаўвае палову, але толькі калі абодва канцы і сэрвіс згодныя з такой мадэллю. Акругляйце бюджэт уверх, а не ўніз, бо паменшыць блок пазней азначае перанумараваць працуючыя каналы.
Абмежаванні пастаўшчыка важнейшыя за агульную практыку. Задакументаваны ўнутраны дыяпазон тунеля можа патрабаваць /30 нават там, дзе /31 працуе на вашых маршрутызатарах, а кіраваны шлюз можа патрабаваць пэўную маску для сваёй падсеткі. Прачытайце патрабаванне сэрвісу, перш чым ужываць правіла, пазычанае з іншай платформы.
Шматпунктавае накладанне зноў мяняе арыфметыку: адзін адрас на шлюз, а дасяжнасць паміж імі забяспечвае накладанне. Вырашыце, якую тапалогію рэалізацыя сапраўды выкарыстоўвае, перш чым памнажаць пляцоўкі на памер блока.
Рост заслугоўвае асобнага радка ў плане. Зарэзерваваць звязны інфраструктурны дыяпазон разумна, як і запісаць, якія меншыя выдзяленні ляжаць унутры яго, каб наступны інжынер не прачытаў рэзерваванне як адзін шырокавешчальны дамен.
Трымайце падсетку шлюза па-за пулам лакальнай сеткі
Інфраструктура кіраванага шлюза — не пул кліентаў. Адрасы ў зарэзерваванай падсетцы шлюза размяшчаюць уласныя кампаненты сэрвісу, і аддаленыя супрацоўнікі ніколі з іх не бяруць. Разлічваць гэтую падсетку па колькасці карыстальнікаў — катэгарычная памылка, якая або марнуе вялікі дыяпазон, або прымушае шлюз галадаць.
Тое ж датычыцца дыяпазонаў тунеляў у хмарных VPN-падключэннях, дзе пастаўшчык выдзяляе невялікі ўнутраны дыяпазон на кожны тунель для ўласных патрэб. Гэты дыяпазон — не месца, дзе жывуць вашыя серверы філіяла, і ён не ваш, каб яго раздаваць.
aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table
Пералік знешніх адрасоў пацвярджае, што выдзеліў пастаўшчык і які рэзервовы тунель зараз актыўны. Гэта хутчэй, чым чытаць праектны дакумент, напісаны да таго, як падключэнне з’явілася.
Запісвайце ролю, уласніка і рост для кожнага прэфікса
План, які перажывае сутыкненне з эксплуатацыяй, пазначае для кожнага прэфікса, якую ролю ён грае, хто выдзяляе далёкі канец і колькі запасу ён мае. Без поля ўласніка два каманды выдзяляюць тую самую /24 у адным квартале, і сутыкненне праяўляецца толькі калі тунель падымаецца.
Трымайце гэтыя дыяпазоны далей ад хатніх і філіяльных прэфіксаў, што прыходзяць праз іншыя тунелі, бо перакрыжаваная прастора — звычайная прычына таго, што злучэнне паміж пляцоўкамі паспяхова ўзгадняецца, а потым не прапускае трафік.
Выдзяленне ўнутраных адрасоў канала не абвяшчае лакальныя сеткі за імі. Маршруты або селектары трафіку, зваротныя шляхі і правілы доступу — асобныя працоўныя пункты, і план павінен казаць гэта, а не намякаць, што пранумараваны інтэрфейс выканае маршрутызацыю за вас.