webshostcom1

webshostcom1

webshostcom1

webshostcom1

چیزهای که باید در مورد Replication در ساختار Directory Service بدانید

معمولا در محیطهای که بیش از چند Domain Controller وجود دارد برای بالا بردن Availability و دسترسی به اطلاعات بین چند DC از Replication یا همگان سازی استفاده می شود. در این مقاله قصد ندارم درباره کل پروسه Replication توضیح بدم و اینکه چگونه این پروسه بین DC ها ایجاد و جریان پیدا می کند. فقط نکات مهم این پرسه را برسی میکنیم
یک سوال مهم چرا ما به Replication نیاز داریم؟
در ساختار Directory Service یکسری اطلاعات مجزا مربوطه به قسمتهای مختلف Directory Service در کانتینریهای به نام Partition نگهداری می شوند. در یک Forest چندین پارتیشن داریم که بعضی از آنها در محدوده کل فارست باید اعمال شود و بعضی ها در محدود Domain. و اما پارتیشن ها:
Domain directory partition: Also known as the domain naming context (NC), contains domain-specific objects such as computer, user, and group accounts.
Configuration directory partition: Contains forest-wide data that controls site and replication operations.
Schema directory partition: Contains schema definitions for the forest.
Application directory partitions: Contain data that is particular to specific applications. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of domain.
بعضی از اطلاعات باید در کل Forest یکسان باشد و بعضی از آنها در یک دومین. همه Domain Controller ها در هر نقطه ای که باشند باید به این اطلاعات دسترسی داشته باشند. و این اطلاعات بوسیله Replication بین DC ها Sync می شوند. علاوه بر پارتیشن های بالا یکسری ابجکیت، سرویس ها و Role ها داریم که نیازمند Replication هستند مانند:

    Universal groups
    PDC emulator
    Global Catalog

etc.
نکته: Replication از سرویس FRS and DFS برای انتقال اطلاعات بین DC ها استفاده می کند. اگر FFL شما از Windows server 2003 به پایین باشد از FRS استفاده می شود ولی اگر FFL از Windows server 2008 به بالا باشد از DFS استفاده می کند.
DCها میتواند در یک Site یا چندین سایت در چندین نقطه جغرافیائی با همدیگر فعالیت کنند. شاید برای شما مهم باشه که در ساختار Directory Service سایت را چگونه تعریف می کنند؟
سایت در ساختارDirectory Service یک محدود جغرافیائی جدا می باشد که دارای Subnet یا Subnet های جداگانه ای هستش که با لینکهای پر سرعت به هم دیگر وصل می باشند. ممکن است شما در یک سایت چندین Domain داشته باشید یا یک Domain در چندین سایت باشد. که در این صورت مدیریت و بهینه سازی Replication دومین کنترول ها بین سایتهای مختلف مهمترین نقش طراح یا ادمین شبکه می باشد.
Intra-site Replication
اینگونه Replication درون یک سایت و بین Domain Controller های آن سایت اتفاق می افتد. وقتی تعقیری بر روی یکی از DC ها ایجاد شود DC ها بوسیلهChange Notifications به بقیه اعلام می کنند که ها ولک بیا ببین چی داروم اونا هم میان و خودشون رو بر روز می کنند.
نکته: وقتی می گوئیم یک DC می خواهد با DC دیگر Replication کند Replication در اینجا به معنی درخواست می باشد. و در پروسه Replication تمام درخواستها بصورت Pull هستند یعنی گرفتنی ، کشیدنی و DC مقصد اطلاعات را به DC مبدا ارسال می کند.
درون یک سایت ارتباطات ساختار بوسیله پروسه KCC یا Knowledge Consistency Checker بصورت اتوماتیک ایجاد می شود و KCC کانال ارتباطی یک DC با DC دیگر را بوسیله شیء به نام Connection object ایجاد می کند. Connection object ها همیشه بصورت Incoming Connection هستند.
Image

DC های بویسله پارامترهای زیر Replication را مدیریت می کنند:

    Update Sequence Numbers
    High-watermark values
    UP-TO-Dateness vectors
    Change Stamps
    Polling

برای کسانی که می خواهند لیاقت لغب Microsoft Ensnaring را داشته باشند باید با ریزترین اشیاء در این ساختار اشنا باشند.
نکته: Replication درون یک سایت بر اساس تعقیراتی هستش که بر روی DC ها ایجاد می شود، اتفاق می افتد. اگر تعقیری در DC ی ایجاد شد DC 15 ثانیه صبر خواهد کرد ( به این تاخیر Intial Notification Delay می گویند) و منتظر می ماند که اگر تعقیری دیگه ای وجود داره ایجاد بشه تا یکباره همه اطلاعات را Replicate کنه. بعد از replicate 3 ثانیه صبر خواهد کرد (این تاخیر را Subsequent Notification Delay می نامیم) واطلاعات را برای DC دیگر ارسال می کند.
Inter-site Replication
این نوع Replication بین سایتهای Directory Service اتفاق می افتد. این Replication بر خلاف Intrasite بر اساس Schedule یا زمان بندی اجرا خواهد شد. مثلا اگر تعقیری در DC یکی از سایتها ایجاد شود بر اساس زمان بندی که انجام دادیم Replication برای Bridgehead Server ها ارسال خواهد شد. علاوه بر خاصیت Schedule ما گذینه دیگری به نام Replication Period داریم که تعداد تکرار Replication بر اساس زمانی که تعیین کردیم را مشخص می کند. که بصورت پیش فرض ,Replication Period 180 دقیقه معادل 3 ساعت می باشد.
هنگام replication بین سایتها پروسه KCC بصورت اتوماتیک در هر یک از سایتها یک نماینده انتخاب می کند. که وظیفه این نماینده دریافت Replication ار بقیه سایتها می باشد و انتشار آن بین DCهای سایت می باشد. همه این نماینده را با نام Bridgehead Server می شناسن.
نکته: پروسه KCC و مولفه آن یعنی Intersite Topology Generator کانکشنهای لازم (Connection object) بین سایتها را بصورت اتوماتیک ایجاد می کند. ISTG کانکشنها را بر اساس Site Link ها ایجاد می کند.
Image

گفتیم که Bridgehead ها توسط KCC انتخاب می شوند. در شرایطی ما می توانیم این نقش را به سروری دیگری واگذار کنیم. برای اینکار لینک زیر را مطالعه کنید:
Designate a Server as a Preferred Bridgehead Server

https://technet.microsoft.com/en-us/library/cc794778(v=ws.10).aspx

