Paano sukatin ang espasyo ng address para sa VPN sa pagitan ng mga site

Itanong kung gaano kalaki ang subnet ng VPN at ang tapat na sagot ay maaaring may apat na magkakaibang subnet sa loob ng tanong. Ang VPN ng site ay maaaring may kasamang mga endpoint ng transport, may bilang na link ng tunnel, ang mga prefix ng protektadong LAN at, sa mga pinamamahalaang gateway, isang subnet ng imprastraktura na inilalaan ng provider. Isa o dalawa lamang sa mga iyon ang umiiral sa isang partikular na disenyo. Ang pagsukat sa kanila mula sa bilang ng mga device sa opisina ang dahilan kung bakit nagtatapos ang isang plano sa /24 na walang nasisiyahan.

Pangalanan ang apat na tungkulin bago maglaan ng anuman

Ang mga endpoint ng transport ay ang mga address na ginagamit ng dalawang gateway upang maabot ang isa’t isa sa internet o pribadong circuit, at ang bilang nila ay nagmumula sa modelo ng gateway at redundancy, hindi sa LAN. Ang mga panloob na link ng tunnel ay umiiral lamang kung saan binibilang ng disenyo ang isang point-to-point interface, na karaniwang hindi ginagawa ng IPsec configuration na nakabatay sa patakaran. Ang mga protektadong prefix ay ang tunay na network ng opisina o VPC na dapat maruting, at ang subnet na inilaan ng provider ay pag-aari ng pinamamahalaang serbisyo.

Iimbentaryo ang umiiral na bago magdagdag ng anuman, dahil ang mamahaling pagkakamali dito ay ang muling paggamit ng prefix na ruta na sa ibang lugar. Ang lumang tunnel mula sa pilot project ay sapat na upang lasunin ang isang plano. Isulat ang imbentaryo kasama ang mga petsa, dahil ang alaala ng isang link na na-decommission ay nabubuhay nang mas matagal kaysa sa link mismo.

ip -br addr show
ip route show | head -40

Ang dalawang command na iyon ay nagbibigay ng lokal na tanawin ng mga konektadong network at ng mga rutang umaabot sa lahat ng nasa labas nila. Ulitin ang imbentaryo sa bawat site, dahil ang planong itinayo mula sa output ng isang site ay babangga sa output ng susunod. Tipunin ang mga output bago maglaan ng isang bloke.

Bilangin ang mga link at topolohiya, hindi ang mga device

Ang disenyong may walong point-to-point na kapitbahayan ay gumagamit ng walong bloke, hindi isa. Sa /30 bawat bloke ay gumagastos ng apat na address upang ikonekta ang dalawang host, kaya nagdadala ang plano ng tatlumpu’t dalawang address para sa labing-anim na magagamit na endpoint, at iyon ang bilang na dapat pasanin ng badyet. Ang platform na sumusuporta sa /31 na link ay gumagastos ng kalahati, ngunit lamang kapag ang dalawang dulo at ang serbisyo ay sumasang-ayon sa modelong iyon. Bilugan ang badyet pataas sa halip na pababa, dahil ang pagpapaliit ng bloke mamaya ay nangangahulugan ng muling pagbilang ng mga aktibong link.

Ang mga hadlang ng provider ay nananaig sa pangkalahatang kasanayan. Ang dokumentadong panloob na hanay ng tunnel ay maaaring mangailangan ng /30 kahit saan gumagana ang /31 sa iyong mga router, at ang pinamamahalaang gateway ay maaaring humingi ng partikular na mask para sa sarili nitong subnet. Basahin ang pangangailangan ng serbisyo bago ilapat ang isang tuntunin na hiniram mula sa ibang platform.

Ang multipoint overlay ay muling nagbabago ng aritmetika: isang address bawat gateway, at ang overlay ang humahawak sa maabot sa pagitan nila. Magpasiya kung aling topolohiya ang aktwal na ginagamit ng implementasyon bago i-multiply ang mga site sa laki ng bloke.

Ang paglago ay nararapat sa sarili nitong linya sa plano. Ang pagreserba ng magkakaugnay na hanay ng imprastraktura ay makatwiran, gayundin ang pagtala kung aling mas maliliit na alokasyon ang nasa loob nito, upang hindi basahin ng susunod na inhinyero ang reserbasyon bilang isang broadcast domain.

Ilayo ang subnet ng gateway sa pool ng LAN

Ang imprastraktura ng pinamamahalaang gateway ay hindi pool ng kliyente. Ang mga address sa inilaang subnet ng gateway ay nagho-host ng sariling mga bahagi ng serbisyo, at ang mga malayuang manggagawa ay hindi kailanman kumukuha mula sa kanila. Ang pagsukat ng subnet na iyon mula sa bilang ng user ay pagkakamali ng kategorya na maaaring mag-aksaya ng malaking hanay o magutom ang gateway.

Ganoon din sa mga hanay ng tunnel sa mga koneksiyon ng cloud VPN, kung saan naglalaan ang provider ng maliit na panloob na hanay bawat tunnel para sa sariling gamit. Ang hanay na iyon ay hindi kung saan nakatira ang iyong mga server ng sangay, at hindi iyon sa iyo upang ipamahagi.

aws ec2 describe-vpn-connections --query "VpnConnections[].{Id:VpnConnectionId,Tunnels:Tunnels[].OutsideIpAddress}" --output table

Ang paglilista ng mga panlabas na address ay nagpapatunay kung ano ang inilaan ng provider at aling redundant na tunnel ang aktibo sa ngayon. Mas mabilis ito kaysa sa pagbasa ng dokumento ng disenyo na isinulat bago pa umiiral ang koneksiyon.

Itala ang tungkulin, may-ari at paglago para sa bawat prefix

Ang planong nakakaligtas sa pakikipag-ugnayan sa operasyon ay nagsasaad, para sa bawat prefix, kung anong tungkulin ang ginagampanan nito, sino ang naglalaan ng malayong dulo at gaano karaming espasyo ang natitira. Kung walang field ng may-ari, dalawang team ang naglalaan ng parehong /24 sa parehong quarter, at ang banggaan ay lumilitaw lamang kapag bumangon ang tunnel.

Ilayo ang mga hanay na ito sa mga prefix ng tahanan at sangay na dumarating sa ibang tunnel, dahil ang nagsasapaw na espasyo ang karaniwang dahilan kung bakit matagumpay na nakikipagnegosasyon ang koneksiyong site-to-site at pagkatapos ay walang trafik na dumadaan.

Ang paglalaan ng mga panloob na address ng link ay hindi nag-aanunsyo ng mga LAN sa likod nila. Ang mga ruta o traffic selector, return path at patakaran sa pag-access ay hiwalay na work item, at dapat sabihin ito ng plano sa halip na ipahiwatig na ang may bilang na interface ang gagawa ng routing para sa iyo.