Skema IP / subnet / dns materi iklan


11

Saya hanya mengelola jaringan yang agak kecil (<= 25 node). Biasanya saya meletakkan gateway .1, dns / proxy sebagai .10, mail at .20, printer di .30-39 dan seterusnya dan seterusnya. Saya tidak pernah secara langsung menggunakan alamat IP karena nama host DNS jelas merupakan cara yang lebih baik, tetapi saya ingin memiliki pola / tata letak / desain yang jelas saat membangun jaringan dari awal.

Pemetaan DNS saya juga memiliki pola / tata letak penamaan yang sederhana. Misalnya, semua perangkat saya memiliki dua nama; satu nama formal berdasarkan peran (dc01, mail02, dll.) dan nama informal. Tidak ada yang mewah, tetapi sangat sederhana dan mudah dikelola.

Saya mencoba mencari skema IP / Subnet / DNS yang lebih intuitif / kreatif (jika ada sesuatu yang lebih baik). Saya yakin orang lain memiliki skema yang lebih intuitif tergantung pada tujuan jaringan dan semacamnya. Jaringan saya yang sedang saya kerjakan masih kecil, tetapi saya memiliki banyak perangkat untuk bersaing.

Saya mencari pola atau metodologi umum untuk menetapkan alamat IP (rentang / kelas), nama dns, dan jaringan subnet yang mencakup 4-5 poin utama:

  1. Layanan jaringan (mail, file, proxy, dll.)
  2. Pengembangan perangkat lunak (lingkungan - dev / staging / prod,
  3. Media (streaming, transfer file besar, pengarsipan)
  4. Server virtual / desktop
  5. VoIP

Saya tidak pernah bekerja secara langsung dengan VoIP, tetapi ini sesuatu yang harus dipertimbangkan untuk masa depan.


Secara keseluruhan saya mendapat beberapa ide yang sangat bagus dari semua orang. Seandainya saya bisa memberikan lebih banyak suara / jawaban yang diterima. Terima kasih atas tanggapannya!

Jawaban:


9

Tetap sederhana. Sesederhana mungkin, tetapi tetap memungkinkan untuk keamanan dan fleksibilitas. Desain abstraksi menjadi hal-hal, yang terdengar seperti itu tidak sederhana, tetapi sebenarnya adalah jalan menuju kesederhanaan itu sendiri.

Adapun subnet, ini cukup umum:

  • Pengguna di satu subnet
  • Tamu yang lain
  • Server di subnet mereka sendiri
  • VOIP sendiri juga.

Saring lalu lintas melalui setiap subnet seperlunya. Mungkin menggunakan VLAN. Saya harap Anda akrab dengan CLI dari vendor perangkat jaringan pilihan Anda.

Sedangkan untuk DNS, Anda tidak akan menyukai ini tetapi ... gunakan apa pun yang berfungsi untuk Anda. Secara pribadi, saya ingin memberikan server nama host yang benar-benar abstrak tanpa ikatan dengan layanannya. Saya kemudian layanan CNAME ke hostname. Dengan begitu layanan migrasi tidak menyebabkan sakit kepala perubahan DNS. Atau setidaknya, tidak sebanyak. Saya juga lebih suka menamai server virtual dengan av yang didahului dengan nama host.

Contoh:

  • Server Database baru bernama Athena. Itu akan dinamai Athena selamanya.
  • Athena adalah CNAMED untuk apa yang dilakukannya: SQL08ENT-CRM, SQL08ENT-AEGIS (sistem keamanan), SQL08ENT-DOCMAN. Mungkin juga CNAMED berdasarkan geografi. Atau mungkin nama host akan memiliki geografi di dalamnya. Athena-ATL. Athena-Sydney. Apapun yang berhasil.
  • Server berada di server subnet yang memiliki kebijakan penolakan standar. Ini memiliki lalu lintas yang tepat termasuk dari subnet yang tepat.

Menjaga. Itu. Sederhana. (tapi fungsional)


1
Athena adalah Athena yang sudah menjadi kota ;-)
dmourati

+1: Amin pada yang sederhana + fungsional. Saya tidak berpikir tentang kebijakan tolak standar pada subnet sehingga saya harus memasukkannya. Saya tidak berpengalaman dalam CLI untuk switch jaringan (Netgear), tapi itu adalah sesuatu yang saya bisa mengetahuinya. Apakah Anda menggunakan kedua subnet DAN VLAN atau hanya satu dan bukan yang lain? Yang mana yang harus diutamakan?
osij2is