نکته: در سازمانهای خیلی بزرگ که حجم Replication زیاد می باشد میتوانید این مسئولیت را بین چندین DC واگذار کنید. و اگر یکی از این DC ها Down شد KCC یکی را به دلخواه انتخاب می کند.
بحث جایگزین شدن DC دان شده بین سایتها بحث خییییلی مهمی می باشد که خارج از بحث این مقاله می باشد. حتما لینکهای که در آخر مقاله ضیمیه می کنم را بخوایند.
بحث دیگری که در Inter-Site وجود دارد بحث Replication Latency می باشد. Replication Latency مدت زمانی می باشد که "یک تعقیر بر روی دیگر DC ریپلیکت شود" اشاره دارد. مشخص کردن Replication Latency درون یک سایت خیلی سادس که در حالت نورمال کمتر از2 دقیقه می باشد. (بستگی به Node ها و سرعت ارتباط آن سایت دارد) ولی محاسبه این زمان بین سایتها کمی دشوار هستش در ابتدا باید مدت زمان رسیدن تعقیرات از DC مبدا به Bridgehead Server محاسبه شود و مدت زمانی که این Replication به دست Bridgehead Server مقابل برسد و همچنین فاکتورهای مانند Schedule و Replication Period در این محاسبه دخیل هستند. که بصورت پیش فرض وقتی یک تعقیر در یک سایت ایجاد شود در مدت زمان 3 ساعت 4 دقیقه این تعقیرات بر روی دیگر DC ها سایت مقابل اعمال می شود. (شما دستون بازه می تونید این تنظیمات را تعقیر دهید).
شکل زیر را نکاه کنید:
Image

فرض کنید Schedule را بصورت تمام وقت تنظیم کردیم و Replication Period را بر روی 15 دقیقه ست کردیم. پس زمان دقیق convergence شدن اطلاعات بصورت زیر محاسبه می شود:

A to B = 15 min + B to C = 30 min + C to D = 45 min

علاوه بر محاسبه Replication Period ما تاخیر 15 ثانیه ای هم داریم که در کل تقریبا 105 ثانیه می باشد.
نکته خیلی مهم: همیشه Schedule and Replication Period همه Site Linkها (امکانش باشد) باید یکسان باشند.
در برخی از موارد یکسری تنظیمات داریم که با چنین مدت زمانی 45 دقیقه ای واقعا دردسر سازه مثلا یکی از کاربران انکانتش Lock شود. این بدبخت 45 دقیقه معطل شود!!! درضمن بعضی از تنظیمات امنیتی باید در کمترین زمان ممکن به دست دیگر DC برسد. این تنظیمات:

    Account Lockout Policy
    Domain Password Policy
    RID Master Moving
    Local Security Authority

برای حل این مشکل ما از Urgent Replication استفاده می کنیم. این نوع Replication همه تنظیمات Schedule and Replication Period را نادیده می گیرند. و تنظیمات بالا را به دست بقیه می رساند.
خانمها یک نمونه بارز از این نوع replication هستند. ://
Understanding Urgent Replication

https://blogs.technet.microsoft.com/kenstcyr/2008/07/05/understanding-urgent-replication/


همچنین یک قابلیتی وجود داره به نام inter-site change notifications که اگر تعقیری در یکی از DC ایجاد شد این تعقیر کمتر از 3 دقیقه می تواند به DC های دیگر سایتها اعمال شود. در مورد آن تحقیق کنید.
Site Link
بصورت فیزیکی هر یک از سایتها را بوسیله اتصالات Broadband به هم دیگر متصل می کنند. Site Link مسیر ارتباطی یک سایت با سایت دیگر را مشخص می کند و همچنین مسیر Replication را هم تعیین می کند (Replication Path). در کنسول AD Site and Service سایت لینکها را بر اساس دو پروتکل انتقال:

    IP or DS-RPC
    SMTP or ISM-SMTP

تنظیم می کنند. که اولویت با IP می باشد. SMTP در مواقعی استفاده می شود که لینک ارتباطی ما با شعبه دیگر Stable یا غیر قابل اعتماد باشد. همچنین SMTP نیاز به ساختار PKI دارد. وهمچنین نمی توان برای یک دومین از این پروتکل انتقال استفاده کرد. هر کدام از این لینکها دارای خاصیتی به نام Cost هستند. وظیفه Cost تعیین مسیر Replication بین سایتها می باشد و در خیلی از موارد مورد استفاده قرار می گیرد. زمانی که شما یک forest ایجاد می کنید یک site link به نام DEFAULTIPSITELINK بصورت پیش فرض ایجاد می شود. اگر شما چندین سایت داشته باشید و Site Linkی ایجاد نکنید KCC فرض می کند همه ی این سایتها با این Site Link وصل هستند و در صورت عدم ایجاد Site Link عملیات replication با مشکل مواجه می شود.
یکی از مشخصات مهم Site Link ها transitive بودن آنها می باشد. یعنی اگر ما سایت A, B and C داشته باشیم و سایت A و B را بوسیله Site Link متصل کرده باشیم و همچنین B به C سایتها A و C بدون نیاز به داشتن Site Link می توانند با هم دیگه Replicate کنند.
Site Link Bridges
یکی از مهترین پارمتر در تنظیمات AD Site and Service می باشد. Site Link Bridges مجموعه ای از Site Linkها می باشد که همه سایتها را به هم وصل میکند حتی سایتهای که بهم دیگر لینک نباشند!!! تصویر زیر را ببینید:


در تصویر بالا ما سه سایت داریم که بصورت Hup and Spoke می باشند. همه سایتها به شعبه اصلی وصل هستند و سایتهای Milan and Atlanta هیچگونه Site Linkی ندارند ولی چون Site Link Bridge بر روی این دو Site Link فعال می باشد این دو سایت می توانند با هم دیگه اطلاعات خود را replicate کنند. قابلیتی که باعث میشه Site link bridge این هنرنمائی را انجام دهد خاصیت transitive بودن Site Link Bridge ها می باشد.
نکته: بصورت پیش فرض Site Link Bridge بر روی Site Linkها فعال می باشد.
نکته: اگر سایتهای شما not fully routed, هستند (یعنی از Atlanta قادر نباشید Milan سایت را پینگ کنید) باید خاصیت Bridge all site links را بر روی Site Link ها غیر فعال کنید و در شرایطی باید یک Site Link Bridges بصورت دستی ایجاد کنید.
Image

نکته: اگر 20 سایت داشته باشید که 19 تا از این سایتها full route باشند و یکیشون full route نباشه مجبورید Bridge all site links را بر بصورت کامل غیرفعال کنید.
And even if you have 20 sites all fully routed EXCEPT for one of them, then the same thing goes. You must disable it all because of that one site,
یک نمونه از یک ساختار Full Route :


یک نمونه از یک ساختار Not Full Route :


در تصویر بالا برای اینکه شعبه ها بتوانند با هم دیگر replicate کنند باید Bridge Site Link را غیر فعال و یک Bridge Site Link دستی ایجاد کنید. ایجاد یک Bridge Site Link مانند ایجاد یک Route بر روی یک Router می باشد. به عکس بالا نگاه کنید چهار سایت وجود دارد که بصورت Hup and Spock می باشد به نظر شما Bridge Site Link را چگونه ایجاد کنیم که همه بتوانند با هم دیگر replicate کنند؟؟؟؟
در بالا سه عدد site link وجود دارد:

    NYC-TO-SEATTEL
    NYC-TO-CHICAGO
    NYC-TO-MIAMI


اگر به Site Link ها نگاه کنید یکی از سایتها در همه Site Link ها مشترکه و آن هم سایت NYC می باشد. پس NYC مثل یک روتر عمل می کند و replicate سایتها را بین آنها منتقل می کند.
این یک قانونه که وقتی شما یک یا چند Bridge site link ایجاد می کنید با یکی از سایتها در کل Site Link ها وجود داشته باشد.
Each site link in a bridge must have at least one site in common with another site link in the bridge.
Image

