Cum dimensionați spațiul de adrese pentru un VPN între locații

Întrebați cât de mare ar trebui să fie subrețeaua VPN și răspunsul onest este că în întrebare pot încăpea patru subrețele diferite. Un VPN de locație poate implica puncte finale de transport, legături de tunel numerotate, prefixele rețelei LAN protejate și, pe gateway-urile administrate, o subrețea de infrastructură rezervată de furnizor. Într-un proiect dat există doar una sau două dintre ele. Dimensionarea lor după numărul de dispozitive de birou este modul în care un plan ajunge la un /24 care nu mulțumește pe nimeni.

Numiți cele patru roluri înainte de a aloca ceva

Punctele finale de transport sunt adresele pe care două gateway-uri le folosesc pentru a se atinge reciproc prin internet sau printr-un circuit privat, iar numărul lor vine din modelul de gateway și redundanță, nu din rețeaua LAN. Legăturile de tunel interne există doar acolo unde proiectul numerotează o interfață punct-la-punct, ceea ce o configurație IPsec bazată pe politici de obicei nu face. Prefixele protejate sunt rețelele reale de birou sau VPC care trebuie să fie rutabile, iar subrețeaua rezervată de furnizor aparține serviciului administrat.

Inventariați ce există deja înainte de a adăuga ceva, pentru că greșeala costisitoare aici este reutilizarea unui prefix care este deja rutat altundeva. Un tunel vechi dintr-un proiect pilot este suficient pentru a otrăvi un plan. Notați inventarul cu date, pentru că amintirea unei legături dezafectate supraviețuiește legăturii înseși.

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

Cele două comenzi dau vederea locală a rețelelor conectate și a rutelor care ajung la tot ce este dincolo de ele. Repetați inventarul la fiecare locație, pentru că un plan construit din ieșirea unei singure locații se va ciocni cu cea a următoarei. Strângeți ieșirile înainte de a aloca un singur bloc.

Numărați legături și topologie, nu dispozitive

Un proiect cu opt adiacențe punct-la-punct consumă opt blocuri, nu unul. La /30 fiecare bloc cheltuiește patru adrese pentru a conecta două gazde, așa că planul poartă treizeci și două de adrese pentru șaisprezece puncte finale utilizabile, iar aceasta este cifra pe care bugetul trebuie să o susțină. O platformă care acceptă legături /31 cheltuiește jumătate, dar numai când ambele capete și serviciul cad de acord asupra acelui model. Rotunjiți bugetul în sus, nu în jos, pentru că reducerea unui bloc mai târziu înseamnă renumerotarea legăturilor active.

Constrângerile furnizorului bat practica generală. Un interval de tunel intern documentat poate cere /30 chiar și acolo unde /31 funcționează pe routerele dumneavoastră, iar un gateway administrat poate cere o mască specifică pentru propria subrețea. Citiți cerința serviciului înainte de a aplica o regulă empirică împrumutată de la altă platformă.

Un strat suprapus multipunct schimbă din nou aritmetica: o adresă pe gateway, stratul suprapus ocupându-se de accesibilitatea între ele. Decideți ce topologie folosește de fapt implementarea înainte de a înmulți locațiile cu o dimensiune de bloc.

Creșterea merită propria linie în plan. Rezervarea unui interval de infrastructură coherent este rezonabilă, la fel și notarea alocărilor mai mici care se află în el, ca următorul inginer să nu citească rezervarea ca un singur domeniu de difuzare.

Țineți subrețeaua gateway-ului în afara grupului rețelei LAN

Infrastructura unui gateway administrat nu este un grup de clienți. Adresele dintr-o subrețea de gateway rezervată găzduiesc componentele serviciului însuși, iar lucrătorii la distanță nu se alimentează niciodată din ele. Dimensionarea acelei subrețele după numărul de utilizatori este o eroare de categorie care fie risipește un interval mare, fie înfometează gateway-ul.

Același lucru se aplică intervalelor de tunel de pe conexiunile VPN în cloud, unde furnizorul alocă un interval intern mic pe tunel pentru uz propriu. Acel interval nu este locul unde stau serverele sucursalei, și nu este al dumneavoastră pentru a-l împărți.

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

Listarea adreselor externe confirmă ce a alocat furnizorul și care tunel redundant este activ în acest moment. Este mai rapid decât citirea unui document de proiectare scris înainte ca conexiunea să existe.

Înregistrați rolul, proprietarul și creșterea pentru fiecare prefix

Un plan care supraviețuiește contactului cu operațiunile declară, pentru fiecare prefix, ce rol joacă, cine alocă capătul îndepărtat și cât spațiu liber are. Fără câmpul proprietarului, două echipe alocă același /24 în același trimestru, iar coliziunea apare abia când tunelul se ridică.

Țineți aceste intervale departe de prefixele de acasă și de sucursală care sosesc prin alte tuneluri, pentru că suprapunerea spațiului este motivul obișnuit pentru care o conexiune între locații negociază cu succes și apoi nu trece niciun trafic.

Alocarea adreselor interne de legătură nu anunță rețelele LAN din spatele lor. Rutele sau selectoarele de trafic, căile de întoarcere și regulile de acces sunt elemente de lucru separate, iar planul ar trebui să spună asta în loc să sugereze că o interfață numerotată face rutarea pentru dumneavoastră.