Jika saya bisa membesarkan hati Anda lagi, saya akan melakukannya. Inilah tepatnya mengapa saya mengajukan pertanyaan ini di sini: " Desain abstraksi ke dalam hal-hal, yang terdengar seperti itu tidak sederhana, tetapi sebenarnya adalah jalan menuju kesederhanaan itu sendiri ". Itulah tepatnya yang saya tuju. Untungnya Anda lebih fasih dan ringkas daripada saya. ;)
osij2is

1
@ osij2adalah saya tidak menggunakan banyak cara subnet atau VLAN karena saya sebagian besar kontraktor kantor kecil. Saya lebih suka menggunakan VLAN karena hanya itulah yang sebagian besar saya gunakan di masa lalu. Namun, saya bersedia dituduh sebagai palu-sindrom. Ketika semua yang Anda miliki adalah dot-one-q, semuanya tampak seperti masalah VLAN. Ya, satu lapisan abstraksi itu bagus. Selalu. Dua lapisan adalah lubang kelinci. Tiga lapisan adalah tanda penyalahgunaan LSD.
Wesley

1
@WesleyDavid - Re: Netgear, mereka jelas bukan pilihan TERBAIK, tetapi hal-hal "ProSafe" mereka dapat dikonfigurasi untuk melakukan 802.1Q (VLAN Tagged). Implementasinya adalah sesuai standar yang terbaik yang dapat saya tentukan: Ini berfungsi baik dengan vendor lain dan memungkinkan Anda fase penggantian dengan Juniper atau peralatan Cisco nanti jika waktu / dana memungkinkan. Kelemahan dengan hal-hal Netgear adalah itu benar-benar lebih diarahkan ke administrasi Web Browser daripada manajemen CLI, yang memperlambat admin bersih yang baik.
voretaq7

9

Saya bekerja di sebuah organisasi dengan ukuran yang sama (kami memiliki / 26), bahwa untuk alasan di luar saya, kekuatan-yang-merasa bahwa skema alokasi IP berbutir halus sangat penting untuk integritas operasional. Gateway harus 0,1, printer harus antara 0,2 dan 0,12, server antara 0,13 dan 0,20 dan seterusnya. Kami bahkan menyimpan dokumentasi di masing-masing host.

Ini adalah rasa sakit yang sangat besar di pantat. Tidak peduli seberapa rajinnya saya, saya tidak pernah bisa membuat dokumentasi tetap terkini. Itu tidak membantu bahwa kami tidak memiliki layanan DNS, jadi menggunakan dokumentasi skema alokasi IP ini adalah satu-satunya layanan "penamaan" yang kami miliki (yang dengan cara yang aneh, membuatnya tampak lebih diperlukan daripada yang sebenarnya).