خب الان چند سناریو میگیم و با هم تجزیه و تحلیل می کنیم. سناریوی اول:


خوب به این سه سایت توجه کنید:

    همه آنها زیر مجموعه یک دومین فعالیت می کنند.
    همه DC ها نقش GC بر روی آنها فعال شده است.
    این سه سایت Full Route نیستند.
    دو عدد Site Link برای ارتباط این سه سایت استفاده شده .

الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟
تنها کاری که باید انجام دهیم غیر فعال کردن Bridge all site links هستش. همین و بس...
چطور!!!!!!؟؟؟؟؟؟
چون ساختار full route نیست ما Bridge site link را غیر فعال می کنیم. چرا یک Bridge site link نساختیم؟؟؟؟ چون هر سه سایت یک دیتای مشترک را نگهداری می کنند (یک دومین می باشد) در مثال بالا فرض کنید سایت NYC تعقیراتی ایجاد کرد، این تعقیرات در زمان معین با Bridgehead Server سایت SEA ریپلیکت می شود و در مرحله آخر سایت DFW از تعقیرات با خبر می شود و خود را با SEA سینک می کند.
سناریوی دوم:


چی می بینید؟؟؟؟

    سه عدد سایت با دو دومین با نام های Reskit.com و Noam.reskit.com
    ساختار Full Route می باشد.
    DC های سایت NYC and DFW نقش GC بر روی آنها فعال شده است. ولی DC های سایت SEA نه.

الان تنظیمات Site Link ها را چگونه انجام دهیم که سه شعبه بتوانند با هم دیگه replicate کنند؟؟؟
این سایتها با دور روش می توانند با هم دیگر Replicate کنند:

    فعال بودن Bridge site link و استفاده از خاصیت transitive بین لینکها.
    غیر فعال کردن Bridge site link بر روی لینکها و ایجاد یک Bridge site link دستی.

بنظر شما چرا علاوه بر غیر فعال کردن Bridge site link باید یک Bridge site link دستی ایجاد کنیم؟؟؟
بخاطر اینکه دومین سایت SEA با بقیه فرق می کند و این دوسایت اطلاعات مختلفی را نگهداری می کنند پس بخاطر همین دلیل غیر فعال کردن Bridge site link نمی تواند موثر باشد. در نتیجه ما مجبوریم یک Bridge site link دستی ایجاد کنیم. در سناریوی بالا ایجاد Bridge Site Link بصورت دستی برای سایت NYC یک Route به سمت DFW از طریق سایت SEA ایجاد می کند که پروسه KCC بتواند طبق این مسیر Connection Object خود را ایجاد و اطلاعات خود را با سایت DFW بروز رسانی کند.
Image

در مقاله بعدی سناریوی که در اینجا طرح کردم را برسی می کنیم. و قابلیتهای جدیدی را معرفی می کنیم که دانستن آن برای هر Microsoft Ensnaring لازم و ضروری هستش.
منابع:

Managing Replication Between Sites

https://technet.microsoft.com/en-us/library/cc961783.aspx

AD Site Design and Auto Site Link Bridging, or Bridge All Site Links (BASL)

http://blogs.msmvps.com/acefekay/2013/02/24/ad-site-design-and-auto-site-link-bridging-or-bridge-all-site-links-basl/

How Active Directory Replication Topology Works

https://technet.microsoft.com/en-us/library/cc755994(v=ws.10).aspx

سولوشن مناسب برای پیاده سازی سناریوی زیر

چند روز پیش سناریوی که در دنیای واقعی بیشتر با آن رو به رو شده ایم را در این انجمن مطرح کردم که بنا به دلایلی کسی رغبت به حل یا ارائه یک سولوشن مناسب دراین سناریو نداشته است. من هم بخاطر این جمله معروف "می نویسم تا همه بخوانند؛ شاید کسی چیزی یاد بگیرد و یا استادی اشتباه مرا بگیرد." تصمیم گرفتم طبق Best Practice های مایکروسافت پیش برم و یک سولوشن مناسب برای این سناریو معرفی کنم.
نکته: این مقاله در دست تعقیر می باشد. در صورت دادن یک سولوشن مناسب (با دلیل و لینک) سولوشن شما جایگزین می شود.
و اما سناریو:


به تازگی شرکت ما سه شعبه دیگر با آن اضافه شده است تیم IT بعد از طراحی و پیاده سازی ساختار را بدین شکل پیاده سازی کرده اند:(همه دلایل فنی در نظر گرفته شده است) در سایت اصلی و Branch office -02 ما DC های از نوع WRDC داریم ولی بخاطر نکات امنیتی یک RODC در Branch office -01 را اندازی کردیم. بعد از نصب و راه اندازی ساختار (اماده بودیم که ژست خدائی بگیریم که ما خدای بلا منازع شبکه و ..... هستیم که) دیدیم Replication بین Branch office 01 و Branch office -02 انجام نمی شود؟؟؟؟ سایت اصلی می تواند با Branch office-02 ریپلیکت کند و برعکس و همچنین Branch office-03 بدلیل تعداد کم یوزر (در حدود 7 تا یوز) DC وجود ندارد و مشکلی از این بابت نداریم. تنها مشکلی که داریم Branch office-01 نمی تواند با Branch office-02 ریپکلت کند!!!!!؟؟؟؟ ما را در یافتن این مشکل راهنمائی کنید؟ همچنین اگر مایل بودید نظر خود را درباب Branch office-03 بگوید در آنجا DCی نصب کنیم یا خیر (چگونه آن را طراحی کنیم دلیل مناسبی دهید که بتوان با مدیریت حرف زد و توپولوژی را تعقیر داد)
جزئیات بیشتر:
Forest Name= Corp.VSP.COM
Branch Office-02= Shiraz.Corp.VSP.Com

    تمام سایتها از طریق یک لینک پر سرعت به هم دیگر وصل می باشند.
    یوزرهای سایت 3 باید به منابع این سازمان درسترسی داشته باشند.
    ساختار بصورت Hup and Spock می باشد و شعبه های 1، 2 هیچگونه ارتباط با هم دیگه ندارند و تنها با سایت اصلی در ارتباط هستند.

از شعبه سوم (Branch office-03) شروع می کنیم:
برای این شعبه دو احتمال وجود داره:

    یوزرهای مهمی برای سازمان هستند. مانند کارشناسان- مدیر پروژه یا پرسنل امور حسابداری که به عنوان یک قطب برای این سازمان فعالیت می کنند.
    یوزرهای عادی می باشند که طبق وظیفه ای که دارند بطور ثابت در یک جا مستقر نیستند و گاهی وقتا در سایت اصلی یا سایت 2 فعالیت می کنند.

