Kreatywne schematy IP / podsieci / dns

Zarządzałem tylko niewielkimi sieciami (<= 25 węzłów). Zazwyczaj umieszczam bramę .1, dns / proxy jako .10, pocztę na .20, drukarki na .30-39 i tak dalej. Nigdy nie używam adresów IP bezpośrednio, ponieważ nazwy hostów DNS są wyraźnie lepszym sposobem, ale lubię mieć jasny wzorzec / układ / projekt podczas budowania sieci od podstaw.

Moje mapowanie DNS ma również prosty wzorzec / układ nazewnictwa. Na przykład wszystkie moje urządzenia mają dwie nazwy; jedna formalna nazwa oparta na roli (dc01, mail02 itp.) i nieformalna nazwa. Nic szczególnego, ale naprawdę proste i łatwe w zarządzaniu.

Próbuję wymyślić bardziej intuicyjny / kreatywny schemat IP / podsieci / DNS (jeśli jest coś lepszego). Jestem pewien, że inni mają bardziej intuicyjne schematy w zależności od celów sieci i tym podobnych. Moja sieć, nad którą pracuję, jest wciąż niewielka, ale mam wiele urządzeń, z którymi mogę się zmagać.

Szukam ogólnego wzorca lub metodyki przypisywania adresu IP (zakresów / klas), nazw dns i sieci podsieci, które obejmują 4-5 głównych punktów:

