بعد از فارغ شدن از بحث سرتیفیکت سرور قصد دارم بحث جالب و دوست داشتی Direct Access را بصورت خیلی واضح و ساده توضیح و آموزش دهم. مطمئن هستم خیلی از ما هنوز با تئوری ، اصطلاحات و تکنولوژی های که در Direct Access بکار رفته اشنا نیستیم و چون Direct Access از IPv6 استفاده می کند خیلیا برای یاد گرفتن آن طفره میرن. در این سری آموزش در ابتدا نگاهی مختصر به بعضی از اصطلاحات و تکنولوژی های به کار رفته در Direct Access می اندازیم و در مقاله های آتی بصورت عملی و کامل آنها را یاد خواهیم گرفت.
رول Remote Access که در Windows Server 2008 R2 معرفی شده است شامل چندین بخش می باشد ما در این سری آموزش فقط با Direct Access سرو کار داریم و به آموزش آن می پردازیم.در بیشتر سازمانها پرسنل های وجود دارند که برای انجام کار سازمان به بیرون از آن سازمان می روند مانند کارشناسان فروش یا خرید و غیره، که در چنین حالیتهای آن پرسنل گاهی مجبور می شوند که از بیرون به شبکه سازمان وصل شوند و داده های خود را ابدیت کند. برای چنین سناریوهای راه حلی های وجود داشت مثل استفاده از Remote access VPN connection.استفاده از Remote access VPN connection معایبی داشت مانند:
در ادامه مزایای استفاده از Direct Access و همچنین معایب استفاده از VPN را بیشتر توضیح می دهیم. اولین بار DA در Windows Server 2008 R2 معرفی شده است و مانند VPN برای دسترسی به منابع شبکه از بیرون سازمان استفاده می شود. خیلی از IT Man ها خیال می کنند این تکنولوژی نسخه پیشرفته VPN می باشد در صورتی که از لحاظ تکنولوژی و کارکرد هر دو آنها با هم فرق می کنند.
DA برخلاف VPN که باید بصورت دستی اجرا و تنظیم شود بصورت کاملا خودکار اجرا و متصل می شود و نیازی به هیچ گونه نرم افزارخاصی ندارد. وقتی کلاینت متوجه شد که بیرون از سازمان می باشد ( چگونه متوجه می شود را در مقاله های بعدی توضیح می دهم) و دسترسی به اینترنت دارد بصورت اتوماتیک ارتباط خود را بصورت امن با DA Server برقرار می کند و از منابع شبکه استفاده میکند.
نکته: DA پروتکل نیست یک مجموعه ای از تکنولوژی های هستش که درون Windows ایجاد شده اند که بتوان یک ارتباط امن با شبکه سازمان داشت. DA از IPv6 برای انتقال داده ها و از IPsec برای امن کردن ارتباطات و از Active Directory ، Certificate ، Kerberos و NTLM برای احراز هویت استفاده می کند و در DA Client از Windows Firewall with Advanced Security (WFAS) and the Name Resolution Policy Table (NRPT) استفاده می کند.
IPv6 یکی از اجزای یکپارچه و مهم در Direct Access می باشد. DA Server و DA Client تمام اطلاعات خود را با استفاده از IPv6 انتقال می دهند. نگرن نباشید ما بصورت کلی IPv6 را پیاده سازی نمی کنیم و همچنین ماشین های که با IPv4 کار می کنند می توانند از DA استفاده کنند. در DA سولوشن های وجود دارد که استفاده از IPv6 را ساده و راحت می کند. (به خواندن ادامه دهید)
در بیشتر سناریوها بستر نقل و انتقالات Packet ها در شبکه ها استفاده از IPv4 می باشد. حالا اگر بخواهیم از DA استفاده کنیم چگونه بتوانیم به Resource های که از IPv4 استفاده می کنند دسترسی داشته باشیم؟؟؟ DA برای حل این مشکل از Tunnel استفاده می کند. بدین صورت که ترافیک IPv6 را در IPv4 کپسوله می کند و آنها را منتقل می کند. در DA ما سه نوع تانل انتقال داریم:
دوستان بصورت مختصر DA به دو صورت نصب می شود:
شما در روش اولی نمی توانید از تانل 6to4 and Teredo استفاده کنید. ولی در روش دومی می توانید از هر سه تانل که در دسترس کلاینت می باشد استفاده کنید. اینو یادتون نره....
گاهی وقتا لازم میشه Help Disk ها بتوانند به DA Client که بیرون از سازمان می باشد ارتباط داشته باشند و آن کامپیوتر را عیب یابی کنند. ولی بصورت پیش فرض نمی توان وصل شد!!!! علتش هم اینه که کامپیوترهای داخل سازمان هیچ گونه IPv6ی بر روی آنها ست نیست که بتوانند با DA Client ارتباط برقرار کنند. برای حل این مشکل دو راهکار دارید:
ISATAP مکانیزمی می باشد که بصورت اتوماتیک یک IPv6 معتبر روی کامپیوتر ایجاد می کند و آن را به ISATAP Router وصل می کند و ISATAP Router آن به بیرون هدایت می کند. (حتما الان تعجب کردید که واااای خدای من باید یک ISATAP Router هم بخریم؟؟؟؟؟؟ بهترین قسمت ماجرا اینجاست که ISATAP Router شما همان Direct Access می باشد و بصورت پیش فرض تمام ترافیک ISATAP را دریافت و منتقل می کند.)
همانطور که قبلا گفتیم DA Client ها برای ارتباط از IPv6 استفاده می کنند، ولی Resource های شبکه سازمان از IPv4 استفاده می کنند!!! الان چگونه DA Client ها بتوانند به Recourse های داخل سازمان دسترسی داشته باشند؟؟ وقتی شما DA Server را نصب می کنید علاوه بر سرویس DA کامپوننت های زیر بر روی آن نصب می شود:
بوسیله کامپوننت های بالا و تانل های مورد استفاده، شما نیازی به داشتن دانش IPv6 و همچنین پیاده سازی آن در شبکه سازمان را ندارید.
گرچه برای پیاده سازی DA شما نیازی به IPv6 ندارید و همه این اتفاقات بصورت اتوماتیک صورت می گیرد ولی همانطور که برای یاد گرفتن IPv4 وقت گذاشتیم برای IPv6 هم وقت بگذارید. برای اینکار توصیه می کنم کتاب زیر را حتما بخوانید:
وقتی که کلاینتی تشخیص دهد که بیرون از سازمان می باشد چه نیاز داشته باشد و چه نیاز نداشته باشد بصورت اتوماتیک سرویس DA Client بر روی آن کلاینت فعال و بصورت امن (Ipsec Tunnel) به DA Server وصل می شود. در بیشتر سناریوها کلاینت دارای یک IPv4 می باشد پس در نتیجه برای اینکه بتواند ارتباط خود را با DA Server برقرار کنید از تانل های Teredo, 6to4 and IP-HTTP استفاده و ترافیک IPv6 را در IPv4 کپسوله و به سمت DA Server هدایت می کنند.
DA Server ترافیک کلاینتها را بوسیله NAT64 and DNS64 به IPv4 و بر عکس تبدیل می کند و یک ارتباط مستقیم بین DA Client و منابع شبکه سازمان برقرار می کند. بعد از برقراری ارتباط بوسیله Certificate, NTLM و غیره کلاینت را احراز هویت می کنند و دسترسی به منابع شبکه را به می دهند. خلاصه کارکرد Direct Access را بصورت خیلی ساده و روان توضیح دادیم.
متاسفانه DA فقط بر روی کلاینتهای اعمال می شود که عضو Domain باشند!!!! به احتمال زیاد الان خشکتون زده!! این همه دنگ و فنگ فقط برای کامپیوترهای که Join to Domain هستش؟؟؟ نه دوستان به این معنی نیست که از داخل خود سازمان ما از DA استفاده کنیم، بدین معنی می باشد که ما برای اینکه از DA استفاده کنیم مجبوریم یک سری تنظیمات بر روی سرور DA و کلاینتها انجام دهیم و ما این تنظیمات را از طریق Group Policy انجام می دهیم که لازمه آن Join to Domain هستش. فرض کنید یک مامور خرید برای اینکه بتواند از DA استفاده کند برای یکبار که شده باید Lab Top این اقا را جوین دومین کنیم. و بعد از اعمال تعقیرات و فعال شدن DA بر روی این Lab Top می تواند از هر جای جهان به DA وصل شود.
نسخه های ویندوز که DirectAccess را پشتیبانی می کنند عبارتند از:
نسخه های سرور هم:
DA برای امن کردن ارتباطات بین DA Server و DA Client از تانل IPSec استفاده می کند IPSec در بعضی از سناریوها از دو تانل متفاوت استفاده می کند:
اگرکلاینت هر دو متد را پاس کند می تواند از منابع از پیش مشخص شده استفاده کند.
ایجاد وتنظیم کانکشن VPN در بیشتر اوقات توسط کاربر انجام می شود و هر گاه کاربر نیاز داشت این کانکشن را اجرا میکند. ولی DirectAccess بصورت یکپارچه در در خود سیستم عامل تعبیه شده است و بصورت اتوماتیک بدون نیاز به اجرا و وصل می شود.تنظیم فایروال برای بعضی از پروتکل های VPN توسط کاربر سخت و گاهی غیرممکن است و این مانع ایجاد یک ارتباط امن می شود. ولی DirectAccess بصورت امن از پروتکل https که پروتکل رایج و ساده می باشد استفاده می کند و همچنین در بیشتر Firewall ها این ترافیک آزاد می باشد.
در بعضی از سناریوها راه اندازی VPN Server نیازمند سخت افزار و برنامه های جانبی می باشد که نیازمند به خرید لایسنس و تنظیمات خاصی می باشد. ولی DirectAccess را می توان در قسمت DMZ و بصورت مجازی اجرا و عملی کرد. VPN نیازمند نرم افزاری به نام VPN Connection می باشد که بتواند به VPN سرور وصل شود که ایجاد و تنظیم این نوع کانکشنها می تواند در بعضی مواقع سخت و غیر ممکن باشد. ولی DirectAccess نیازمند به هیچ گونه نرمافزاری نیست و تمام تنظیمات آن از طریق Group Policy ایجاد و تنظیم می شود.
محدودیت و اشکلات DirectAccess شامل:
در این مقاله تا حدودی با DirectAccess اشنا شدیم و کامپوننت های آن را برسی کردیم، و بعضی از اصطلاحات و تکنولوژی های منحصربفرد آن را توضیح دادیم. در مقالات آتی نوع Plan های آن و سناریو های که از DA استفاده می شود را برسی می کنیم.
در این قسمت یاد میگیریم چگونه DirectAccess را در ساختار پیاده سازی کنیم و در چه توپولوژی قابل پیاده سازی می باشد و …… با ما همراه باشید.نحوه پیاده سازی یا دیزاین DA یکی از مهمترین بخشهای پیاده سازی این سرویس فوق العاده می باشد. DA در ثوپولوژهای مختلفی می تواند پیاده سازی شود. درک نحوه پیاده سازی DA برای راه اندازی این سرویس خیلی مهم می باشد.
DA می تواند بر روی Windows Server 2012 and 2016 نسخه های Datacenter, Standard نصب شود. و DA باید بر روی یک سرور اختصاصی نصب شود. شما نمی توانید این سرویس را بر روی Domain Controller or ADCS and Exchange Server نصب کنید. ( در نصب شدن این سرویس بر روی سرویس های بالا می توان آن را نصب کرد ولی اختلال و خطاهای عجیب غریبی دریافت می کنید که می تونه کلا شما را از این دنیا نا امید کنه و به فکر خودکشی بندازه :) پس خواهشا Best Practice ها را رعایت کنید) گرچه شما می توانید در سناریوهای سرویس های VPN و Web application proxy را بر روی DA نصب کنید.
همانطور که قبلا گفته شد DA باید بر روی یک سرور مجزا نصب شود یا می توانید آن را بصورت یک VM بر روی Hyper-V یا VMware و غیره نصب کنید و حداقل سخت افزار توصیه شده برای نصب DA یک پردازنده 4 هسته ای با 8 گیگ رم و 60 گیگ فضای آزاد بر روی هارد می باشد.
یکی از پیش نیازهای DA عضو کردن آن در Active Directory می باشد چون DA تنظمات خود و کلاینتها را از AD دریافت می کند و همچنین تانل IPsec بوسیله AD احراز هویت می شود.
In addition, IPsec tunnels used by DirectAccess are authenticated via Active Directory
همچنین شما می توانید DA را عضو هر دومینی در فارست کنید و لزومی ندارد در یک دومین خاص عضو شود.
یکی از پیش نیازهای مهم DA فعال بود Windows Firewall بر روی DA Server و DA Client می باشد. یعنی اگر شما فایروال ویندزتون رو بخاطر پینگ کردن دو سیستم غیرفعال کرده باشید نمی توانید از DA استفاده کنید. (شاید باور نکنید 80 درصد ادمین های ما بخاطر پینگ فایروال را خاموش می کنند)
پس در نتیجه Firewall باید بر روی همه پروفایلها فعال باشد.
تمام تبادل اطلاعات بین سرور و کلاینتها بر روی بستر IPv6 صورت میگیرد. همچنین استفاده از transition technologies باعث شده استفاده از IPv6 راحت باشد و نیازی به پیاده سازی آن بر روی شبکه داخلی نیست. ولی با این همه گاهی وقتا مشاهده شده بعضی از ادمین های عزیز IPv6 را بر روی سیستم ها غیرفعال می کنند شما با غیرفعال کردن این قابلیت کلا DA را فلج می کنید.پس خواهشا IPv6 را غیرفعال نکنید. اگر احیانا IPv6 مزاحمتهای در عملکرد بعضی از سرویس ها ایجاد می کند مانند nslookup.exe میتوانید اولویت IPv6 را به IPv4 تعقیردهد.
شما می توانید DA را در سه محیط و ساختار مختلف پیاده سازی کنید:
در این ساختار DA در لبه شبکه راه اندازی می شود و حتما باید دارای دو کارت شبکه باشد یکی به Internal شبکه لینک شده باشد و یکی به External یا اینترنت.
DA می تواند بصورت یک یا دو کارت شبکه در قسمت Perimeter شبکه و پشت فایروال فعالیت کند. فرض کنید DA ما پشت فایروال باشد (بدون استفاده از قابلیت NAT) و دارای دو کارت شبکه باشد
DA میتواند در قسمت LAN شبکه فعالیت کند که فقط نیاز به یک کارت شبکه و IP Private دارد.
اگر در قسمت Edge شبکه یک Firewall باشد باید پروتکل و پورتهای زیر بر روی فایروال باز باشد:
اگر DA دارای یک IPv6 بصورت Routable باشد (به اصطلاح دیگر IPv6 Public) باید پورت و پروتکل های زیر بر روی Firewall باز باشد:
اگر DA در قسمت DMZ شبکه قرار دارد و دارای یک IP Public باشد باید پروتکل و پورتهای زیر بر روی فایروال باز باشد:
اگر DA در قسمت DMZ و پشت NAT باشد باید پروتکل و پورتهای زیر بر روی Firewall باز باشد:
اگر DA در شبکه LAN باشد پروتکل و پورتهای زیر باید در firewall باز باشد:
نحوه Publish کرد DirectAccess را در TMG در یک قسمت جدا آموزش خواهم داد.
در سناریو و ساختارهای بسیار نادری مشاهده می کنید که DA را در قسمت Edge شبکه قرار می دهند. یکی از مزایای قرار دادن DA در قسمت Edge شبکه استفاده از سه تانل IPv6 می باشد (Teredo, 6to4 and IP-HTTPS) می باشد ولی از لحاظ امنیتی شما فقط Windows Firewall را دارید که از DA محافظت می کند. گرچه Windows Firewall از نوع خودش یک firewall کامل و جامع می باشد ولی شما یک لایه امنیتی بر روی DirectAccess دارید. پس توصیه می شود که DA را پشت یک Firewall در قسمت DMZ قرار دهید تا امنیت آن فراهم شود گرچه در این سناریو فقط می توانید از تانل IP-HTTPS استفاده کنید.
در این قسمت پیش نیازهای ساختار اکتیودایرکتوری برای پیاده سازی DA را مرور می کنیم.
DA به سه نوع Certificate نیاز دارد:
شما به راحتی می توانید از یک CA Server داخلی استفاده کنید. چون تمام DA Client ها قبل از اتصال بوسیله Active Directory تنظیمات خود را دریافت می کنند همچنین می توانیم بعضی از Certificate Template ها را از این طریق به آنها اعمال کنیم.نکته: لازمه استفاده از CA Server داخلی Publish کردن لیست CRL آن می باشد چون وقتی کاربران خارج از سازمان باشند قبل از استفاده از Certificate باید لیست Certificate های باطل شده را دریافت کنند.
برای Publish کردن لیست CRL در TMG می توانید از لینک زیر استفاده کنید:
پابلیش کردن لیست CRL مربوط به CA Server در TMG
اگر از CA Server داخلی استفاده می کنید باید سرتیفیکت تمپلیت Computer را بر روی DirectAccess Server and DA Client صادر و نصب کنید.نکته خیلی مهم: Certificate Template باید با FQDN و Hostname کلاینتها و سرور مچ باشد وگرنه با مشکلات زیادی رو به رو می شوید. همچنین باید این سرتیفیکت EKU آن دارای Client Authentication باشد.
برای پروتکل انتقال IP-HTTPS شما نیاز به یک SSL Certificate دارید که با FQDN ی که کاربران برای اتصال با DA استفاده می کنند یکی باشد. IP-HTPS از این Certificate برای احراز هویت و رمزگذاری اطلاعات استفاده می کند.نکته: اگر حوصله دنگ و فنگ CA Server و پابلیش کردن لیست CRL آن را ندارید می توانید از یک third-party CA درخواست Certificate دهید.
ی سوال دارم: کلاینتها داخل سازمان تنظیم می شوند و وقتی که خارج از سازمان شدند به صورت اتوماتیک از طریق DA به شبکه داخلی سازمان متصل می شوند همانطور که می دانید در DA ما نه کانکشن دارم و نه تنظیمات خاصی همه چیز از طریق GPO اعمال می شود، با این تعاریف کلاینت چگونه مت وجه شود که خارج یا داخل سازمان می باشد؟؟؟؟؟؟؟؟؟؟ جواب سادس بوسیله NLS!!!!!! خب این NLS چی هست؟؟؟
NLS یک web Siteی هستش که بر روی آن یک صفحه وبی میزبانی می شود. DA Client قبل از اینکه ارتباط خود را با DA برقرار کند اول چک می کند داخل سازمان است یا نه برای اینکار یک درخواست به سمت وب سرور NLS ارسال می کند، اگر توانست با NLS ارتباط برقرار کند متوجه می شود که داخل سازمان می باشد و از DA استفاده نمی کند درغیراین صورت متوجه می شود بیرون از سازمان هستش و از DA استفاده می کند. Got it??? خب این وب سایت NLS هم نیازمند یک SSL Certificate می باشد و همچنین یک A Record و غیره که به وقتش آن را کامل توضیح می دهیم.
پیش نیازهای DNS برای استفاده از DirectAccess. ما دو سری رکورد داریم که باید در Internal DNS و در External DNS ایجاد شوند:
رکوردهای که در هنگام نصب DirectAccess در DNSایجاد می شود عبارتند از:
در External DNS شما فقط نیازمند ایجاد یک A Record می باشد که کاربران خارج از سازمان از آن برای دسترسی به DirectAccess استفاده می کنند. این رکورد می تواند به IP Publicی که بر روی DA Server ست شده است اشاره کند یا به IP ی که بر روی Edge Firewall ست شده.اگر قسمت قبلی و این قسمت را با دقت مطالعه کرده باشید تا حدودی اطلاعاتی درباره DirectAccess کسب کردید و به نظرم از این مرحله به بعد اماده اید که بریم سراغ تنظیمات و کانفیگ این سرویس مهم.
در این قسمت مقدمات و پیش نیازهای نصب DirectAccess را آموزش خواهیم داد.
بعد از انتخاب نوع سرور، فیزیکی یا بیستر مجازی اقدام به نصب DA کنید. شما می توانید DA را علاوه بر محیط GUI در Windows Server 2012 and 2016 در نسخه Core نصب کنید ولی نصب DA در نسخه Core در Windows Server 2008 R2 امکان پذیر نمی باشد. توصیه شده بعد از نصب و کانفیگ DirectAccess محیط GUI را پاک کنید ( آن را به Windows Server core تبدیل کنید).
بعد از تعیین نوع توپولوژی و اقدامات لازم سیستم عامل DirectAccess را نصب می کنیم. من در این سری آموزشی چیزی که در بیشتر سازمانها روال هستش را انتخاب می کنم و آن هم مدل Perimeter/DMZ با یک کارت شبکه می باشد.نکته: چه در محیط تست یا در محیط واقعی جدا از DVD های که در بازار مرسوم هستش که به همراه نصب سیستم عامل یسری برنامه دیگر را نصب می کند خوداری کنید.
برای آن دسته از دوستانی که می خواهند DA را در مد Edge Facing پیاده سازی کنند مراحل زیر را انجام دهند:
سرور باید دو کارت شبکه داشته باشد یکی Internal و یکی External. کارت شبکه Internal می تواند به شبکه DMZ یا LAN متصل شود و دارای یک IP Private می باشد.
و بر روی کارت شبکه External یک IP Public ست می کنیم و یک Default Gateway.
اگر می خواهید از تانل Teredo استفاده کنید باید یک IP public دیگر علاوه بر IP بالا ست کنید. برای اینکار دکمه Advanced را کلیک کنید و
و گذینه Register this connection’s addresses in DNS غیرفعال کنید
و همچنین پروتکل NetBIOS را بر روی این کارت شبکه غیرفعال کنید
و همچنین مطمئن شوید کارت شبکه Internal در تنظیمات Adapters and Bindings اولین گذینه باشد.
بعد از انجام مراحل بالا اگر DirectAccess ما در قسمت DMZ شبکه باشد باید راه دسترسی به شبکه LAN را به این سرور معرفی کنیم. سناریوی زیر را در نظر بگیرید:
پس ما بوسیله دستور زیر به سرور DA می گویم برای دسترسی به شبکه 192.168.100.0/24 ترافیک را به سمت Back-End Firewall ارسال کند.
Route add 192.168.100.0 mask 255.255.255.0 10.10.10.1 –P
اگر دو قسمت قبلی را خوانده باشید شاید تعجب بکنید چرا ما هیچ گونه IPv6 ی را تنظیم نمی کنیم!!!! خوبی DirectAccess همینه با تنظیم و نصب DA ادرسهای IPv6 بصورت اتوماتیک انجام می شود و شما هیچگونه کار خواصی لازم نیست انجام دهید. اگر ساختار شما با IPv6 پیکربندی شده باشد نور علی نوره DA از این تنظیمات استفاده می کند.
یکی از پیش نیازهای DA عضو شدن در Active Directory می باشد. لطفا قبل از Join شدن این سرور یک اسم مناسب به Hostname این سرور اختصاص دهید. همچنین بعد از جوین کردن سرور آن را ابدیت کنید. (اونور ابیا توصیه کردن حتما اینکار را انجام دهید. دوست داشتید سرور را ابدیت کنید)
دوتا گروه ایجاد کنید. یک گروه شامل کامپیوترهای هستش که قراره از DirectAccess استفاده کنند و تنظیمات DA بر روی آنها اعمال شود و یک گروه شامل سرورهای DA. بعدا فایده اینکار را متوجه می شوید.
سرور DA نیاز به دو سرتیفیکت دارد یکی برای تانل IPsec و یکی برای پروتکل IP-HTTPS. برای IPsec می توانید ار تمپلیت Computer استفاده کنید ولی نه بهتر است تمپلیت سفارشی برای اینکار ایجاد کنیم.خواهشا اگر هیچگونه اطلاعاتی درباره Certificate و Certificate Template ها ندارید توصیه می کنم لینک زیر را مطالعه کنید و بعد ادامه مطالب را بخوانید:
پس برای اینکار در کنسول مربوطه بر روی تمپلت Workstation Authentication راست کلیک کنید و گذینه Duplicate Template را انتخاب کنید و مراحل زیر را انجام دهید:
در کادر بالا گروه Authentication User and Domain computers را پاک کنید و گروه های که شامل DA Server و DA Client هستند را اضافه کنید و مجوز بالا را بر روی آنها ست کنید.
برای فعال کردن این پالاسی از لینک بالا که معرفی کردم استفاده کنید.اجازه بدید ی داستان کوتاه و عاشقانه برای شما تعریف کنم که خالی از لطف نیست:) یکی از دوستام برام تعریف می کرد که یک وب سرور در پتروشیمی ..... بنا به دلایلی از کار افتاد این وب سایت اطلاعات را بصورت HTTPS ارسال و دریافت می کرد، قسمت انفورماتیک آن پتروشیمی بعد از سه چهار روز سرو کله زدن نتوانستن مشکل را حل کنند این ور صدای مسئولین درامده بود که چرا تا حالا این مشکل حل نشده.....
خلاصه چند نفر خوشتیپ از شعبه اصلی شرکت اومدن تا مشکل را حل کنند ولی بازم مشکل حل نشد!!!!! همه چیز خوب و صحیح ست شده بود ولی نمی دانستند چرا کسی نمی توانست به این وب سروروصل شود!!!! دیگر خواستند دست به دامن رمال و دعا نویس شوند که یکی از نفرات آن قسمت گفت اقا میشه SSL Certificate وب سایت را چک کنید...... اره درست حدس زدید، Certificate اکسپایر شده بود و به ذهن هیچ کس نمی رسید که مشکل از آن باشد، خب فرتی این خوشتپبا Certificate را Renew کردن و مشکل حل شد.....
وقتی Certificateی 2 یا 5 سال اعتبار دارد بعد از این مدت اکسپایر می شود بعد از این همه مدت یاد اوری این مسئله خیلی سخته در نتیجه تنظیمات بالا بسیار حیاتی و ضروری هستش. بعد از انجام تنظیمات بالا DA Server and DA Client باید این Certificate را بصورت اتوماتیک دریافت کنند.
SSL Certificate برای پروتکل IP-HTTPS لازم و ضروری هستش. توصیه شده این سرتیفیکت را از یک third-party ca دریافت کنید ولی می توانید از یک CA Server داخلی استفاده کنید. وقتی که همه کلاینتها به CA داخلی اعتماد دارند و لیست CRL پابلیش شده و می توانم از اینترنت بهش دسترسی داشته باشم دیگه چه دردی دارم از CA دیگه ای سرتیفیکت درخواست بدم؟؟؟ برای درخواست این سرتیفیکت از لینک زیر استفاده کنید: (آموزش زیر را برای این منظور ایجاد کردم)
بعد از انجام مراحل بالا نوبت به نصب این سرویس می رسد. شما به دو صورت می توانید این سرویس را نصب کنید با استفاده از GUI یا Power Shell. من Power Shell را ترجیح می دهم. برای نصب این سرویس دستور زیر را در Power Shell اجرا کنید:
Install-WindowsFeature DirectAccess-VPN –IncludeManagementTools
That’s it….
اگر چندین DirectAccess Server داشته باشید و همه عضو یک Cluster هستن کارهای بالا باید بر روی تک تک آنها انجام شود. انشالله در قسمت بعدی شروع به تنظیم این سرویس مهم می کنیم.به امید خدا قسمت بعدی از این سری آموزش بعد از 15 یا 20 روز دیگر اماده می شود چون واقعا سرم شلوغه و ازهمه دوستان بابت این مسئله عذرخواهی میکنم.
در قسمتهای قبلی ما DirectAccess را تعریف و سناریو و نحوه پیاده سازی آن و همچنین قابلیت ها و تنظیمت های اولیه آن را توضیح دادیم. در این قسمت تنظیمات بعد از نصب این سرویس را آموزش خواهیم داد.برای اجرای DA کنسول Server Manager را اجرا کنید و گذینه زیر را کلیک کنید:
در بالا دو گذینه دارید. به شدت توصیه می کنم گذینه Getting started wizard را انتخاب نکنید انتخاب این گذینه تنظیمات ناخواسته ای در ساختار ایجاد می کند و از Windows 7 پشتیبانی نمی کند و یک Certificate بصورت Self-Singe اعمال می کند و تنظیمات DA را بر روی همه کلاینتها ست می کند و .....در عوض گذینه Remote Access Setup Wizard را انتخاب کنید با انتخاب این گذینه دست شما باز می باشد و DirectAccess را متناسب با خواسته های سازمان میتوانید تنظیم کنید.
با کلیک گذینه remote access… کادر زیر نمایش داده می شود:
گذینه اول DA and VPN را با هم نصب و کانفیگ می کند. گذینه دوم فقط DA را نصب و کانفیگ می کند. گذینه سوم هم فقط VPN را نصب و تنظیم می کند. ما گذینه دوم را انتخاب میکنیم.
همانطور که می بینید برای تنظیم DA چهار مرحله پیش رو داریم که هر کدام از این مراحل بر روی تنظیمات خاصی زوم می کند.
در این قسمت کلاینتهای که باید تنظیمات DirectAccess بر روی آنها اعمال شود را مشخص می کنیم و همچنین تنظیمات Network Connectivity Assistant را بر روی Windows 8 and 10 را مشخص می کنیم.دکمه Configure را در Step 1 را کلیک کنید:
با انتخاب گذینه اول کامپیوترها و یوزرهای که از اینترنت بوسیله DA به منابع داخلی وصل می شوند دسترسی کامل دارند (طبق پرمیژن های که برای آنها ست می کنیم) و همچنین ادمین می تواند به کامپیوترهای آنها Remote بزند.گذینه دوم برعکس گذینه اول می باشد DA Client ها نمی توانند به منابع شبکه دسترسی داشته باشند و فقط به منظور Remote زدن به آنها از DA استفاده می شود. Next می کنیم
در کادر بالا باید مشخص کنیم تنظیمات DA Client بر روی چه کامپیوترهای اعمال شود. همانطور که در قسمتهای قبلی اشاره کردیم ما باید دو گروه داشته باشیم یک گروه برای کامپیوترهای که همیشه بیرون سازمان هستن و گاه گاهی در سازمان فعالیت می کنند. که باید تنظیمات DA Client بر روی چنین کامیپوترهای اعمال شود. و گروهی که شامل DA Server ها می باشد که تنظیمات DA Server مخصوص سرورها بر روی آنها اعمال شود.
(یادتون باشه این گروه را نباید بر روی پلاسی DirectAccess Server Setting اضافه کرد. شما لازم نیست کاری خاصی انجام دهید تمام تنظیمات بصورت اتوماتیک انجام می شود. گروه سرورهای DA فقط برای دادن مجوز Certificate Enrollment و غیره می باشد) در کادر بالا ما گروه DA Client ها را Add می کنیم.دو گذینه در پایین کادر وجود دارد، گذینه اول یک WMI Filter در گروپ پلاسی ایجاد می کند برای DA Client ها.گذینه دوم باعث میشه DA Clientها چه خارج از سازمان باشند یا داخل سازمان از DirectAccess استفاده کنند و همچنین ترافیک اینترنت چنین کامپیوترهای از DirectAccess عبور می کند.
در کادر بالا ما NCA را برای کلاینتها میتوانیم تنظیم کنیم NCA ابزاری می باشد که در Windows 8 به بالا برای مدیریت ومانیتور کردن ارتباط DirectAccess بوجود آمده است. برای اطلاع بیشتر:
Network Connectivity Assistant
https://blogs.technet.microsoft.com/tip_of_the_day/2013/11/13/tip-of-the-day-network-connectivity-assistant/
در کادر Resources that validate connectivity to the internal network ما می توانیم ادرس یا URL به NCA معرفی کنیم تا با چک کردن آن ادرس NCA مطمئن شود بصورت موفقیت آمیز به DA Server وصل می باشد.ویندوز 8 و ویندوز 10 در اولین ارتباط با DA سرور، URL آن را چک و Resolve می کنند و نیازی نیست در کادر بالا چیزی ایجاد کنیم. و همچنین در پایین می توانیم ایمیلی به NCA معرفی کنیم که اگر کلاینتی قادر به اتصال با DA Server نباشد بتواند با این ایمیل با ادمین مکاتبه کند. و گذینه اخر که واضح می باشد.Finish را کلیک کنید تا به Step 2 برویم
با کلیک کردن Configure در Step 2 کادر زیر ظاهر می شود:
در بالا باید مشخص کنیم از چه توپولوژی استفاده می کنیم؟ که سرور DA خود تشخیص داد که دارای یک NIC و پشت فایروال می باشد.در آخر هم باید یک FQDN اینترنتی یا یک IPv4 بصورت Public به DA Server معرفی کنیم. DA Client بوسیله این ادرس به DA Server وصل می شوند.
در کادر بالا کارت شبکه و Certificateی که برای IP-HTTPS استفاده می شود بصورت اتوماتیک تشخیص داده می شوند. Certificateی انتخاب می شود که ما قبلا برای DA از CA داخلی سازمان با نام DA.Mahshaher.Com درخواست کردیم.
در قسمت بالا باید مشخص کنیم DA Client ها چگونه احراز هویت شوند؟ که در بالا انتخاب کردم که اینکار بوسیله Active Directory انجام شود یعنی هر کسی که می خواهد از خدمات DA استفاده کند باید یک User/Pass در اکتیو دایرکتوری داشته باشد. و همچنین علاوه بر احراز هویت فوق کلاینتها بوسیله سرتیفیکت Computer که بر روی آنها اعمال شده احراز هویت می شوند.
( همه این کلاینتها باید سرتیفیکت تمپلیت Computer بر روی آنها اعمال شود) به عبارت دیگر یوزر و کامپیوتر هر دو بصورت جدا احراز هویت می شوند.در کادر بالا باید CA Server داخلی را مشخص کنیم اگر علاوه بر Root CA یک Intermediate CA در ساختار داشته باشیم که Certificate به Subject ها Issue می کند آن را نیز باید معرفی کنیم.و در آخر به Windows 7 اجازه دادیم از خدمات DA کند. و همچنین می توانید از پلاسی های که در سرویس NAP می باشد استفاده کنید.Finish را کلیک کنید و به Step 3 بروید.
در اولین کادر شما باید وب سرور NLS را به DA معرفی کنید. اگر اطلاعی از NLS ندارید قسمت دوم این سری آموزش را مطالعه کنید. در بالا دو گذینه وجود دارد گذینه اول که گذینه پیشنهادی می باشد NLS بر روی یک Web Server جدا راه اندازی شده است که باید ادرس آن را در کادر مربوطه بنویسید و گذینه دوم NLS را بر روی خود DA راه اندازی می کند. تا می توانید از گذینه دوم اجتناب کنید.
توضیح تنظیمات بالا نیاز به یک مقاله مجزا دارد ولی سعی می کنم بصورت مختصر اینجا توضیح دهم.وقتی که DA Client ها از اینترنت به سازمان بوسیله کانکشن DA متصل می شوند Name Resolution Policy Table (NRPT) درخواست DNS آنها را برای استفاده از منابع سازمان به DNS Server داخلی سازمان ارسال می کند.در در وهله اول شما باید NRPT و نحوه عملکرد آن را بدانید برای شروع می توانید از لینک زیر استفاده کنید:
https://technet.microsoft.com/en-us/library/ee649207(v=ws.10).aspx
در کادر بالا ما مشخص می کنیم که برای هر دامنه از چه DNS Server ی استفاده کنیم. مثلا درخواستهای دامنه Mahshaher.local به سمت DNS Server ی به ادرس 10.10.10.55 ارسال می شود که ادرس DirectAccess می باشد.
در بالا مشاهده می کنید که ادرس NLS فاقد ادرس DNS سرور می باشد. قانونی در NRPTوجود دارد که اگر مقابل یک Namespace ادرس DNSی ست نشود آن Namespace از طریق کانکش DirectAccess قابل دسترسی نمی باشد. (یعنی اگر بیرون از سازمان باشید و بوسیله DA به سازمان متصل شوید نمی توانید به سرور NLS متصل شوید)
ساختار و نحوه دیزاین Namespace در سازمان برای پیاده سازی DirectAccess خیلی مهم می باشد. به عنوان مثال اگر از Split-Brain DNS استفاده می کنید تنظیمات خاصی در کادر بالا باید انجام دهید و همچنین این تعریف برای Non Split-Brain DNS صدق میکند. امیدوارم با این اصطلاحات اشنا باشید.
وقتی ساختار DNS شما بصورت Split-Brain DNS باشد و DA Client ها بیرون از سازمان باشند NRPT درخواست DNS آنها را برای دسترسی به منابع سازمان به DNS محلی ارسال می کند. معمولا NRPT برای Namespaceی که DA Client از آن استفاده می کنند یکسری قوانین ایجاد می کند.خب شما فرض کنید از Split-Brain DNS استفاده می کنید و دو وب سرور دارید یک وب سرور برای پرسنل سازمان و داخل سازمان و یک وب سرور برای کاربران اینترنت. اگر شما تنظیمات را بصورت زیر انجام دهید:
کاربرانی که بوسیله DA به سازمان وصل می شوند فقط توانائی دسترسی به وب سرور داخلی را دارند و نمی توانند به وب سرور اینترنتی دسترسی داشته باشند.اگر می خواهید DA Client ها به وب سرور اینترنتی دسترسی داشته باشند باید تنظیمات را بصورت انجام دهید:
ولی الان DA Client ها دیگر نمی توانند به وب سرور داخلی دسترسی داشته باشند. بخاطر همین دلایل همیشه توصیه می کنیم که دامنه اینترنتی با دامنه داخلی یکی نباشد. مایکروسافت درباره این روش می گوید:
For split-brain DNS deployments, you must list the FQDNs that are duplicated on the Internet and intranet and decide which resources the DirectAccess client should reach, the intranet version or the public (Internet) version. For each name that corresponds to a resource for which you want DirectAccess clients to reach the public version, you must add the corresponding FQDN as an exemption rule to the NRPT for your DirectAccess clients.
ولی وقتی که از Split-Brain DNS استفاده نکنیم اوضاع فرق می کنه تنظیمات راحتی داریم چون دامنه داخلی با خارجی متفاوت هستن. دامنه داخلی و DNS Server آن را مشخص می کنیم و سرویس های که اینترنتی هستن را وارد نمی کنیم درضمن DA Client ها می توانند به ریسورهای داخلی و خارجی سازمان دسترسی داشته باشند. پس در نتیجه تنظیمات ما بدین صورت می باشد:
With a non-split-brain DNS deployment, because there is no duplication of FQDNs for intranet and Internet resources, there is no additional configuration needed for the NRPT. DirectAccess clients can access both Internet and intranet resources for their organization.
خب اومدیم و DA Client ها نتوانستند رکوردهای خود را توسط DNS پیدا کنند یا DNS در دسترس نبود!!! این کلاینت بدبخت چکار کند؟؟؟؟
از IPv6 Link-Local Multicast Name Resolution (LLMNR) and NetBIOS over TCP/IP protocols استفاده می کنند. هااااا چتونه؟؟؟ چرا همچین نگاه می کنید؟؟؟ خب باید این رو یاد بگیرید هر سرویسی یسری سختی های داره.
برای LLMNR لینک زیر را مطالعه کنید:
An Overview of Link Local Multicast Name Resolution
http://www.windowsnetworking.com/articles-tutorials/windows-server-2008/Overview-Link-Local-Multicast-Name-Resolution.html
کلاینتها اگر نتوانند از DNS استفاده کنند از LLMNR و NetBIOS بصورت Broadcast and Multicast استفاده می کنند و به کامپیوتر مقصد وصل می شوند. پروتکل LLMNR برای هر دو IPv4 and IPv6 مورد استفاده قرار می گیرد و قابل Route نیست و فقط در یک سگمنت فعالیت می کند به خاطر همین یک ادم بیکار (هکر) می تواند اطلاعات LLMNR را کپچر کند و Hostname های سرویس ها را بدست آورد و کارهای ناخواسته ای انجام دهد. برای همین ماکروسافت تدابیر امنیتی زیر را در نظر گرفته:
اگر Suffix دیگری در سازمان دارید می توانید در کادر بالا اضافه کنید. و با فعال کردن گذینه Configure DirectAccess clients with DNS client suffix search list می توانید ادرسهای که با Hostname خالی یا single-label names به عنوان مثال https://itpro باشند بصورت اتوماتیک Suffix دومین به آنها ضافه کنید.
نکته زیر را رعایت کنید:
To ensure that unqualified, single-label names resolve to the same intranet resources whether DirectAccess clients are connected to the intranet or the Internet, your DNS suffix search list should match the namespace rules in your NRPT. As a general rule, each DNS suffix for an intranet namespace should correspond to a namespace rule in your NRPT.
در کادر بالا می توانید سرور و سرویسهای را معرفی کنید که به محض کانکت شدن DA Client به آنها متصل می شوند.
بعد از اتمام شدن تنظیمات مرحله سوم Finish را کلیک کنید و بعد از آن دوباره دکمه Finish پایین را کلیک کنید:
بعد از Finish کردن کادری باز می شود که خلاصه ی تنظیماتی که انجام دادید را نشان می دهد.
شما در کادر بالا می توانید تنظیمات را در صورت نیاز تعقیر دهید.
در بالا مشاهده می کنید تنظیماتی که بر روی DA Client اعمال می شود با نام DirectAccess Client Setting و تنظیماتی که بر روی DA Server اعمال می شود با نام DirectAccess Server Setting می باشد.
اگر تنظیمات را از قبل انجام دادید و می خواهید GPO دیگری را انتخاب کنید Browse کنید و آن GPO را انتخاب کنید.
بعد از Apply کردن تنظیمات ایجاد و اعمال می شوند:
بعد از اتمام شدن پروسه بالا بر روی گذینه زیر کلیک کنید:
اگر خطائی یا هشداری مشاهده کردید آن را حل کنید و ادامه تنظیمات را انجام دهید
تمام تنظیمات بالا بوسیله دستورات و اسکریپتهای Power Shell ایجاد شده اند شما می توانید این فرامین و اسکریپتها را در فایلی ذخیره کنید.
بعد از تمام شدن تنظیمات بالا شما میتوانید Optionهای را در سمت چپ کنسول مشاهده کنید. بر روی Operations Status کلیک کنید تا از وضعیت سرویس های DirectAccess مطلع شوید.
همچنین یسری گذینه دیگری هم دارد که ساده و نیازی به توضیح ندارند.
آخرین بخش از تنظیمات DA می باشد که بصورت اختیاری هستش. بصورت پیش فرض فقط ارتباطات بین DA Client و DA Server احراز هویت و رمزگذاری می شود و ارتباطات DA Server و Host درون شبکه داخلی رمزگذاری و احراز هویت نمی شود. اگر می خواهید یک ارتباط End-to-End بصورت امن داشته باشید باید این Host یا سرور را در DA معرفی کنید. برای اینکار قسمت چهارم را Edit کنید و :
گذینه Extend authentication to… را انتخاب و گروهی که شامل سرورها می باشد را Add کنید. در کادر بالا دو گذینه دیگر هم دارید که توضیحات آن را نوشته و نیازی به توضیح ندارد.
آموزش: پابلیش کردن سرور DirectAccess در فایروال TMG
یکی از تفاوت های که بین اتصالات VPN و اتصالات DirectAccess وجود دارد دو طرفه بودن ارتباط DA Client و DA Server می باشد. علاوه بر اتصال DA Client ها به منابع سازمان ادمین می تواند از داخل شبکه به DA Client ریموت بزند و آن را مدیریت کند.ارتباطات بین DA Client and Server استفاده از IPv6 می باشد بصورت مختصر برای اینکه ادمین و Help Disk ها بتوانند DA Client ها را مدیریت کنند باید یک IPv6 بر روی کامپیوترهای آنها ست شود. قبل از هر چیز به اتصال ادمین از درون شبکه به DirectAccess Client ها در اینترنت را Managing Out میگویند. به خاطر داشته باشید.
در IPv6 تانلی وجود دارد که پکتهای IPv6 را درون این تانل کپسوله می کند و با استفاده از بستر IPv4 آنها را منتقل می کند نام این تانل Intrasite Automatic Tunnel Addressing Protocol یا ISATAP می باشد که بصورت پیش فرض بر روی کلاینتها فعال می باشد:
حتما برای شما سوال پیش اومده که فرق بین تانل های 6to4, Teredo and IP-HTTPS و تانل ISATAP در چیست؟؟؟
ما دو نوع تانل داریم:
Overlay tunnels can be configured between border routers or between a border router and a host. An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. ISATAP is designed for transporting IPv6 packets within a site, not between sites.
IPv6 Implementation Guide
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6/configuration/xe-3s/ipv6-xe-36s-book/ip6-tunnel.html
برای اینکه ما بتوانیم از تانل ISATAP استفاده کنیم نیازمند یک ISATAP Router هستیم که تنظیمات IPv6 را به کلاینتهای درون شبکه واگذار کند.
خوشبختانه نیاز به خریدن روتر سخت افزاری ندارید چون خود DirectAccess Server نقش ISATAP Router را ایفا می کند. و با نصب DirectAccess این قابلیت بر روی آن نصب و کانفیگ می شود.
بد نیست یک نگاهی به لینک زیر بندازید:
http://www.isaserver.org/articles-tutorials/general/implementing-windows-server-2012-directaccess-behind-forefront-tmg-part2.html
برای استفاده از روش Managing Out باید به کلاینتها حالی کنیم که از DirectAccess Server به عنوان یک ISATAP Router استفاده کنند. برای اینکار ما می توانیم تنظیمات را بصورت دستی (Power Shell) یا بصورت اتوماتیک (Group Policy) انجام دهیم که من روش اتوماتیک را انتخاب می کنم. ولی قبل از اینکار باید تنظیمات DNS را انجام دهیم.
در بالا گفتیم که تانل ISATAP بصورت پیش فرض بر روی ویندوزها فعال می باشد. خب مسئله بعدی اگر کلاینتها بتوانند اسم ISATAP در DNS را به IP ادرس ISATAP Router ریزالو کنند تمام تنظیمات را بصورت اتوماتیک از ISATAP Router دریافت و بر روی خود اعمال می کنند. پس ما یک اسم به نام ISATAP با IP ادرس DirectAccess Server در DNS ایجاد می کنیم:
یادتون باشه بصورت پیش فرض DNS Server به درخواستهای ISATAP جواب نمی دهد چون ISATAP در لیست DNS Global Query Block list می باشد. برای حدف ISATAP از این لیست دستور زیر را در DNS Server وارد کنید:
Set-DnsServerGlobalQueryBlockList -List wpad
ولی این نوع تنظیمات، حرفه ای و به درد سازمانهای بزرگ نمی خورد فرض کنید Help Disk شما 50 نفر هستند شما باید دستی این دستورات را بر روی این 50 نفر اجرا کنید؟ یک مشکل دیگر هم وجود دارد و آن هم اینکه اگر کاربری بتواند ISATAP را بر روی کامپیوتر خود فعال کند بصورت اتوماتیک تنظیمات ISATAP را دریافت می کند و در صورت داشتن User/Pass میتواند به DirectAccess Client دسترسی داشته باشد. برای حل کردن این مشکلات راه حل زیر را انجام دهید.
بصورت پیش فرض کلاینتها برای دریافت تنظیمات ISATAP به دنبال رکوردی مشابه به ISATAP در DNS هستند و اگر این رکورد را پیدا کنند به ISATAP Router وصل می شوند. برای جلو گیری از اتصال کلاینتها به ISATAP Router ما اسم ISATAP را به اسم دیگری تعقیر می دهیم مانند ISATAP-DA و این اسم را به عنوان یک ISATAP Router به بعضی از کاربران معرفی می کنیم و همچنین ISATAP را نیز فعال می کنیم. جالبه همه این کارا را می توان بوسیله GPO انجام داد.
بعد از ایجاد رکورد بالا برای مدیریت بهتر, یک گروه می سازیم و کامپیوترهای که Managing Out را انجام می دهند را عضو این گروه می کنیم و بعد از آن Policy های زیر را بر روی آنها اعمال می کنیم:
به مسیر بالا رفته و FQDN مربوطه به ISATAP Router را وارد کنید. در مثال بالا FQDN من:
ISATAP-DA.MAHSHAHER.LOCAL
بعد از آن باید ISATAP را بر روی این کامپیوترها فعال کنیم. برای اینکار در همان صفحه و انتخاب گذینه:
و در آخر این Policy را بر روی گروه مورد نظر اعمال کنید.
بعد از اعمال Policy بالا Help Disk ها باید تنظیمات ISATAP را دریافت کنند.
بعد از تنظیمات بالا شما باید ترافیک ICMPv6 وهمچنین ترافیک RDP یا برنامه مورد نظر خود را بر روی ویندوز فایروال DA Client آزاد کنید. برای اینکار ما از Group Policy استفاده می کنیم. برای اینکار:
همچنین بوسیله GPO ریموت دسکتاپ را فعال کنید که فعال کردن و ایجاد رول های بالا یک امر بدیهی هستش ونیازی به توضیح خاصی ندارد.
مرحله بعدی باید درServer DirectAccess به کامپیوترهای Managing out اجازه اتصال به DA client ها را بدهیم. برای اینکار در Step 3 دکمه Edit را کلیک کنید
و FQDN های مورد نظر را وارد کنید. همچنین می توانید با یک دستور اینکار را انجام دهید:
Add-DAMgmtServer -MgmtServer [management server FQDN]
موضوع بعدی که از اهمیت زیادی برخورداره ثبت رکورد DA Client ها در DNS می باشد. برای اینکه ادمین بتواند به DA Client ها وصل شود DA Client ها باید AAA Record خود را در DNS ثبت کنند در غیر این صورت نمی توان به آنها وصل شد.در سناریوی که انجام دادم در مرحله اول DA Client ها نتوانستند رکورد خود را ثبت کنند بعد از کمی سرچ کردن متوجه شدم که باید Policy زیر را تعقیر داد:
بعد از اینکار DA Client ها توانستند رکورد خود را ثبت کنند:
آنهای که از Windows Server 2008 استفاده می کنند حتما لینک زیر را مطالعه کنند.
DNS server requirements for ISATAP
https://technet.microsoft.com/en-us/library/ee382323(v=ws.10).aspx
الان باید بتوانم DA Client را Ping کنم و همچنین به آن Remote بزنم
در سازمانهای بزرگ که تعداد DirectAccess Client ها بیشتر از ۵۰۰ عدد باشد برای اجتناب از single point of failure و افزایش کارائی و availability از Load Balancing استفاده می کنند. Load Balancing اصطلاحی می باشد که برای پخش ترافیک بین دو یا سه سیستم موجود در یک Cluster استفاده می شود. وقتی بخش عظیمی از ترافیک یک سازمان متوجه سرویس خاصی باشد برای کنترول و حفظ آن سرویس از Load Balancing استفاده می کنند و LB این ترافیک را بصورت مساوی بین اعضای یک Cluster پخش می کند.
قبل از اینکه ادامه مقاله را مطالعه کنید حتما لینک زیر را بخوانید:
Overview of Network Load Balancing
https://technet.microsoft.com/en-us/library/cc725691.aspx
DirectAccess از دو نوع LB استفاده می کند:
NLB یک قابلیتی می باشد که وظیفه آن Load Balance کردن ترافیک ورودی می باشد و درون نسخه های Windows Server وجود دارد. استفاده از NLB باعث صرفه جوی در هزینه و زمان هستش و همچنین به راحتی می توان آن را پیاده سازی کرد و حداکثر سیستم های که می توان در یک Cluster فعالیت کنند هشت سیستم می باشد. (در این مقاله از NLB استفاده می کنیم)
NLB از دو مد متفاوت پشتیبانی می کند:
وقتی NLB را نصب می کنید بصورت پیش فرض از این مد استفاده می کند. در این مد یک MAC Address بر روی تمام اعضای Cluster رونویسی و ثبت می شود و باعث می شود ترافیک ورودی توسط تمام اعضای Cluster در دسترس باشد و توسط NLB driver که برروی پشته پروتکل TCP/IP نصب می شود تصمیم گرفته می شود این ترافیک توسط کدام Hostهای پردازش شود.(بحث priority)
در این مد MAC Address سیستم دست نخورد باقی می ماند و multicast MAC address به IP Address کلاستر اعمال می شود. برای درک این موضوع درباره multicast MAC address تحقیق کنید. وقتی ما از این مد استفاده می کنیم بیشتر Router ها نمی توانند ترافیک را به دست IP Address کلاستر یا VIP تحویل دهند برای حل این مشکل ادمین باید یک ARP Record برای IP Address کلاستر بصورت دستی ایجاد کند. توضیح این قضیه و همچنین راه حل آن خارج از بحث این مقاله می باشد.
Microsoft NLB not working properly in Unicast Mode (1556)
https://kb.vmware.com/kb/1556
استفاده از NLB برای سازمانهای کوچک تا متوسط مورد استفاده قرار میگیرد ولی بهترین گذینه برای سازمانهای بزرگ استفاده از External Load Balancer می باشد. در این روش ما برای Load Balancing از دیوایسهای سخت افزاری مانند KEMP Load Balancer و غیره استفاده می کنیم. دیواس های سخت افزاری در لایه های ۳ و ۷ مدل OSI فعالیت می کنند (NLB در لایه ۲ فعالیت می کند) و تا ۳۲ سیستم می توان در یک Cluster ایجاد کرد.
اگر ساختار DirectAccess بر روی بستر Hyper-V پیاده سازی شده است برای اینکه Hyper-V بتواند از مد Unicast Operating Mode استفاده کند باید گذینه Enable MAC address spoofing را بر روی NIC آن VM فعال کنیم. برای اینکار در قسمت تنظیمات VM:
و همچنین برای اماده سازی DirectAccess برای استفاده از NLB در بستر VMware از لینکی که در بالا برای شما قرار دادم استفاده کنید.
قبل از اینکه NLB را بر روی اولین DirectAccess Server فعال وتنظیم کنیم باید تصمیم بگیریم چه تعدا باید عضو یک کلاستر باشند؟ حداقل تعداد هر کلاستر دو سیستم می باشد. و قبل از اینکه سرور جدیدی را عضو یک کلاستر کنید باید سیستم عامل آن را نصب کنید و همچنین رول DirectAccess and NLB را بر روی آن فعال کنید و آن سرور را عضو Domain کنید و غیره. نکته مهم: بر روی سرور جدید فقط رولهای DirectAccess and NLB را نصب کنید آنها را به هیچ وجه تنظیم و دستکاری نکنید. چون به محض اینکه سرور جدید عضو کلاستر شد تنظیمات را از default host دریافت می کند.
اولین مرحله نصب رول NLB بر روی اولین DirectAccess Server می باشد. برای نصب آن دستور زیر را در Power Shell وارد کنید: (یعنی حال می کنم با Power Shell)
Install-WindowsFeature NLB –IncludeManagementTools
مرحله بعدی فعال کردن NLB بر روی DirectAccess می باشد برای اینکار کنسول Remote Access را اجرا کنید و
اولین صفحه را Next کنید و در صفحه بعدی باید نوع Load Balancing را انتخاب کنید:
گذینه اول را انتخاب میکنیم چون از NLB استفاده می کنیم.
یک IP Address در رنج شبکه DMZ خود وارد کنید. این IP Address به این DirectAccess اختصاص داده می شود و IP Address قبلی آن به عنوان VIP برای این کلاستر رزرومی شود. VIP یک IP مجازی می باشد که به کلاستر DirectAccess ها اشاره دارد.
نکته: اگر DirectAccess شما در قسمت Edge شبکه پیاده سازی شده باشد تنظیمات فعلی بالا متفاوت می باشد.
در آخر هم دکمه Commit را کلیک کنید تا تعقیرات اعمال شود.
نکته: تنظیمات NLB همیشه باید توسط کنسول Remote Access Management انجام شود و نباید اینکار را از طریق کنسول NLB انجام دهید.
فرض می کنیم که شما کارهای زیر را بر روی DirectAccess Server جدید انجام دادید.
نکته خیلی مهم: شما باید سرتیفیکت تمپلیت Computer را بر روی این سرور جدید درخواست و نصب کنید. و همچنین باید IP-HTTPS Certificate مربوط به DirectAccess Server اولی را همراه با کلید خصوصی آن Import کنید و بر روی DirectAccess Server جدید در قسمت Personal آن Import کنید. حواستو باشه این مرحله رو با دقت انجام بدید.
خب اگر همه کارهای بالا را با موفقیت انجام دادید نوبت اضافه کردن این سرور به کلاستر می رسد. برای اینکار در اولین DA Server گذینه زیر را کلیک کنید:
DA Server اولی بصورت پیش فرض در این کلاستر عضو شده است برای اضافه کردن سرور جدید دکمه مشخص شده را کلیک کنید
FQDN سرور مورد نظر را می نویسیم و Next می کنیم
در کادر بالا NIC و IP-HTTPS Certificate را چک می کنیم و Next
در کادر بالا Add و در آخر کلید Close را کلیک کنید.
و در نهایت Commit کنید.
تبریک میگم LB با موفقیت پیاده سازی شد.
دوستان خود سرویس DirectAccess و تنظیمات آن از طریق Active Directory بر روی سرورها و کلاینتها اعمال می شود. یعنی شما هر تعقیر در تنظیمات DirectAccess ایجاد کنید این تعقیرات در وهله اول در Active Directory اعمال می شود و بعد بر روی سرورها و کلاینتها از طریق GPO اعمال می شود. اگر احیانا شما تعقیرات را بصورت اشتباه و ناخواسته ایجاد کنید این تعقیرات ممکن است کل ساختار دومین را تهدید کند. مسئله بعدی اگر یکی از DirectAccess Server ها بنا به دلایلی از کار افتاد NLB این سرور را از مدار خارج می کند و ترافیک را به سمت سرورهای فعال هدایت می کند. در آخر هم به این اشاره کنم که گاهی وقتا یکی از اعضای Cluster به دلایلی قابل دسترس نمی باشد و شما هر کار کنید نمی توانید آن را از Cluster خارج کنید خطای زیر را دریافت می کنید:
برای حل مشکل بالا باید این سرور را از دومین خارج کنید و دوباره سرویسها را نصب و تنظیم کنید و دوباره آن را عضو کلاستر کنید.
جزئیات بیشتر در لینک زیر:
DirectAccess load balanced cluster corruption
https://engineeringit.wordpress.com/2014/07/23/directaccess-load-balanced-cluster-corruption/
الان بریم دسته گلی که به آب دادیم رو امتحان کنیم. اگر هیچگونه اطلاعی از Publish کردن DirectAccess Server و نحوه اتصال به آن ندارید لینک زیر را مطالعه کنید:
آموزش: پابلیش کردن سرور DirectAccess در فایروال TMG
به این نکته هم توجه کنید که هنگام Publish کردن سرور DirectAccess ادرس یا IP آن را بر روی VIP کلاستر تنظیم کنید.
از بیرون به DirectAccess وصل شدم و همانطور که در تصویر بالا مشاهده می کنید به DirectAccess 2 یا DA-02.mahshaher.com وصل می باشم. برای تست سرور دو را خاموش میکنم و نتیجه را برسی می کنیم:
سرور دوم نابود شد. الان چک کنیم DA Client به چه سروری وصل می باشد:
Ok???
برای اطمینان شما دوستان میریم Event Viewer رو چک می کنیم ببیینم چی میگه. Event ID 69 مربوطه به NLB میگه:
NLB cluster [192.168.1.3]: NLB is initiating convergence on host 0x1 because host 0x2 is leaving the cluster.
سرور دوم کلاستر را ترک کرد و نتیجه مذاکره یا همون Convergence به نفع Host 1 تصویب شد (تو اخبار زیاد شندیم این جمله رو میگن :)
Event ID 29 مربوطه به NLB می فرماید:
NLB cluster [192.168.1.3]: Host 0x1 converged with host(s): 1. It is now an active member of the NLB cluster and will start load balancing traffic as the default host. The default host is the host with the lowest host priority. It handles all traffic that isn't covered by any of the defined port rules.
بعد از دریافت نکردن Heartbeat از سمت هاست دو ترافیک به سمت هاست 1 هدایت شد و در مد Active قرار گرفت.
و کلاینتهای من کمتر از چند ثانیه دوباره به سازمان کانکت شدند
برای اولین بار یک مقاله فارسی درباره high availability مربوطه به DirectAccess نوشته شده است و برای اولین بار در این انجمن قرار می گیرید.
در این جلسه مشکلاتی که در حین اتصالات DirectAccess پیش می اید و همچنین راه حل آن را بیان می کنیم و همچنین چند ابزار و دستور که در حین پروسه عیب یابی استفاده می شود را برسی می کنیم. این جلسه آخرین جلسه می باشد هر چند در آینده نکات و قابلیتهای جدید DirectAccess (اگر آن قابلیت مورد نیاز و فراگیر شود ) آموزش می دهیم.
گاهی وقتا در تست های که انجام می دهم می بینم که کلاینتها نمی توانند با موفقیت به DirectAccess وصل شوند و با تعجب می بینم که از تانل Teredo استفاده می کنند!!! یا در بعضی از کتابهای تخصصی نوشته اند که اگر سه تانل IP-HTTPS, 6to4 AND Teredo در دسترس کلاینت باشد این کلاینت ممکن است بصورت اشتباه از یکی از این تانلها استفاده کند!!! راه حل این مشکل غیر فعال کردن تانلهای غیر ضروری می باشد. مثلا من در حال حاضر از تانل IP-HTTPS استفاده می کنم و دلیلی نداره تانلهای 6to4 یا Teredo فعال باشند. شما می توانید بصورت دستوری یا از طریق GPO این تانلهای را غیرفعال کنید:
netsh interface Tunnel set state disabled
یا از طریق GPO
Computer Configuration | Policies | Administrative Templates | Network | TCPIP Settings | IPv6 Transition Technologies | 6to4 State = Disabled
بهتره که یک دید کلی از نحوه اتصال DA Client با DA Server داشته باشید. این دید باعث تسهیل در روند عیب یابی می شود و زوتر مشکل را پیدا خواهید کرد.
قبل از عیب یابی ارتباطات DirectAccess باید مطمئن شویم که تنظیمات DA Client and Server دریافت و بر روی آنها اعمال شده است. به عنوال مثال DA Server باید تمام پیش نیازهای آن از جمله نصب کامپوننتها و Certificate ها نصب شود و ارتباط ان با اینترنت و همچنین شبکه داخلی فراهم باشد. همچنین تنظیمات برای DA Client and Server بوسیله GPO دریافت می شود.برای اینکه مطمئن شویم DirectAccess Server تنظیمات را دریافت کرده دستور زیر را اجرا میکنیم:
gpresult /r /scope:computer
و تمام کامپوننتهای آن بصورت صحیح در حال سرویس دادن باشند:
ادمین می تواند با دستور زیرسلامت سرویسهای DA را چک کند:
Get-RemoteAccessHealth | Where-Object HealthState -NE Disabled | Format-Table –Autosize
وقتی DirectAccess دارای دو NIC باشد باید مطمئن شوید که NIC اکسترنال پروفایل Public بر روی آن فعال باشد و NIC اینترنال پروفایل Domain. برای چک کردن این موضوع دستور زیر را وارد کنید:
Get-NetConnectionProfile | Select-Object Name,NetworkCategory
همچنین باید مطمئن شوید که DA Server بتواند به منابع داخلی شبکه دسترسی داشته باشد. و همانطور ارتباط آن با دنیای اینترنت برقرار باشد. همچنین از صحت ریزالو شدن نام DNSی DirectAccess مطمئن شوید:
Resolve-DnsName DA_FQDN
اگر کلاینتها هنگام اتصال به DirectAccess Server با مشکلی روبرو شده اند حتما چک کنید که ترافیک IP-HTTPS به دست DA Server می رسد.(اگر از این تانل استفاده می کنید) بر روی DA Client دستور زیر را اجرا کنید:
Test-NetConnection -Port 443 <FQDN>
نکته: اگر بر روی DA Server and Client انتی ویروس یا فایروالی نصب شده باشد. نباید Windows Firewall را غیرفعال کنید چون تانل های مورد نظر در Windows Firewall ایجاد می شود. و همچنان فایروالهای دیگر نباید مزاحم عملکرد DirectAccess شوند.
برای اینکه DA Client بتوانند به منابع داخلی شبکه دسترسی داشته باشند DA Server باید تمام FQDN منابع داخلی را ریزالو کند. ارتباط DA Server و DNS داخلی را با دستور زیر چک کنید:
Resolve-DnsName <domain>
ارتباط DirectAccess Server با Domain Controller لازمه احراز هویت DA Client می باشد پس ارتباط DA Server با DC را توسط دستور زیر چک کنید:
nltest.exe /sc_verify:<domain>
DA Server برای تانل IP-HTTPS از SSL Certificate استفاده می کند و برای تانل IPsec از سرتیفیکت تمپلیت Computer. SSL Certificate ی که برای DA Server درخواست می دهید باید مورد اعتماد و EKU آن دارای Server Authentication باشد و این سرتیفیکت در قسمت Personal خود DA-Server نصب شود. و همچنین Common Name باید با Internet FQDN دایرکت اکسس یکی باشد. همچنین این Certificate باید معتبر باشد (اکسپایر نشده باشد).
در بیشتر پیاده سازیهای DirectAccess برای راحتی متصل شدن تانل IPSec ادمین شبکه سرتیفیکت تمپلیت Computer را بر روی DA Server and Client نصب می کند.
برای عملی کردن DirectAccess به هیچ وجه نباید IPv6 را بر روی سرور و کلاینت غیرفعال کنید.
برای اینکه DA Server بتواند به خوبی کار کند سرویسهای پایین باید استارت باشند.
برای اینکه کلانتها بتوانند به DA Server وصل شوند در وهله اول باید ارتباط انها با اینترنت برقرار باشد ثانیا یک Computer Account در AD داشته باشند. برای چک کردن این موضوع، دستور زیر را برای ارتباط کللاینت با DC اجرا کنید:
nltest.exe /sc_verify:<domain>
برای اینکه چک کنید کلاینت از چه تانلی برای کپسوله کردن ترافیک IPv4 استفاده می کند از دستور Ipconfig استفاده کنید. همچنین برای اتصال موفقیت آمیز به DirectAccess Server سرویس های زیر باید بر روی کلاینت فعال باشد:
همچنین کلاینت برای اتصال به DA Server باید پروفایل Private or Public بر روی Windows Firewall فعال باشد. اگر اتصال کلاینت با سرور به هر دلیلی برقرار نشد کارهای زیر را انجام دهید:
قسمت CSR در Windows Firewall را چک کنید. و بر روی DirectAccess Policy-ClientToInfra دابل کلیک کنید و در قسمت زیر
چک کنید IP تانل IPsec با IP دایرکت اکسس یکی باشد:
و همین کار را برای بقیه CSR ها انجام دهید.
همچنین تانل IPsec را پینگ کنید. برای پیدا کردن ادرس این تانل دستور زیر را اجرا کنید:
get-DAClientExperienceConfiguration
نکته: برای Ping کردن ادرس فوق ترافیک ICMPv6 echo باید بر روی سرور آزاد باشد. اگر ادرس تانل پینگ می شود ولی ارتباط برقرار نمی شود تانلهای IP-HTTPS 6to4… را چک کنید. اگر تانل مورد نظر سالم و فعال باشد Name resolution. را چک کنید.
برای دیدن ارتباطات IPsec با DirectAccess Server در کنسول Windows Firewall
اگر هیچگونه اتصالی در کنسول بالا مشاهده نکرده اید تنظیمات Certificate کلاینت را چک کنید و مطمئن شوید به درستی تنظیمات Certificate را انجام داده اید.
گاهی وقتا خودم به شخصه می بینم Windows Firewall Profile اشتباها تعقیر می کند ومانع اتصال ارتباط DirectAccess می شود. در یکی از تسهای که انجام دادم کلاینت در شبکه سازمان قرار داشت و با NLS Server در ارتباط بود ولی از DirectAccess استفاده می کرد که بعدا متوجه شدم پروفایل Public بر روی این کلاینت فعال می باشد و طبق این تعقیر ناخواسته کلاینت به خود تلقین می کرد (لامصب کامپیوتر نیست هوش مصنوعیه) در خارج از سازمان می باشد. که بعد از تعقیر پروفایل فایروال مشکل حل شد. برای تعقیر پروفایل فایروال بوسیله Power Shell لینک زیر را مطالعه کنید:
How to force a network type in Windows using PowerShell
http://windowsitpro.com/powershell/how-force-network-type-windows-using-powershell
اگر کلاینت قادر به resolve کردن Namespace سازمان نباشد مشکل آن عدم احراز هویت کلاینت می باشد.و همچنین ممکن است جدول NRPT به درستی تنظیم نشده باشد. جدول NRPT باعث می شود فقط اسامی مربوط به سازمان به سمت DNS64 ارسال شود. در Windows 8 به بالا میتوانید توسط دستور زیر ورودی های این جدول را مشاهده کنید:
get-DnsClientNrptPolicy
نکته: برای Resolve کردن اسامی داخلی سازمان می توانید از دستور Resolve-DNSName استفاده کنید.
نکته: ابزار NSlookup.exe در این ارتباط به خوبی کار نمی کند چون اطلاعی از تنظیمات جدول NRPT ندارد و درخواست خود را توسط ادرس DNSی که بر روی NIC آن ست شده ارسال می کند.
نکته: گاهی وقتا در DA Client ابزار NCA را می بینید که در مد Connecting… هستش (یعنی هنوز وصل نشده :) ولی کانکش DirectAccess وصل هستش و می توانید از آن استفاده کنید. علت این مشکل دسترسی نداشتن کلاینت به ادرس web-probe host می باشد (این URL در Step 1 هنگام کانفیگ DA ایجاد می شود) برای حل این مشکل مطمئن شوید این رکورد به درستی resolve شود و در دسترس کلاینتها قرار بگیرد.
نکته: برای دیدن وضعیت اتصال DirectAccess در کلاینت از دستور get-DAConnectionStatus استفاده کنید.
گاهی وقتا تمام کارهای بالا را انجام می دهید ولی باز هم کلاینتها وصل نمی شوند و شک دارید که این مشکل بوسیله Firewall در کلاینت یا در سرور ایجاد می شود. برای اینکه وضعیت فایروال را در حین اتصال کلاینتها چک کنید دستور زیر را اجرا کنید:
Set-NetFirewallProfile -All -LogFileName c:\firewalllog.txt -LogMaxSizeKilobytes 2767 -LogAllowed True -LogBlocked True
بصورت لحظه ای از فایروال لاگ برداری می کند و لاگها را در مسیر مشخص ذخیره می کند.
به نکته زیر توجه کنید:
There is a known issue with Windows 8.1 and Windows Server 2012 R2, where enabling firewall logging can cause the firewall service to freeze and crash.8 Before enabling firewall logging on these operating systems, ensure that the May 2016 update rollup for Windows 8.1 and Windows Server 2012 R2 (KB3156418) has been installed.
در اینجا چنتا ابزار مفید برای عیب معرفی می کنم که قطعا در این پروسه مفید و سودمند هستش. اولین ابزار Message Analyzer هستش.این ابزار به ادمین شبکه اجازه می دهد که ترافیک داخل تانل IPsec را مشاهده کند.
run the Message Analyzer as an administrator. Click Favorite Sessions and choose Loopback and Unencrypted IPSEC. Attempt to connect to the internal resource and stop the trace when complete. Once finished, network trace information from inside the IPsec tunnel will be visible.
واقعا ابزار جالبیه حتما امتحانش کنید.ابزار دیگه ای که اکثرا باهاش اشنا هستن Nmap هستش. اگر اشتباه نکنم بهش میگن چاقوی همه کاره سوئیسی :). برای تشخیص پورتهای باز سرور مورد استفاده قرار میگیرد. مانند پورتهای مورد استفاده تانل Teredo or IP-HTTPS و غیره
اخرین ابزار هم DirectAccess Client Troubleshooting Tool می باشد به نظرم خودم بهتر از دو ابزار بالائی هستش ( هر کدام از این ابزارها در مواقع خاصی کاربرد دارد) چون تمام اطلاعتی که بهش نیاز دارید را در اختیار شما قرار می دهد.
خب اینم از عیب یابی این سرویس قدرتمند. بصورت خیلی دقیق و ریز مطالب را برای شما توضیح دادم امیدوارم بهره کافی رو برده باشید.در آخر هم اگر برای کسی مهمه که منبع این مقالات چی هستش می توانند از دو کتاب زیر استفاده بکنند:
حرفه ای باشید.