برای هر یک از این احتمالات سولوشن های جداگانه ای وجود دارد.
احتمال اول:
چون این 7 یوزر کاربرهای مهمی هستند (زورشون زیاده با یک نامه به رئیس شما رو خفت می کنن :[) باید سعی کنیم دسترسی آنها به منابع و... سریع و Stable باشد. پس در نتیجه ایجاد یک RODC و همچنین یک File سرور در این شعبه گذینه مناسبی می باشد. ولی هزینه راه اندازی این چند سرویس بر روی سرور و همچنین نگهداری از آنها می تواند هزینه آن سازمان را افزایش دهد. برای مسئله سرور هر چند می توان از PC Server و قابلیت مجازی سازی استفاده کرد که تا حدودی در هزینه صرفه جوئی شود. ولی مشکلی که PC ها دارند بعد از چند روز یا چند ماه فعالیت یک قطعه از آنها می سوزد ( چه فشار روی این سرور باشد چه نباشد) که در نتیجه PC Server گذینه مناسبی نمی باشد. شاید در این شرایط بتوان از MicroServer های HP استفاده کرد.


http://www.storagereview.com/hp_proliant_microserver_gen8_review

اگر دسترسی و پایداری اطلاعات برای آن 7 نفر مهم باشد و این امر با خریدن سرور به انجام می رسد حتما باید این مسئله را در جلسه ای که با مدیران آن سازمان ایجاد می شود مطرح کنید. اگر مدیریت با این هزینه توافق نکرد چی؟؟؟ سادس باید از روشها و قابلیتهای استفاده کنیم که خلع این سرور را پرکند و تا حدودی دسترسی به اطلاعات با سرعت زیاد وهمچنین استفاده از امکانات سازمان را برای آنها فراهم کند.
Automatic Site Coverage process
معمولا DC ها مشخصات سایت خود و بقیه پرامترهای خود را در DNS ثبت می کنند (با استفاده از سرویس Net Logon و ثبت رکورد SRV متناسب) تا کلاینتها به DCهای سایت خودشان Log on کنند و خود را در ساختار احراز هویت کنند. اگر در سایتی DC ی وجود نداشته باشد DCهای سایت مقابل (نزدیکترین DCهای یک سایت بر اساس Cost مربوط به Site Link می شخص می شود) آمادگی خود را برای احراز هویت چنین کاربران بدون سرپرست و یتیم :// ( سایتی که DCنداشته باشد) اعلام می کنند. در نتیجه کاربران سایت 3 می توانند به DC های سایت دو متصل و احراز هویت شوند. به این روش automatic site coverage می گویند.
Sites Sites Everywhere…

https://blogs.technet.microsoft.com/askds/2011/04/29/sites-sites-everywhere/

Offline Domain Join (Djoin.exe)
اگر لینک ارتباطی سایت 3 با سایت 2 کم سرعت و ضعیف باشد می توان از قابلیت Offline join استفاده کرد. و آنها را عضو Domain کرد.
Offline Domain Join (Djoin.exe) Step-by-Step Guide

https://technet.microsoft.com/en-us/library/offline-domain-join-djoin-step-by-step(v=ws.10).aspx

تا اینجا تونستیم این 7 کاربر را عضو دومین کنیم. شاید یکی بپرسه چه لزومی داره این 7 کاربر عضو دومین باشن؟؟؟ اگر کاربری نتواند Session Ticket ی که در پروسه Kerberos هستش دریافت کند نمی تواند به منابع آن سازمان دسترسی داشته باشد.(آن سازمان دسترسی ها را بصورت متمرکز و فقط برای کاربران Active Directory ست کرده اند) مسئله بعدی دسترسی کاربران سایت 3 به فایلهای سازمانی بر روی سایت 2 یا سایت 1 چگونه می باشد؟؟؟ این مسئله را چگونه حل کنیم؟؟؟؟ بازم سادس استفاده از قابلیت BranchCache!!!!!!
BranchCache
این قابلیت باعث می شود کلاینتها به فایلهای که در سایتهای دیگری میزبانی میشوند استفاده و کش کنند. این روش دومزیت دارد:

    دسترسی سریع به منابع.
    بهینه سازی ترافیک بین سایت 3 و سایت 2
    BranchCache™ is designed to reduce WAN link utilization and improve application responsiveness for branch office workers who access content from servers in remote locations. Branch office client computers use a locally maintained cache of data to reduce traffic over a WAN link.

BranchCache در دو مد ارائه شده:

    Distributed Cache mode
    Hosted Cache mode

در مد Distributed Cache mode اگر یکی از کاربران فایلی از فایل سرور که در سایت 2 می باشد دریافت کند، آن فایل را کش می کند و اگر کاربر دیگری آن فایل را نیاز داشت آن را از آن کلاینت قبلی دریافت می کند و نیازی نیست آن را مستقیما از فایل سرور دانلود کند.


ولی در مد Hosted Cache mode ما نیاز به یک سرور داریم که محتویات دانلود شده از شعبه اصلی در آن ذخیره می شود و کاربران از آن سرور استفاده می کنند.


ما در این سناریو از مد Distributed Cache mode استفاده می کنیم که خیلی کارآمد و مناسب می باشد. همچنین مایکروسافت برای چنین محیطهای آن را توصیه می کند:
For branch offices with fewer than 50 users, BranchCache can be configured in Distributed Cache mode.
BranchCache in Windows 7 and Windows Server 2008 R2 Overview

https://technet.microsoft.com/en-us/library/dd755969(v=ws.10).aspx

فرض کنید این 7 کاربر یک برنامه حسابداری یا مالی یا هر چیز دیگری دارند که باید به آن دسترسی داشته باشند. این مشکل را چگونه حل کنیم!!!؟؟
برای این مشکل هم راه حلهای وجود دارد مانند استفاده از قابلیت Remote App
Remote App
فکر کنم همه یک اشنائی جزئی یا کامل از این قابلیت داشته باشند. Remote App باعث میشه کاربران سایتهای دیگر یک برنامه وب بیس را از روی سروری بر روی کامپیوتر (کنسول) خود فراخوانی کنند و از آن استفاده کنند.
RemoteApp enables you to make programs that are accessed remotely through Remote Desktop Services appear as if they are running on the end user's local computer.
Overview of RemoteApp

https://technet.microsoft.com/en-us/library/cc755055(v=ws.11).aspx

ولی مسئله خریدن لایسنس برای هر RDP Session می تواند مانع شود از این سرویس استفاده کنیم. و مجبوریم از برنامه های دیگری استفاده کنیم که بتوان لایسنس آنها را دور زد. (فقط شانس بیارم مقالم حذف نشه :/) یکی از بهترین برنامه های که در این زمینه میشه استفاده کرده برنامه TSPlus می باشد.
Image

از مهندس اسحاقی عزیز تشکر می کنم که این برنامه جالب و قدرتمند را معرفی کردند. برای این موضوع شاید انتخابهای زیادی وجود داشته باشه مثل XenApp and XenDesktop و ... ولی تمام این قابلیتها بستگی به این دارد که آن برنامه مالی وب بیس باشد و با چنین تکنولوژی های همخوانی داشته باشد. تا اینجا ما راه حلهای که مناسب شعبه سوم هستش را مطرح کردیم. اگر برای این شعبه شما سولوشن بهتری سراغ دارید خوشحال میشم در قسمت نظرات آن را اعلام کنید. بریم سر بحث Replication سایت 1 و سایت 2 :
مشکلی که وجود داشت عدم Replication شدن اطلاعات بین DC های سایت 1 و 2 بود. در ابتدا بگم که موضوع Replication هیچ ربطی به RODC سایت 1 ندارد چون RODC یک Replica از اطلاعات DC دیگر می باشد و همیشه تعقیرات را از Partner خود دریافت می کند و بر روی RODC هیچگونه تعقیری ایجاد نمی شود که لزومی داشته باشد بقیه DC با آن Replicate کنند.در سناریوی فوق وقتی تعقیری بر روی DC های سایت 2 انجام شود این تعقیرات به DC های سایت اصلی Replicate می شود. و در آخر RODC این تعقیرات را از Partner خود دریافت می کند. خروجی دستور repadmin /showrepl بر روی RODC :


خب الان فرض کنید بجای RODC در سایت 1 یک دومین با نام
Mahshaher.Corp.VSP.Com
داشته باشیم. ایا الان این سه دومین می توانند با هم دیگر Replication کنند؟ جواب خیر می باشد. با تنظیمات پیش فرض، Replication بین سایت 2 و سایت 1 به هیچ وجه انجام نمی شود. و ما مجبوریم قابلیت Bridge All site link را بر غیرفعال کنیم (not full route) برای اطلاع بیشتر درباره Bridge Site Link مقاله زیر را مطالعه کنید: (بیشتر تنظیمات این قسمت را در لینک زیر توضیح دادم)
مقاله: چیزهای که باید در مورد Replication در ساختار Directory Service بدانید
نمونه ای از تنظیمات AD Site and Service برای این سناریو:


خروجی دستور repadmin /showrepl بر روی DC های سایت اصلی:


خروجی دستور repadmin /showrepl بر روی DC های سایت 1:


خروجی دستور repadmin /showrepl بر روی DC های سایت 2:


همچنین ارتباطات Replication را توسط ابزار Active Directory Replication Status Tool تست کردم. این ابزار را می توانید ازلینک زیر دانلود کنید:

https://www.microsoft.com/en-us/download/details.aspx?id=30005

این ابزار را بر روی DCهای سایت 2 تست کردم و Destination DC را DC های سایت دو انتخاب کردم. نتیجه را با هم دیگه ببینیم:


توانست Domain Partition مربوطه به Mahshaher.corp.vsp.com را از طریق DC های سایت اصلی بدست آورد.
نکته: هر DC فقط و فقط Domain Partition خود را نگهداری می کند و آن را بین DC های همان دومین Replicate می کند. ولی DC های که نقش Global Catalog بر روی آنها فعال علاوه بر Domain Partition خود نیاز به Domain Partition های دیگر دومینها دارند.
اجازه دهید این سناریو را با یک سوال تمام کنم. اگر در سایت 3 ما یک Domain داشته باشیم جریان Replication بین این سایتها چگونه می باشد؟ ایا نیاز به تعقیر تنظیمات هست یا نه؟
در آخر از مهندس اسحاقی و بهزادی عزیز کمال تشکر را دارم که مرا در حل این سناریو یاری کردن.


 

۱۰ مفهوم امنیتی وب که بهتر است هر کاربری بداند

برای اینکه هک نشویم و اطلاعات و سخت‌افزار ما آلوده نشوند، باید وقت بگذاریم و یاد بگیریم. یکی از مهم‌ترین کارها در این زمینه آشنا شدن با مفاهیم و اصطلاح‌های امنیتی است. این مفاهیم به ما می‌آموزند که هکرها چگونه می‌توانند وارد سیستم شده و چگونه می‌توان از ورودشان جلوگیری کرد.
فرق ضد‌ویروس با ضدبدافزار چیست؟

امروزه اکثر مردم با آنتی‌ویروس‌ها آشنایی دارند. نرم‌افزارهایی که برای محافظت از کامپیوتر کاربران در برابر تهدیدات هکری و نرم‌افزارهای مخرب مورد استفاده قرار می‌گیرند. امروزه هر کاربری در ارتباط با باج‌افزارها و بدافزارها با شما سخن می‌گوید.
حمله روز صفر چیست؟ آیا دفاعی در برابر آن وجود دارد؟

در میان انواع تهدیدات امنیتی و طیف گسترده‌ای از مکانیزم‌های مورد استفاده در حملات، این حملات روز - صفر (Zero day) هستند که نه ‌تنها از قدرت تخریب بالایی برخورداراند، بلکه بیشترین فشار روانی را به شرکت‌های سازنده محصولات سخت‌افزاری یا نرم‌افزاری وارد می‌کنند.
همه‌چیز درباره حملات بدافزارهای مبتنی بر ماکروها

روند رو به رشد افزایش قدرت محاسباتی کامپیوترها و تجهیزات همراه باعث شده است تا زندگی برای حرفه‌ای‌ها ساده‌تر شود. اینترنت نه تنها کاربران را قدرتمند می‌سازد، بلکه انجام وظایف را هم ساده‌تر از گذشته می‌کند.
کارت‌های تراشه‌دار چیستند و چگونه کار می‌کنند؟

از اول اکتبر سال جاری (نزدیک به یک هفته دیگر) میلای نسل جدید کارت‌های اعتباری موسوم به کارت‌های هوشمند( کارت‌های تراشه‌دار) در سراسر ایالات متحده مورد استفاده قرار خواهند گرفت. کارت‌های جدید نوید امنیت بیشتر را داده‌اند. از چند ماه پیش بانک‌ها اقدام به توزیع میلیون‌ها کارت اعتباری جدید کرده‌اند. کارت‌هایی که از فناوری امنیتی جدیدی نسبت به کارت‌های مغناطیسی بهره می‌برد.
تبلیغ آلوده‌کننده چیست و چگونه از دست آن‌ خلاص شویم؟

هکرها سعی می‌کنند مرورگر وب و افزونه‌هایی که مورد استفاده قرار می‌دهید را سرقت کنند. امروزه Malvertising یا به عبارت دقیق‌تر تبلیغات آنلاینی که با هدف گسترس بدافزارها مورد استفاده قرار گرفته و با استفاده از شبکه‌های تبلیغاتی قرار گرفته درون سایت‌های معتبر گسترش می‌یابند، بسیار محبوب شده‌اند.
برنامه‌های ناخواسته چیستند و چرا مبارزه با آن‌ها شدت گرفته است

در طول یک هفته حداقل دو یا سه مرتبه پیغام هشدار آبی رنگی با یک صدای بلند به من می‌گوید، من یک ویروس هستم، برای عدم مشاهده صفحه آبی مرگ با من تماس بگیرید. من با تبلیغات و وقفه‌های ناخواسته روبرو شده‌ام، چگونه می‌توانم این مشکل را حل کنم؟ این‌ها نمونه‌ای از سؤالاتی هستند که بخش پشتیبانی شرکت گوگل آن‌ها را دریافت کرده است.
همه چیزی که باید درباره رمزنگاری ایمیل بدانید!

محافظت از پست‌الکترونیک به معنای حفاظت از حریم خصوصی است. عدم توجه به اصول ساده اما زیربنایی باعث می‌شود که نه تنها ایمیل‌ها به آسانی مورد سوء‌استفاده قرار گیرند، بلکه احتمال دسترسی‌های غیرمجاز به یک سیستم که از طریق یک ضمیمه آلوده ارسال شده است را ساده می‌کند.
آشنایی با حملات فیشینگ قلاب‌دار

فیشینگ گونه‌ای از حملات کامپیوتری است که با هدف دسترسی به حساب‌ها و اطلاعات حساس مورد استفاده قرار می‌گیرد. اما فیشینگ قلاب‌دار (Phishing Spear) نوع پیچیده‌تری از فیشینگ است که برای نفوذ به مراکز حساس و دسترسی به اطلاعات مهم مورد استفاده قرار می‌گیرد. حتی کارمندان شرکت‌های امنیتی نیز در خطر به دام افتادن در دام این مدل از حملات قرار دارند.
والینگ: نسل جدیدی از حملات سایبری!

در دنیای امنیت اطلاعات، همیشه قاعده‌ای کلی وجود دارد. شرکتی امنیتی، یک مکانیزم امنیتی می‌سازد و چندی بعد مجرمان سایبری ابزاری برای گذر از این مکانیزم امنیتی طراحی می‌کنند.

 اولین زیرساخت باج‌افزار به عنوان سرویس ویژه سامانه‌های مک شناسایی شد

اگر از کاربران مک در ارتباط با امنیت این پلتفرم سوال کنید، آن‌ها به شما می‌گویند دستگاه‌ها و سامانه‌های مک در برابر بدافزارها ایمن‌تر هستند و هکرها در مقایسه با سیستم‌های ویندوزی به سختی می‌توانند دستگاه‌های مک را در معرض خطر قرار دهند. این حرف تا حدودی صحت دارد، با این وجود بازهم دستگاه‌های مک در برابر تهدیدات امنیتی آسیب‌پذیر هستند. در همین ارتباط کارشناسان امنیتی در وب تاریک موفق شدند اولین زیرساخت باج‌افزار در قالب سرویس را که به منظور آلوده‌سازی سیستم‌های مک مورد استفاده قرار می‌گیرد شناسایی کنند.

شاید در گذشته‌های دور با صراحت می‌توانستیم اعلام کنیم باج‌افزارها تنها به سراغ کاربران پلتفرم ویندوز می‌آیند، اما دیگر این‌گونه نیست و اکنون زمان آن رسیده است تا باج‌افزارها به سامانه‌ها و کاربران پلتفرم مک حمله کنند. تکنیک باج‌افزار در قالب سرویس به هر کاربری در اقصا نقاط جهان اجازه می‌دهد از این زیرساخت به منظور اخاذی از کاربران آنلاین استفاده کنند.
هر کاربری بداند

 این فرآیند باج‌گیری تنها به شرطی در اختیار یک کاربر قرار می‌گیرد که متعهد شود بخشی از سود حاصل از اخاذی خود را به طراح این سرویس اختصاص دهد. در چند سال گذشته هکرها به وفور از این طرح در ارتباط با پلفترم ویندوز استفاده کرده‌اند و متاسفانه با استقبال طیف کثیری از کاربران نیز روبرو شده بودند. اما اکنون هکرها به سراغ سیستم‌های مک آمده‌اند. تحلیل انجام گرفته از سوی کارشناسان امنیتی نشان می‌دهد این زیرساخت موسوم به MacRansom در حال حاضر از طریق یک سایت پوشش داده شده با شبکه‌های پنهان کننده در حال تبلیغ است. در تبلیغ این زیرساخت آمده است که یکی از پیچیده‌ترین بدافزارهای ممکن برای سیستم‌های مک آماده شده و در اختیار متقاضیان قرار می‌گیرد.

سازوکار زیرساخت فوق به چه ترتیبی است؟

پژوهش انجام گرفته از سوی کارشناسان امنیتی نشان می‌دهد زمانی که کاربری درخواست خرید این باج‌افزار را ارسال می‌کند، هکر به درخواست خرید واکنش نشان داده و همراه با دستورالعمل لازم یک فعال‌ساز زمانی را برای باج‌افزار فوق نوشته و برای خریدار ارسال می‌کند. این فعال‌ساز به این منظور مورد استفاده قرار می‌گیرد تا فرآیند رمزنگاری فایل‌ها با تاخیر آغاز شده و به صورت بلادرنگ رمزنگاری فایل‌های یک سامانه آغاز نشود. هنگامی که باج‌افزار فوق فعال شد، باج‌افزار فرآیند رمزنگاری فایل‌ها را آغاز می‌کند.

 اما در این بین یک اتفاق عجیب و غریب رخ می‌دهد. باج‌افزار فوق قادر است تنها 128 فایل را رمزنگاری کند و همین موضوع باعث شده است تا کارشناسان امنیتی اعلام دارند باج‌افزار MacRansom به پیچیدگی نمونه‌هایی نیست که تا پیش از این شناسایی شده‌اند. با این وجود باج‌افزار فوق هنوز هم قادر است فایل‌های مهم و اجرایی کاربر روی یک سامانه مک را قربانی ساخته و مهر زمانی و تاریخ سیستم قربانی را نیز تغییر دهد. این دو تغییر مهم عملا باعث می‌شوند تا ابزارهایی که به منظور بازیابی فایل‌ها ساخته می‌شوند قادر نباشند فایل‌های قفل شده را باز کنند. مقدار باجی که از سوی این زیرساخت درخواست می‌شود معادل 0.25 بیت‌کوین است. به عبارت دقیق‌تر قربانی برای دسترسی مجدد به فایل‌های خود باید 670 دلار را تنها در یک بازه زمانی یک هفته‌ای پرداخت کند. در غیر این صورت فایل‌های او برای همیشه پاک می‌شوند.

 

ابزار امنیتی ویژه‌ای برای شکار سرورهای کنترل و فرمان‌دهی عرضه شد

در حملات هکری مجرمان سایبری بدافزارهای خود را به‌گونه‌ای طراحی می‌کنند که در ابتدا سامانه‌های کامپیوتری را آلوده کند و در ادامه از طریق یک سرور کنترل و فرمان‌دهی با هکرها در ارتباط باشند. هکرها از طریق این مرکز کنترل و فرمان‌دهی دستورات لازم را برای بدافزار ارسال می‌کنند. بات‌نت‌ها و باج‌افزارها به‌شکل گسترده‌ای از این سرورها استفاده می‌کنند. حال اگر بتوانیم مانع برقراری این ارتباط شویم، در واقع موفق شده‌ایم ارتباط میان هکر و بدافزار را از میان ببریم. در چنین حالتی شانس ما برای مقابله با بدافزارها دوچندان خواهد شد. سرویس Malware Hunter که به شکارچی بدافزارها معروف شده برپایه همین ایده طراحی شده است.

سرویس فوق به شرکت‌ها و سازمان‌ها اجازه می‌دهد کانال ارتباطی میان بدافزارها و سرورهای کنترل و فرمان‌‌دهی را مسدود کنند. شرکت Recorded Future که در زمینه شناسایی تهدیدات امنیتی از طریق الگوریتم‌های یادگیری ماشینی به فعالیت اشتغال دارد، با همکاری موتور جست‌وجوگر شادون موفق شده است این سرویس آنلاین را طراحی کند. سرویس فوق به‌طور مستمر در سطح اینترنت به جست‌وجو پرداخته تا پانل‌های کنترلی متعلق به ده‌ها برنامه RAT (سرنام Remote Access Trojan) را شناسایی کند.

پانل‌هایی که با تروجان‌های معروفی همچون Gh0st RAT، DarkComet، njRAT، ZeroAccess و XtremeRAT در ارتباط هستند. بدافزارهایی که به آن‌ها اشاره شد، جزء بدافزارهای تجاری هستند و در انجمن‌های دارک وب خرید و فروش می‌شوند. هکرها از طریق این بدافزارها و تعامل آن‌ها با پانل‌های مربوط قادر هستند دستگاه‌های آلوده را کنترل و دستورات مربوط را برای آن‌ها ارسال کنند. سرویس فوق برای آنکه بتواند سرورهای کنترل و فرمان‌دهی (C&C) (سرنام Command-and- Control) را شناسایی کند، به نشانی‌های IP عمومی متصل می‌شود و در ادامه ترافیکی را به‌سمت این نشانی‌ها هدایت می‌کند.



ترافیکی که ممکن است تروجان‌ها آن ‌را دریافت و به‌سمت پانل کنترلی خود ارسال کنند. اگر دستگاه‌هایی که این ترافیک به‌سمت آن‌ها ارسال شده پاسخی برای سرویس Malware Hunter ارسال کنند، نشان می‌دهند که یک سرور کنترل و فرمان‌دهی هستند. سرویس فوق تا به امروز موفق شده است بیش از 5700 سرور کنترل و فرمان‌دهی را شناسایی کند. جالب آنکه بیش از چهار هزار مورد از این سرورها در کشور ایالات متحده قرار داشته‌اند. بخش اعظمی از پانل‌های کنترلی شناسایی شده در ارتباط با تروجان Gh0st بودند. بدافزار فوق اولین بار در سال 2009 میلادی شناسایی شد. بدافزاری که منشأ آن یکی از کشورهای آسیایی بوده و تا به امروز در طیف گسترده‌ای از حملات سایبری مورد استفاده قرار گرفته است. الگویی که سرویس شکارچی بدافزارها به‌منظور شناسایی سرورهای کنترل و فرمان‌دهی RAT از آن استفاده می‌کند، منطبق بر پژوهشی است که در گذشته شرکت Research Future انجام داده است. شرکت یاد شده در گذشته از طریق همین تکنیک سرورهای مخرب را شناسایی می‌کرد، اما این کار را در مقیاس کوچک‌تری انجام می‌داد. توسعه‌دهندگان سرویس شکارچی بدافزار ساز و کاری را ترتیب داده‌اند که به شرکت‌های امنیتی و همچنین پژوهشگران امنیتی اجازه می‌دهد فهرستی از این سرورهای کنترل و فرمان‌دهی را مشاهده کرده و قواعد مربوط به دیوار آتش خود را منطبق با این فهرست به‌روزرسانی کنند. فهرست یاد شده به‌طور مرتب به‌روزرسانی شده تا همواره جدیدترین اطلاعات را در اختیار شرکت‌های امنیتی قرار دهد.


زمانی که ارتباط بدافزار با سرور کنترل و فرما‌ن‌دهی قطع و این ‌کار در سطح لایه شبکه انجام شود، هکرها دیگر این توانایی را نخواهند داشت تا حمله خود را به‌طور کامل اجرا و اطلاعات موجود روی سامانه‌های قربانی را استخراج کنند

رویکرد ارائه شده از سوی این سرویس در عمل کارایی بالایی دارد، زیرا در حالت عادی باید منتظر باشیم تا شرکت‌های امنیتی نمونه‌هایی از یک بدافزار را به دست آورده، آن‌ها را تحلیل کرده، در ادامه الگوی مورد استفاده از سوی یک بدافزار در ارتباط با مرکز کنترل و فرمان‌دهی را کشف کرده و در ادامه گزارش آن‌ را منتشر کنند تا سازمان‌ها از کم و کیف موضوع اطلاع پیدا کنند. همان ‌گونه که مشاهده می‌کنید، این پروسه به زمان نسبتاً زیادی نیاز دارد، در حالی که سرویس شکارچی بدافزارها این ‌کار را در سریع‌ترین زمان ممکن انجام می‌دهد. با توجه به آنکه در چند سال اخیر سامانه‌های امنیتی در ارتباط با ترافیک وارد شونده به یک شبکه در بعضی موارد هشدارهای مثبت کاذبی را صادر کرده‌اند و پس از بررسی مشخص شده هیچ ‌گونه فعالیت مشکوکی شکل نگرفته است، در نتیجه این احتمال وجود دارد که سرویس فوق بتواند در این زمینه راهگشا باشد.

همه چیز درباره تقویت‌کننده‌های سیگنالی وای‌فای

زمانی که در حال تماشای سریال موردنظر خود هستید یا در حال انجام یک بازی آنلاین هستید به اتاق‌های مختلف خانه می‌روید. اما ناگهان به اتاقی وارد می‌شوید که سیگنال وای‌فای در آن نقطه دریافت نمی‌شود. در چنین حالتی شما به نقطه کور (Zone dead) سیگنال وای‌فای وارد شده‌اید. بسیاری از کاربران برای حل این مشکل به دنبال خرید روترهای جدید و بعضا گران‌قیمتی می‌روند، اما برای حل این مشکل یک راه‌کار ساده پیش روی شما قرار دارد. یک افزایش‌دهنده برد وای‌فای (Wi-Fi Range Extender) قادر است این مشکل را برطرف کند.

یک افزایش دهنده برد که بعضی منابع به آن تقویت‌کننده سیگنال وای‌فای نیز می‌گویند، ابزاری است که می‌تواند دامنه امواج وای‌فای را افزایش داده، سیگنال‌ها را تقویت کرده و دومرتبه آن‌ها را پخش کند. نصب این ابزارها ساده بوده و در ابعاد، اندازه و سرعت‌های مختلفی در اختیار کاربران قرار دارد. اما این ابزارها نیز محدودیت‌های خاص خود را دارند. سرعت آن‌ها به‌طور معمول نصف سرعت روتر بوده و همچنین شبکه جداگانه‌ای را ایجاد می‌کنند که رومینگ کردن به آن کمی دشوار است. اگر در خانه‌ای سکونت دارید که زیاد بزرگ نیست یک روتر متوسط رو به بالا نیاز شما در دستیابی به سیگنال‌های وای‌فای را به خوبی پوشش می‌دهد.


اما برای خانه‌هایی که در ساخت آن‌ها از مواد سنگین همچون بتن، آجر، فلز و گچ استفاده شده است سیگنال‌ وای‌فای ممکن است تمامی خانه را به درستی پوشش ندهد. این مشکل در خانه‌های چند طبقه یا در برج‌های بزرگ حادتر می‌شود. در چنین شرایطی بهترین راهکار این است که روتر خود را در یک مکان مرکزی قرار دهید تا نقاط کور را پوشش دهد. اما مشکلی که در این بین وجود دارد این است که در اغلب موارد برای تغییر مکان روتر به کابل‌ اترنت نیاز دارید که دردسرهای خاص خود را دارد. اما یک افزایش‌دهنده برد بدون نیاز به هیچ‌گونه کابلی قادر است مشکل عدم دسترسی به وای‌فای را حل کند.

چگونه یک افزایش دهنده برد وای فای مناسب پیدا کنیم؟

در زمان انتخاب یک تقویت کننده سیگنال وای‌فای مهم‌ترین فاکتوری که باید به آن توجه داشته باشید این است که مشخصات آن با مشخصات روتر شما هماهنگ باشد. به‌طور مثال اگر یک روتر دو بانده AC1900 دارید، یک افزایش دهنده دو بانده AC1900 (یا بهتر از آن) گزینه ایده‌آلی است. اگر روتر شما از فناوری MU-MIMO در ارتباط با استریک کردن داده‌ها پشتیبانی می‌کند به تقویت کننده سیگنالی نیاز دارید که از این فناوری پشتیبانی کرده تا بتوانید شبکه MU-MIMO را ایجاد کنید.

مدل دسکتاپی یا پلاگینی؟

تقویت‌کننده‌های سیگنال وای‌فای به دو شکل دسکتاپی یا پلاگینی در اختیار شما قرار دارند. اکثر تقویت‌کننده‌های دسکتاپی شبیه به روترهای بی‌سیم معمولی هستند و به‌طور معمول به آنتن‌های قابل تنظیم خارجی، پورت‌های LAN چندگانه برای اتصال دستگاه‌های مختلف همچون تلویزیون و کنسول‌های بازی، پورت‌های USB برای اتصال چاپگرها و درایوهای ذخیره‌ساز تجهیز شده‌اند. تقویت‌کننده‌های نوع پلاگینی در مقایسه با مدل‌های دسکتاپی کوچک‌تر بوده و به‌طور مستقیم به پریز برق متصل می‌شوند. تعدادی از مدل‌ها دارای آنتن‌های خارجی هستند، در حالی که اکثر آن‌ها به آنتن‌های داخلی تجهیز شده‌اند. با توجه به اندازه آن‌ها، تقویت‌کننده‌های نوع پلاگینی به‌طور معمول تنها یک پورت LAN دارند و فاقد پورت USB  هستند. در نتیجه در مقایسه با نمونه‌های دسکتاپی کمتر مقرون به صرفه هستند.
نصب ساده

در گذشته‌های نه چندان دور برای پیکربندی یک تقویت کننده سیگنال به کمی دانش فنی و صبر حوصله زیاد برای پیدا کردن بهترین مکان برای نصب نیاز داشتید. (به‌طور معمول مکانی بینابین روتر و نقطه کور) اما اکثر روترهای امروزی و افزایش‌دهنده‌ها از ویژگی WPS پشتیبانی می‌کنند. جفت کردن این ویژگی روی هر دو دستگاه به سادگی امکان‌پذیر بوده و به سادگی فشار دادن دو دکمه روی دستگاه‌ها، نام‌گذاری شبکه تقویتی و ساخت گذرواژه‌ای برای شبکه است. علاوه بر این، تقریبا تمامی تولیدکنندگان تجهیزات تقویت‌کننده یک صفحه تنظیمات وب‌محور را در اختیار کاربران خود قرار می‌دهند که دستورالعمل‌های لازم  برای تنظیمات اولیه بی‌سیم را ارائه می‌کنند. تعدادی (نه همه) از تقویت‌کننده‌های سیگنال به چراغ‌های LED مجهز هستند که به شما وضعیت دستگاه و دور بودن آن از روتر را اطلاع می‌دهند. تقویت‌کننده‌های سیگنال همچنین قادر هستند ویژگی‌های پیشرفته‌‌‌ای همچون شبکه میهمان، قابلیت‌های مدیاسرور و... را ارائه کنند.


تقویت‌کننده‌های سیگنال چه محدودیت‌هایی دارند؟

در حالی که پیکربندی این ابزارها نسبتا ساده است، اما تقویت‌کننده‌ها محدودیت‌های خاص خود را دارند. آن‌ها از SSID جداگانه‌ای استفاده می‌کنند، در نتیجه برای دسترسی به وای‌فای مجبور هستید به شبکه‌ای که این ابزارها ساخته‌اند وارد شوید. سرعت وای‌فای ارائه شده از سوی تقویت‌کننده‌ها تقریبا نصف سرعتی است که از روتر اصلی خود دریافت می‌کنید. اکثر تقویت‌کننده‌های دو بانده از باندهای رادیویی برای انتقال داده‌ها به/از روتر استفاده می‌کنند. این حرف به معنای آن است که دستگاه‌ها برای اتصال به تقویت‌کننده سیگنال با پهنای باندی که از سوی روتر ارائه می‌شود در تقابل قرار خواهند داشت. البته برخی از تولیدکنندگان این تجهیزات برای کاهش ترافیک شبکه به شما اجازه می‌دهند یک باند ویژه برای برقراری ارتباط روتر به تقویت‌کننده تعریف کنید. فناوری Fastlane متعلق به نت‌گیر و فناوری BoostBand  متعلق به Amped Wireless مثال‌های خوبی در این زمینه به شمار می‌روند.

چه زمانی باید به سراغ یک سامانه وای‌فای مبتنی بر مش برویم؟

اگر به دنبال ارتقا شبکه خود با سخت‌افزارهای جدیدی هستید بهتر است پیش از آن‌که برای یک روتر سنتی هزینه‌‌ای را متحمل شوید به یک سامانه وای‌فای مش نگاهی داشته باشید. سامانه‌های وای‌فای به گونه‌ای طراحی شده‌اند تا خانه شما را به خوبی پوشش دهند. این سامانه‌ها از یکسری مولفه‌های شبکه همچون یک روتر اصلی و مجموعه‌ای از ماژول‌های ماهواره‌ای یا گره‌هایی که همه فضای خانه شما را پوشش می‌دهند ساخته شده‌اند. همه این اجزا در قالب یک شبکه بی‌سیم و تحت یک SSID و گذرواژه یکسان کار می‌کنند. این حرف به معنای آن است که شما بدون آن‌که نیازی داشته باشید تا به یک شبکه توسعه یافته وارد شوید از همان شبکه اصلی خود استفاده کنید. در حالی که تقویت‌کننده‌های سیگنال برای برقراری ارتباط با روتر در محدوده فرکانس 2.4 گیگاهرتز تا 5 گیگاهرتز رادیویی کار می‌کنند، اکثر سامانه‌های ماهواره‌ای وای‌فای از فناوری مش برای برقراری ارتباط با روتر و دیگر دستگاه‌ها استفاده می‌کنند. در این سامانه هر گره در نقش یک هاپ پوینت (Hop Point) برای گره‌های دیگر ظاهر شده و به این شکل به گره‌های دورتر از روتر کمک می‌کنند تا از یک سیگنال قوی وای‌فای به منظور برقراری ارتباط استفاده کنند.

سامانه‌های وای‌فای برای کاربرانی با حداقل دانش فنی ایده‌آل هستند. آن‌ها در عرض چند دقیقه نصب شده و در اکثر مواقع با برنامه‌های موبایل کاربرپسند عرضه شده و گام به گام دستورالعمل لازم برای نصب را در اختیار کاربر قرار می‌دهند. اما به این نکته توجه داشته باشید که اگر به دنبال آن هستید تا فقط نقاط کور وای‌فای را از بین ببرید این سامانه‌ها ایده‌آل نیستند، به واسطه آن‌که قیمت نسبتا بالایی دارند. در مقایسه با تقویت‌کننده‌های سیگنالی پریزی که در محدوده 70 دلار تا 100 دلار قرار دارند و همچنین تقویت‌کننده‌های دسکتاپی که در محدوده 70 تا 170 دلار (بسته به ویژگی‌هایی که ارائه می‌دهند)،  قیمت سامانه‌های وای‌فای مش از نرخ پایه 130 دلار برای هر گره شروع شده و به 500 دلار می‌رسند.