1. Usługi sieciowe (poczta, pliki, proxy itp.)
2. Tworzenie oprogramowania (środowiska - dev / staging / prod,
3. Media (streaming, przesyłanie dużych plików, archiwizacja)
4. Wirtualne serwery / komputery stacjonarne
5. VoIP

Nigdy nie współpracowałem bezpośrednio z VoIP, ale warto wziąć to pod uwagę na przyszłość.

Ogólnie mam od wszystkich naprawdę dobre pomysły. Chciałbym dać więcej głosów / zaakceptowanych odpowiedzi. Dziękuję za odpowiedzi!

Nie komplikuj. Tak proste, jak to możliwe, ale wciąż zapewniające bezpieczeństwo i elastyczność. Zaprojektuj abstrakcję w rzeczy, które brzmią tak, jakby to nie było proste, ale w rzeczywistości jest ścieżką do samej prostoty.

W przypadku podsieci jest to dość powszechne:

• Użytkownicy w jednej podsieci
• Goście na innym
• Serwery we własnej podsieci
• VOIP sam w sobie.

Filtruj ruch według każdej podsieci, jeśli to konieczne. Ewentualnie użyj sieci VLAN. Mam nadzieję, że dobrze znasz CLI wybranego dostawcy urządzenia sieciowego.

Jeśli chodzi o DNS, nie spodoba ci się to, ale ... użyj tego, co Ci odpowiada. Osobiście lubię nadawać serwerom całkowicie abstrakcyjną nazwę hosta bez powiązań z jej usługami. Następnie usług CNAME do nazwy hosta. W ten sposób migracja usług nie powoduje problemów związanych ze zmianą DNS. A przynajmniej nie tak wiele. Wolę też nazywać wirtualne serwery z av poprzedzonym nazwą hosta.

Przykłady:

• Nowy serwer bazy danych nosi nazwę Athena. Będzie nazywać się Atena na zawsze.
• Athena jest CNAMED za to, co robi: SQL08ENT-CRM, SQL08ENT-AEGIS (system bezpieczeństwa), SQL08ENT-DOCMAN. Być może również CNAMED na podstawie geografii. A może nazwa hosta będzie zawierać geografię. Athena-ATL. Athena-Sydney. Cokolwiek działa.
• Serwer znajduje się w podsieci serwera, która ma domyślną zasadę odmowy. Zawiera odpowiedni ruch z odpowiednich podsieci.

Trzymać. To. Prosty. (ale funkcjonalne)

Pracowałem w organizacji o podobnej wielkości (mieliśmy / 26), która z przyczyn niezależnych ode mnie uważała, że ​​precyzyjny schemat alokacji własności intelektualnej był najważniejszy dla integralności operacyjnej. Brama musiała być .1, drukarki musiały być między .2 a .12, serwery między .13 a .20 i tak dalej. Prowadziliśmy nawet dokumentację na temat poszczególnych hostów.

To ogromny ból w dupie. Bez względu na to, jak bardzo byłem sumienny, nigdy nie wydawałem się, aby dokumentacja była aktualna. Nie pomogło nam to, że nie mieliśmy żadnych usług DNS, więc korzystanie z dokumentacji schematu alokacji adresów IP było jedynymi usługami „nazywania”, jakie mieliśmy (co w dziwny sposób sprawiło, że wydawało się to bardziej niezbędne niż w rzeczywistości).

W przypadku sieci twojego rozmiaru poleciłbym kilka rzeczy (z których większość już zrobiłeś):

• Proste - nie zarządzasz setkami hostów. Złożoność rozwiązania powinna odzwierciedlać złożoność środowiska. Opieraj się pokusie bycia zbyt sprytnym. Podziękujesz sobie później.

  1. Weź dostępną przestrzeń IP i daj klientom 60% za pośrednictwem DHCP. Skonfiguruj jakieś dynamiczne usługi DNS, abyś nigdy więcej nie musiał patrzeć na cholerny adres IP. Zapomnij o ich śledzeniu. Zysk.

  2. Zarezerwuj pozostałe 30% na adresy IP, którymi zarządzasz: serwery, drukarki, urządzenia sieciowe, usługi testowania. itp. UŻYJ DNS DO DOKUMENTOWANIA TEGO. Moim zdaniem nie ma większej straty czasu niż uważne śledzenie wszystkich tych „zarządzanych przez administratora” adresów IP (w przeciwieństwie do adresów IP zarządzanych przez DHCP) za pomocą arkusza kalkulacyjnego Excel (do którego należy stale odnosić się i utrzymywać) , kiedy możesz wkładać ten wysiłek we wspieranie samokontraktującego i znacznie bardziej użytecznego rozwiązania DNS.

  3. Nie wykorzystuj ostatnich 10% swojego adresu u góry przestrzeni adresowej IP. Mała rezerwa nigdy nie boli.

  4. Dostosuj współczynniki według własnego uznania. Niektóre środowiska będą miały więcej klientów, inne będą obciążone „serwerami” (tj. „Zarządzanymi przez administratora”).

• Usługi sieciowe (poczta, pliki, proxy itp.)
• Tworzenie oprogramowania (środowiska - dev / staging / prod,

Oba należą do kategorii „zarządzanych przez administratora” przestrzeni IP.

• Media (streaming, przesyłanie dużych plików, archiwizacja)

Moim zdaniem ma to niewiele wspólnego z podsieciami i wszystko z monitorowaniem sieci.

• Wirtualne serwery / komputery stacjonarne

Serwery są „zarządzane przez administratora”, komputery stacjonarne (tj. Komputery klienckie) powinny być „zarządzane przez DHCP”.

• VoIP

Fizycznie dyskretna sieć byłaby idealna ... ale to nierealne. Kolejną najlepszą rzeczą będzie oddzielna sieć VLAN i podsieć. Jest to jedyny punkt w małej sieci, w którym naprawdę czułbym potrzebę segregacji ruchu (z wyjątkiem rzeczy publicznie dostępnych).

Przydziały IP

Radzę umieścić wszystko w podsieci 10.0.0.0/8, korzystając z następującej struktury: 10 site.. division.device

• site jest fizyczną lokalizacją lub logicznym odpowiednikiem (np. biuro w Nowym Jorku, biuro w NJ, ośrodek DR, środowisko programistyczne).
• divisionjest logicznym podziałem, który ma dla ciebie sens. np.
  0 => Przełączniki / routery
  1 => Administratorzy, 2 => Użytkownicy
  3 => VOIP
  4 => Goście
• devices to pojedyncze urządzenia (komputery, serwery, telefony, przełączniki itp.)

Chodzi o to, że można łatwo określić, co to jest urządzenie i gdzie jest jego adres: 10.2.1.100 jest stacją roboczą administratora w „Witrynie nr 2”.

Ten model wywodzi się z przypisań IP opartych na klasach: klasa A (/ 8) to twoje przedsiębiorstwo. Każda lokalizacja otrzymuje klasę B (/ 16), a każdy logiczny podział w lokalizacji otrzymuje klasę C (/ 24) dla swoich urządzeń.
Możliwe jest (a czasem pożądane) użycie czegoś większego niż a / 24 na poziomie „podziału”, a na pewno możesz to zrobić: wszystko od a / 17 do a / 24 jest ogólnie uczciwą grą z tym schematem.

Dla nazw DNS

Radzę postępować według schematu podobnego do przypisanego powyżej adresu IP:

• Wszystko jest zakorzenione w mycompany.com
• Każda witryna (/ 16) ma własną sitename.mycompany.comsubdomenę.
• Podziały logiczne mogą mieć jedną (lub więcej) subdomen w witrynie, na przykład:
  • voip.mycompany.com(z urządzeń takich jak tel0000.voip.mycompany.com, tel0001.voip.mycompany.cometc.)
  • switches.mycompany.com
  • workstations.mycompany.com (ewentualnie podzielony na administratora, użytkownika i gościa)
• Urządzenia powinny mieć sensowne nazwy. Na przykład:
  • Nazwij telefony, aby zobaczyć rozszerzenie, które dzwonią na podstawie nazwy DNS.
  • Nazwij stacje robocze na podstawie ich głównego użytkownika.
  • Wyraźnie określ adresy IP gości.
  • Nazwij serwery, abyś mógł powiedzieć, czym są / co robią.
    Można to osiągnąć za pomocą „boring” nazwy ( www01, www02, db01, db02, mail, itd.) Lub poprzez ogłaszanie schemat nazewnictwa i trzymanie się go (na przykład: serwery pocztowe są nazwane po skałach, serwery www są nazywane po drzewach, serwery baz danych są nazwany na cześć malarzy).
    Nudne imiona są łatwiejsze do nauczenia się przez nową osobę, fajne schematy nazewnictwa są przyjemniejsze. Wybierz swój.

Różne uwagi

W odniesieniu do serwerów wirtualnych:
rozważ je tak, jakby były maszynami fizycznymi (posegreguj je według podziału / celu, a nie faktu, że są one „wirtualne”. Mają osobny podział dla sieci Hypervisor / VM Administration.
Może to wydawać się ważne aby dowiedzieć się, czy skrzynka jest wirtualna czy fizyczna, ale gdy system monitorowania mówi „Hej, e-mail nie działa!”, pytanie, które zadajesz, brzmi: „Które maszyny są powiązane z pocztą e-mail?”, a nie „Które maszyny są które są wirtualne i fizyczne?”.
Należy pamiętać, że nIE potrzeba praktycznego sposobu identyfikacji, czy dana maszyna jest wirtualny lub fizyczny w przypadku hosta hypervisor wieje, ale jest to wyzwanie dla systemu monitorowania, nie architekturę sieci.

W odniesieniu do VOIP:
VOIP (w szczególności gwiazdka) jest synonimem „dziury w zabezpieczeniach”. Przenieś wszystkie swoje VOIP na własną podsieć i własną VLAN, i nie pozwól, aby znajdowała się w pobliżu czuła.
Każdy telefon VOIP, który widziałem w ubiegłym roku, obsługuje segregację VLAN (w rzeczywistości wszystkie obsługują zarówno sieci głosowe, jak i danych VLAN, więc nadal możesz używać telefonu jako przepustowego połączenia dla stacjonarnych połączeń Ethernet). Skorzystaj z tego - będziesz zadowolony, że zrobiłeś to, jeśli / kiedy twoje środowisko VOIP zostanie zhakowane.

Odnośnie planowania i dokumentacji:
Narysuj sieć na papierze, zanim zaczniesz przypisywać adresy i nazwy DNS. W rzeczywistości najpierw narysuj ołówkiem na DUŻYM arkuszu papieru.
Popełniaj wiele błędów.
Wymaż swobodnie.
Przeklinaj płynnie.
Gdy przestaniesz przeklinać i wymazywać przez co najmniej 10 dni, nadszedł czas, aby umieścić diagram w Visio / Graffle / Niektóre inne formaty elektroniczne jako oficjalny schemat sieci. Zabezpiecz ten schemat. Zachowaj to w swojej Świętej Poprawności, dodając i usuwając urządzenia, rozwijając organizację i modyfikując strukturę sieci.
Ten schemat sieci będzie najlepszym przyjacielem, gdy będziesz musiał wprowadzić zmiany, wyjaśnić sieć nowym administratorom lub rozwiązać tajemniczą awarię.