Untuk jaringan ukuran Anda, saya akan merekomendasikan beberapa hal (yang sebagian besar sudah Anda lakukan):

  • Sederhana - Anda tidak mengelola ratusan host. Kompleksitas solusi Anda harus mencerminkan kompleksitas lingkungan. Tahan godaan untuk menjadi terlalu pintar. Anda akan berterima kasih pada diri sendiri nanti.

    1. Ambil ruang IP yang tersedia dan berikan 60% untuk klien Anda melalui DHCP. Menyiapkan beberapa jenis layanan DNS Dinamis sehingga Anda tidak perlu melihat alamat IP lagi. Lupakan tentang melacak mereka. Keuntungan.

    2. Cadangan 30% lainnya untuk alamat IP yang Anda kelola: server, printer, perangkat jaringan, layanan pengujian. dll. GUNAKAN DNS UNTUK DOKUMEN INI. Menurut pendapat saya, tidak ada pemborosan waktu yang lebih besar selain dengan rajin melacak semua alamat IP "yang dikelola administrator" ini (yang bertentangan dengan alamat IP yang dikelola DHCP) dengan menggunakan lembar bentang Excel (yang harus selalu Anda lihat dan pelihara) , ketika Anda bisa melakukan upaya itu untuk mendukung solusi DNS yang mendokumentasikan diri dan jauh lebih berguna.

    3. Biarkan 10% terakhir dari alamat Anda di bagian atas ruang alamat IP Anda tidak digunakan. Cadangan kecil tidak pernah sakit.

    4. Sesuaikan rasio sesuai keinginan Anda untuk lingkungan Anda. Beberapa lingkungan akan memiliki lebih banyak klien, beberapa akan menjadi "server" (yaitu, "dikelola-administrator") berat.


  • Layanan jaringan (mail, file, proxy, dll.)
  • Pengembangan perangkat lunak (lingkungan - dev / staging / prod,

Keduanya termasuk dalam kategori ruang IP "yang dikelola administrator".

  • Media (streaming, transfer file besar, pengarsipan)

Menurut pendapat saya ini tidak ada hubungannya dengan subnetting dan semuanya ada hubungannya dengan pemantauan jaringan.

  • Server virtual / desktop

Servernya "dikelola-administrator", desktop (yaitu mesin klien) harus "dikelola-DHCP".

  • VoIP

Jaringan diskrit fisik akan ideal ... tapi itu tidak realistis. Hal terbaik berikutnya adalah VLAN dan subnet terpisah. Ini adalah satu-satunya titik di jaringan kecil di mana saya benar-benar merasa perlu untuk memisahkan lalu lintas (kecuali untuk hal-hal yang dapat diakses publik).


2
Kata-kata. Suara positif. Oh, tunggu, ini bukan Reddit. Pokoknya, "Tahan godaan untuk menjadi terlalu pintar." Dikutip untuk kebenaran!
Wesley

5

Untuk alokasi IP

Saran saya adalah menempatkan semuanya di bawah subnet 10.0.0.0/8, menggunakan struktur berikut: 10 site.. division.device

  • site adalah lokasi fisik atau yang setara secara logis (mis. kantor NY, kantor NJ, fasilitas DR, lingkungan Pengembangan).
  • divisionadalah pembagian logis yang masuk akal bagi Anda. mis.
    0 => Switch / Router
    1 => Admin, 2 => Pengguna
    3 => VOIP
    4 => Tamu
  • devices adalah perangkat individual (PC, server, telepon, sakelar, dll.)

Idenya di sini adalah Anda dapat dengan mudah menentukan apa perangkat itu dan di mana alamatnya: 10.2.1.100 adalah stasiun kerja administrator di "Situs # 2".

Model ini berasal dari penugasan IP berbasis kelas: Kelas A (/ 8) adalah perusahaan Anda. Setiap lokasi mendapat Kelas B (/ 16), dan setiap divisi logis di lokasi mendapat Kelas C (/ 24) untuk perangkat mereka.
Dimungkinkan (dan kadang-kadang diinginkan) untuk menggunakan sesuatu yang lebih besar dari / 24 untuk tingkat "divisi", dan Anda tentu dapat melakukannya: Apa pun dari / 17 ke / 24 umumnya permainan yang adil dengan skema ini.


Untuk Nama DNS

Saran saya adalah mengikuti skema serupa dengan penugasan IP yang saya jelaskan di atas:

  • Semuanya berakar di mycompany.com
  • Setiap situs (/ 16) memiliki sitename.mycompany.comsubdomain sendiri .
  • Divisi logis mungkin memiliki satu (atau lebih) subdomain di dalam situs, misalnya:
    • voip.mycompany.com(dengan perangkat seperti tel0000.voip.mycompany.com, tel0001.voip.mycompany.com, dll)
    • switches.mycompany.com
    • workstations.mycompany.com (mungkin dibagi lagi menjadi admin, pengguna & tamu)
  • Perangkat harus memiliki nama yang bermakna. Sebagai contoh:
    • Beri nama ponsel sehingga Anda dapat melihat ekstensi yang berdering berdasarkan nama DNS.
    • Beri nama workstation berdasarkan pengguna utama mereka.
    • Identifikasi dengan jelas alamat IP "tamu".
    • Beri nama server sehingga Anda dapat mengetahui apa itu / apa yang mereka lakukan.
      Hal ini dapat dicapai dengan menggunakan "membosankan" nama ( www01, www02, db01, db02, mail, dll) atau dengan menyebarkan skema penamaan dan berpegang teguh pada itu (misalnya: server Mail dinamai batu, server web dinamai pohon, server database yang dinamai setelah pelukis).
      Nama membosankan lebih mudah dipelajari orang baru, skema penamaan keren lebih menyenangkan. Ambil pilihanmu.

Catatan Lain-lain

Mengenai server virtual:
Pertimbangkan ini sama seperti jika mereka adalah mesin fisik (pisahkan dengan divisi / tujuan daripada oleh fakta bahwa mereka "virtual". Punya divisi terpisah untuk jaringan Administrasi Hypervisor / VM.
Ini mungkin terlihat penting kepada Anda sekarang untuk mengetahui apakah sebuah kotak itu virtual atau fisik, tetapi ketika sistem pemantauan Anda mengatakan "Hei, Email turun!" pertanyaan yang akan Anda tanyakan adalah "Mesin mana yang terkait dengan email?", bukan "Mesin mana yang virtual dan mana yang fisik? ".
Perhatikan bahwa Anda TIDAK memerlukan cara praktis untuk mengidentifikasi apakah mesin itu virtual atau fisik seandainya host hypervisor meledak, tetapi ini merupakan tantangan bagi sistem pemantauan Anda, bukan arsitektur jaringan Anda.

Mengenai VOIP:
VOIP (asterisk khususnya) adalah sinonim untuk "Lubang Keamanan". Dorong semua barang VOIP Anda ke subnetnya sendiri, dan VLAN-nya sendiri, dan jangan biarkan itu berada di dekat sesuatu yang sensitif.
Setiap telepon VOIP yang saya lihat pada tahun lalu mendukung segregasi VLAN (bahkan semuanya mendukung VLAN suara dan data, sehingga Anda masih dapat menggunakan telepon sebagai pass-thru untuk koneksi ethernet desktop). Manfaatkan ini - Anda akan senang jika / ketika lingkungan VOIP Anda diretas.

Mengenai Perencanaan dan Dokumentasi:
Gambar jaringan Anda di atas kertas sebelum Anda mulai menetapkan alamat dan nama DNS. Bahkan, gambarkan dengan pensil di atas selembar kertas BESAR terlebih dahulu.
Buat banyak kesalahan.
Hapus dengan bebas.
Kutukan dengan lancar.
Setelah Anda berhenti mengutuk dan menghapus setidaknya 10 hari, saatnya untuk meletakkan diagram ke Visio / Graffle / Beberapa format elektronik lainnya sebagai diagram jaringan resmi Anda. Lindungi diagram ini. Pertahankan dalam Koreksi Mahakudus saat Anda menambah dan menghapus perangkat, menumbuhkan organisasi Anda, dan memodifikasi struktur jaringan Anda.
Diagram jaringan ini akan menjadi teman terbaik Anda ketika Anda harus membuat perubahan, menjelaskan jaringan kepada admin baru, atau memecahkan masalah kegagalan misterius.


Perhatikan bahwa saya membuat asumsi Anda akan ke NAT - terutama karena saya membuat asumsi Anda akan ingin memiliki> 1 situs dan ingin VPN di antara mereka.
voretaq7

+1: Saya suka penggunaan oktet dan korelasinya dengan lokasi (dan / atau virtualisasi seperti yang Anda sebutkan). Ini dapat diperluas ke divisi logis yang berbeda, tetapi gagasan itu masuk akal. Juga untuk info tentang VoIP.
osij2is

Hal oktet memecah ketika Anda memiliki> 200 atau lebih perangkat - itu bisa membatasi jika Anda memiliki 1000 orang di kantor dan semuanya memiliki telepon IP di meja mereka. Peringatan kecil yang harus diperhatikan :-)
voretaq7

@ vortaq7: Saya menganggap hal itu tetapi masih bagus untuk dicatat. Either way, menggunakan IP sebagai cara mengatur hal-hal secara logis dan fisik itu bagus. Juga, poin bagus dari virtual vs fisik secara praktis tidak relevan. Sangat menyenangkan untuk diatur tetapi imbalan untuk pemisahan ini sangat kecil.
osij2is

@ osij2is - Virtual vs Physical pasti relevan, saya hanya tidak berpikir infrastruktur jaringan adalah tempat untuk merekamnya (atau jika Anda harus melakukannya, lakukan dengan DNS dengan membuat catatan A atau CNAME yang terpisah seperti app01.hypervisor02.site.mycompany.com). Sistem pemantauan yang dipikirkan secara matang dan diterapkan adalah hal penting kedua (setelah organisasi jaringan) di lingkungan apa pun yang Anda pedulikan.
voretaq7
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.