بنیانگذار انجمن تخصصی فناوری اطلاعات ایران ، هکر کلاه خاکستری ، کارشناس امنیت اطلاعات و ارتباطات
آموزش رفع مشکلات معمول سرویس Secure NAT در TMG
در آموزش های قبلی در خصوص نصب و راه اندازی سرویس TMG 2010 و ارائه خدمات پروکسی سرور و TMG Firewall Client صحبت کردیم ، علاوه بر این سرویس ها گفتیم که بصورت پیشفرض سرویس Secure NAT بدون داشتن هر گونه تنظیم خاص و فقط با اضافه کردن یک Rule ساده یا استفاده از ویزارد اولیه نصب و پیکربندی TMG راه اندازی می شود.در این مقاله قصد داریم به شما شیوه فعالیت سرویس Secure NAT بر روی کلاینت های این سرویس و همچنین روش های مختلفی که برای رفع اشکال ارتباطات این حالت با سرور وجود دارد را با هم بررسی کنیم. همانطور که در آموزش های سری گام به گام یاد گرفتید TMG 2010 به عنوان یک فایروال می تواند بسته به نوع سرویسی که کلاینت ها نیاز دارند به سه روش می تواند اینترنت را در شبکه داخلی شما به اشتراک بگذارد که به شرح زیر می باشند :
دوره های شبکه، برنامه نویسی، مجازی سازی، امنیت، نفوذ و ... با برترین های ایران
سرفصل های این مطلب
- قابلیت ها و امکانات Secure NAT در TMG 2010
- استفاده از Application Filter ها در TMG 2010
- Firewall Client یا TMG Client ارتباطات خودش را مدیریت می کند
- مشکلات دسترسی به وب سایت ها در TMG 2010
- مشکلات ناشی از احراز هویت یا Authentication در فایروال TMG 2010
- مشکلات برقراری ارتباط با همه پروتکل ها در فایروال TMG 2010
- خلاصه
- مشکلات Name Resolution در فایروال TMG 2010
- سناریوی فایروال TMG در حالتی که DNS سرور در شبکه داخلی قرار دارد
- تنظیمات DNS در TMG زمانیکه DNS سرور بر روی Domain Controller شبکه داخلی قرار دارد
- DNS سرور داخلی نمی تواند از DNS سرورهای خارجی Query بگیرد
- DNS سرور شبکه داخلی به عنوان یک Forwarder پیکربندی شده است
- Secure NAT Client ها آدرس DNS سرورهای اینترنتی را روی کارت شبکه خود دارند
- خلاصه
- حالت Secure NAT
- حالت Firewall Client که گفتیم امروزه TMG Client هم گفته می شود
- حالت Web Proxy یا پروکسی سرور
هر کدام از سرویس هایی که در بالا عنوان کردیم و قبلا در سری آموزشی نیز در خصوص آنها توضیح دادیم به روش های مختلفی با فایروال ارتباط برقرار می کنند و هر کدام برای خودشان مزایا و معایبی دارند. مشکلاتی وجود دارد که ویژه هر کدام از این نوع در اصطلاح client type ها هستند . مختص یک نوع از این نوع سرویس ها هستند بنابراین هیچوقت شما در یک سازمان یک راهکار جامع که تمامی نیازهای شما را در خصوص فایروال برطرف کند را نخواهید داشت. در اولین قسمت از این سری مقالات در خصوص Secure NAT Client صحبت خواهیم کرد و روش های مختلفی که برای رفع اشکال این نوع client type وجود دارد را به هم بررسی می کنیم. بعد از اینکه هر دو سری از این مجموعه مقالات را مطالعه کردید شما می توانید اکثر مشکلات اساسی و پایه ای که در Secure NAT به وجود می آید را شناسایی و رفع اشکال کنید.
قابلیت ها و امکانات Secure NAT در TMG 2010
خوب قبل از اینکه به سراغ رفع اشکال برویم بیایید با هم بررسی کنیم که اصلا Secure NAT Client چیست و چگونه کار می کنید ؟ خوب همانطور که می دانید فایروال TMG می تواند درخواست های کلاینت هایی را که سمت آن فرستاده می شوند را پردازش کند ، البته در صورتیکه به شکل Secure NAT Client باشند
هر کامپیوتری که در شبکه داخلی شما دارای یک آدرس Gateway باشد که به فایروال TMG شما اشاره کند این کامپیوتر از نظر TMG یک TMG Secure NAT Client می باشد. هرگاه آدرس Gateway کامپیوتری آدرس کارت شبکه داخلی TMG باشد یعنی اینکه کلیه ترافیکی که از نظر کلاینت باید به بیرون یا اینترنت منتقل شود باید از طریق آدرس Default Gateway منتقل شود ، این آدرس Default Gateway کارت شبکه داخلی TMG باید در Net ID باشد که شبکه و کلاینت شما در آن قرار دارد.
حتی اگر TMG Secure NAT Client در Net ID ای نباشد که TMG قرار دارد آدرس Default Gateway کلاینت باید به Gateway ای اشاره کند که ترافیک را به سمت شبکه ای می برد که در آن TMG Firewall قرار دارد. به این نکته توجه کنید که قابلیت Secure NAT Client برای کلاینت های غیر مایکروسافتی دارای اولویت است برای مثال اگر شما در شبکه خود از سیستم عامل های Mac یا لینوکس یا چیزی شبیه به آنها استفاده می کنید یا حتی گوشی اندرویدی خود شما باید آنها را برای دریافت اینترنت در حالت Secure NAT Client قرار بدهید.
با اینکار شما به آنها اجازه خواهید داد که بتوانند کلیه ترافیک TCP و UDP خود را از طریق اینترنت دریافت و استفاده کنند . استفاده از Secure NAT برای Publish کردن سرورها از درون شبکه نیز بهترین گزینه است ، Publish کردن به این معناست که سرویسی که سرور داخلی ارائه می دهد را به بیرون شبکه ارائه بدهیم . چند مشکل یا بهتر بگوییم اتفاقات معمولی که ممکن است در خصوص TMG Secure NAT با آنها مواجه بشوید به شرح زیر هستند :
- مشکلات با پروتکل های پیچیده یا Complex Protocols
- مشکلات در دسترسی پیدا کردن به وب سایت ها
- مشکلات در دسترسی پیدا کردن به همه پروتکل ها
- مشکلات مربوط به فرآیند Name Resolution
اینها مشکلات یا مسائل معمولی هستند که معمولا با Secure NAT Client ها در شبکه مواجه هستیم ، در این مقاله خواهید دید که براحتی بیشتر این مشکلات را می توانیم با یک سری پیکربندی های ساده رفع کنیم ، مشکلاتی که بیشتر ناشی از پیکربندی نادرست این فایروال هستند.
مشکلات Secure NAT Client ها در TMG و پروتکل های پیچیده یا Complex Protocols
خوب قبل از اینکه به سراغ مشکلات دیگری برویم ابتدا مشکلاتی که در مورد پروتکل های پیچیده یا Complex Protocols در TMG وجود دارد صحبت کنیم. قابلیت Secure NAT مزیت های زیادی دارد که از آن جمله می توانیم به پشتیبانی بسیاری از پروتکل ها اشاره کنیم ، بسیاری از پروتکل های اینترنتی در Secure NAT پشتیبانی می شوند که برخی از آنها شامل موارد زیر است :
- HTTP و HTTPS
- FTP
- SMTP
- NNTP
- NTP
این پروتکل ها البته به استثنای پروتکل FTP به عنوان پروتکل های ساده یا Simple Protocols شناخته می شوند. اما منظور از این کلمه پروتکل ساده چیست ؟ در واقع پرتکل ساده یا Simple Protocol به پروتکلی گفته می شود که نیازی به برقراری Back Channel یا کانال بازگشت برای برقراری ارتباط با سرور مقصد از طریق سرور مقصد ندارد.
برای شفافیت بیشتر در خصوص پروتکل های پیچیده یا Complex Protocol هایی مثل FTP ماجرا به این شکل است که بعد از ارسال درخواست به سرور مقصد بایستی یک Back Channel یا کانال ارتباطی از طریق سرور مقصد به فایروال TMG برقرار شود و نیاز این وضعیت این است که شما یک درخواست ورودی یا inbound request جدید در فایروال ایجاد کنید.
اما خوب تاثیر این موضوع چه چیزی خواهد بود ؟ برای چنین وضعیت هایی که ما می خواهیم از پروتکل های پیچده استفاده کنیم Secure NAT Client ها بایستی از Application Filter های موجود در فایروال TMG استفاده کنند.
استفاده از Application Filter ها در TMG 2010
اگر احساس کردید که Secure NAT client شما نمی تواند به برخی از پروتکل ها دسترسی پیدا کند احتمال بسیار زیاد در این است که این پروتکل نیاز به Back Channel دارد. ساده ترین مثالی که معمولا در سازمان ها درگیر آن می شویم پروتکل ها و پورت های معروف سرویس و دستورات FTP هستند که بصورت استاندارد بر روی دو پورت 20 و 21 کار می کنند.
بعد از اینکه شما به یک FTP سرور از طریق پورت شماره 21 TCP ارتباط برقرار کردید سرور نیاز به باز کردن یک پورت بر روی فایروال TMG بر روی ارتباط شما دارد که برای ارسال داده استفاده می شود و شماره آن 20 می باشد ، درخواست باز شدن این پورت که از طریق FTP سرور ارسال می شود به TMG Firewall می رسد که در این حالت سرور FTP درخواست یک Back Channel داده است.
بصورت پیشفرض زمانیکه فایروال TMG شما چنین درخواستی را از بیرون شبکه دریافت کند آن را به عنوان یک ارتباط inbound از نوع non-ACK در نظر می گیرد و ارتباط را به عنوان یک ارتباط غیرمجاز خارجی شناسایی کرده و آن را مسدود می کند. برای حل کردن این مشکل ما نیاز به استفاده از یک Application Filter داریم.
در این حالت که ما از پروتکل FTP استفاده می کنیم در Application Filter های TMG Firewall 2010 یک FTP Access Application Filter وجود دارد که بایستی فعال شود. Filter ای که در اینجا از آن صحبت می کنیم به ارتباطی که بین Secure NAT Client و FTP سرور ایجاد شده است گوش می کند و ارتباط بازگشتی که قرار است بصورت inbound از طریق FTP سرور به فایروال برقرار شود را قبول می کند
توجه کنید که این موضوع فقط زمانی اتقاق می افتد که شما FTP Access Application Filter را فعال کرده باشید. اگر Secure NAT Client های شما در برقراری ارتباط با برخی از پروتکل ها به مشکل خوردند نرم افزار Firewall Client یا همان TMG Firewall Client را بر روی آن نصب کنید.
اگر بعد از نصب Firewall Client مشاهده کردید که پروتکل مورد نظر براحتی و بدون مشکل کار می کند بنابراین این یک پروتکل پیچیده یا Complex بوده است. اگر مشکل شما با Firewall Client حل شد بنابراین روی این ماشین Firewall Client را نصب کنید به جای اینکه از Secure NAT استفاده کنید.
Firewall Client یا TMG Client ارتباطات خودش را مدیریت می کند
همانطور که اشاره کردیم با استفاده از قابلیت و یا بهتر بگوییم نصب نرم افزار TMG Client بر روی کلاینت هایی که با پروتکل های پیچیده مشکل دارند مشکل استفاده آنها از پروتکل های خاصل حل می شود. دلیل این موضوع این است که TMG Client ها ارتباطاتی که در آن از پروتکل های پیچیده استفاده می شود را به تنهایی و به خودی خود مدیریت می کنند و همیشه نیازمند استفاده از Application Filter های موجود در سرور TMG نیستند.
این موضوع براحتی قابل آزمایش است ، کافیست که یک Protocol Rule در فایروال خود ایجاد کنید که نیاز به استفاده از پروتکل های پیچیده را دارد و شما در این حالت شما نمی خواهید از SOCKS4 Application Filter که باعث برقراری ارتباط این پروتکل هاست استفاده کنید.
قاعدتا نباید این مورد کار کند و پروتکل شما غیرقابل استفاده خواهد شد ، اما جالب اینجاست بدانید که TMG Client براحتی با SOCKS4 کار می کند و این در حالی است که Application Filter مورد نظر ما غیر فعال است ، دلیل آن را گفتیم ، در این حالت Firewall Client به خودی خود این ارتباطات با پروتکل های پیچیده را مدیریت می کند و نیازی به استفاده از SOCKS4 Filter ندارد.
مشکلات دسترسی به وب سایت ها در TMG 2010
Secure NAT Client های می توانند به دو روش مختلف به وب سایت ها دسترسی پیدا کنند. اولین روش به این شکل است که درخواست خود را بصورت مستقیم به وب سرور مقصد ارسال می کنند و روش دوم این است که از یک سرویس پروکسی در این میان به عنوان سرویس رابط استفاده می کنند.
تنها مزیت استفاده از سرویس پروکسی در این میان برای Secure NAT Client ها در این است که آنها می توانند از قابلیت Web Caching ای که در پروکسی سرور راه اندازی شده است استفاده کنند. Web Object هایی که توسط Secure NAT Client ها نیز استفاده می شوند در Web Cache یا به زبان ساده تر در کش سرور قرار می گیرند.
به هر حال علاوه بر این موردی که عنوان کردیم مشکلات دسترسی به وب سایت ها معمولا به دلیل عدم احراز هویت درست یا نیازمندی های احراز هویت ( Authentication Requirement ) می باشد. در پاراگراف بعدی بصورت ویژه در خصوص مشکلاتی که برای احراز هویت ممکن است پیش بیاید می پردازیم.
مشکلات ناشی از احراز هویت یا Authentication در فایروال TMG 2010
یکی از مهمترین مشکلاتی که در خصوص Secure NAT Client ها وجود دارد این است که در این حالت کلاینت ها نمی توانند اطلاعات هویتی خود که در اصطلاح فنی Credentials گفته می شود ره با TMG Firewall ارسال کنند اما این به این معنی نیست که شما نمی توانید هیچ کنترلی بر دسترسی به منابع و وب سایت ها داشته باشید.
در حالت Secure NAT همانطور که در سری آموزشی گام به گام TMG نوشته خودم ( Unity ) اشاره کردم ، این نوع سرویس دهی امکان احراز هویت کاربران را ندارد و شما نمی توانید کاربران را محدود به استفاده از یک وب سایت یا منبع خاص کنید در عوض می توانید این محدودیت را بر اساس آدرس IP و Computer Name انجام دهید که تنها راه محدود کردن Secure NAT می باشد. شما می توانید یک محدوده آدرس IP یا لیستی از کامپیوترهای شبکه را به عنوان Computer Set به فایروال TMG معرفی کنید و کنترل های دسترسی خود را بر روی این Computer Set ها انجام دهید.
به هر حال اگر می خواهید کنترل های دسترسی خود را بر اساس User یا Group در فایروال TMG تعریف کنید قابلیت Secure NAT Client نمی تواند این نیاز شما را برطرف کند. برای اینکه بتوانید به یک Secure NAT Client دسترسی به یک HTTP Content را بدهید باید برای این کلاینت یک Access Rule در فایروال نوشته شود که آدرس IP یا Computer Set ای که کلاینت در آن قرار دارد با با استفاده از یک روش احراز هویتی به نام Anonymous Access به شبکه External یا خارجی شما متصل کند.
این دسترسی بصورت پیشفرض به معنی اضافه شدن گروه Users در انتخاب کاربران برای Access Rule ها می باشد ، All Users یعنی همه کاربران حتی آنهایی که رمز و نام کاربری ندارند که با این روش همان Anonymous Access را ایجاد کرده ایم. توجه کنید که تعیین شرایط احراز هویت در هر یک از Access Rule های فایروال TMG بصورت جداگانه تعیین می شود.
مشکل استفاده از Access Control list هایی که بصورت Anonymous نوشته می شوند برای درخواست های HTTP در این است که این قوانین در صورتیکه با قوانین دیگری که در سازمان وجود دارد و می خواهد کنترل دسترسی بر اساس user و group باشد دچار اخلال خواهد شد.
طبیعتا در محیط هایی که مسائل امنیتی در آنها ملاک محسوب می شود شما به Access Control Rule هایی نیاز دارید که بتوانند عملیات احراز هویت را برای شما انجام دهند. استفاده از User و Group برای احراز هویت امروزه یکی از ملاک های اصلی در پردازش درخواست های HTTP در TMG محسوب می شود.
همانطور که عنوان کردیم Secure NAT Client ها نمی توانند Credentials را ارسال کنند بنابراین بهتر است برای کاربرانی که ما نیاز به تعیین سطوح دسترسی به منایع وب آنها هستیم به جای استفاده از Secure NAT Client ها از Web Proxy Client ها استفاده شود.
ترجیحا حالت Secure NAT و Firewall Client را برای کاربرانی مثل مدیران شبکه و مدیران سازمان استفاده کنید که سر و صدای اصلی اینترنت در سازمان خوابیده شود. فراموش نکنید کار شما به رضایت مدیران وابسته است نه رضایت کاربران ، بنابراین تا می توانید به مدیران سازمان خود حال بدهید ( والا به خدا ) ...
مشکلات برقراری ارتباط با همه پروتکل ها در فایروال TMG 2010
برخی اوقات پیش می آید که Secure NAT Client های شما نمی توانند به اینترنت دسترسی پیدا کنند و در این حالت ارتباط کلی آنها بصورت کامل به اینترنت قطع خواهد بود. دلایل متعددی برای این مشکل وجود دارد که در سناریو های مختلف ممکن است دلایل نیز متفاوت باشد اما بصورت کلی دلایل عدم دسترسی کاربران به اینترنت در حالت Secure NAT به شرح زیر می باشد:
- ممکن است بر روی Secure NAT Client آدرس default gateway به درستی قرار نگرفته باشد.
- ممکن است آدرس DNS سروری که بر روی Secure NAT Client قرار گرفته است به درستی قرار نگرفته باشد.
- ممکن است Access Rule مناسبی برای دسترسی به اینترنت Secure NAT Client ها در TMG نوشته نشده باشد.
این خیلی مهم است که فراموش نکنیم که تنظیمات پیشفرض فایروال TMG به این شکل است که کلیه ترافیک خروجی از شبکه داخلی یا همان در اصطلاح فنی outbound traffic را مسدود می کند و هیچ کلاینتی نمی تواند ترافیک خود را از TMG عبور دهد.
اگر احساس کردید که درست بعد از انجام مراحل نصب TMG کاربران شما نمی توانند به اینترنت دسترسی پیدا کنند ، باید یک Access Control Rule در TMG ایجاد کنید که به آنها اجازه عبور پروتکل های درخواستی خود به اینترنت را بدهد. همانطور که در لیست بالا مشاهده می کنید ، قرار ندادن آدرس default gateway درست برای سیستم های کلاینت ها نیز خود می تواند باعث عدم دسترسی درست کلاینت ها به شبکه اینترنت شود.
زمانیکه با اینگونه مشکلات مربوط به مسیریابی مواجه می شوید همیشه بررسی کنید که routing table کلاینت ها آیا به gateway درستی اشاره می کند یا خیر. مطمئن شوید که اگر در محیطی هستید که ساختار VLAN بندی دارید شبکه ها قادر هستند میان همدیگر مسیریابی داشته باشند. این مهمترین مشکلاتی است که در حالت کلی برای Secure NAT Client ها پیش می آید.
خلاصه
در قسمت اول از این سری مقاله ما مشکلات عمده و کلی که در بحث Secure NAT Client ها پیش می آید را با هم بررسی کردیم . به هر حال مشکلات به همین تعدادی که در این قسمت اشاره شده محدود نمی شود و شما در خصوص مشکلات Secure NAT Client ها مشکلات زیادی در خصوص مباحث مربوط به DNS و احراز هویت خواهید داشت.
در مقاله بعدی بصورت مفصل در خصوص بیشترین مشکلاتی که در حوزه DNS و احراز هویت برای Secure NAT Client ها پیش می آید صحبت خواهیم کرد ، هر گونه ابهامی در خصوص این مقاله برای شما پیش آمده لطفا در ادامه همین مطلب عنوان کنید تا در حد توان Unity بتواند به شما کمک کند.
در قسمت اول از این سری مقاله دو بخشی ، ما در خصوص چگونگی رفع اشکال TMG Secure NAT Client ها صحبت کردیم که شامل مباحثی در خصوص پروتکل های پیچیده یا Complex Protocols و مشکلات دسترسی به وب سایت ها و همچنین مشکلات کلی در برقراری ارتباط با اینترنت بود.
همانطور که در انتهای مقاله قبلی نیز عنوان کردیم یکی دیگر از مشکلات بسیار مهم در رفع اشکال مشکلات ناشی از DNS یا بهتر بگوییم Name Resolution نادرست است. در قسمت دوم از این سری مقاله در خصوص مشکلات مربوط به Name Resolution و DNS و همچنین شیوه طراحی یک ساختار مناسب Name Resolution برای شبکه داخلی و خارجی بسته به محل قرار گیری DNS سرور شما صحبت خواهیم کرد. پس تا انتهای مقاله با ما باشید.
مشکلات Name Resolution در فایروال TMG 2010
اولین نکته ای که در خصوص Name Resolution باید بدانید این است که Secure NAT Client ها نمی توانند از فایروال TMG برای Resolve کردن اسامی وب سایت ها استفاده کنند. به این نکته توجه کنید که بر خلاف TMG Firewall Client ها و Web Proxy Client ها که می توانند فرآیند Name Resolution را به گردن فایروال TMG بیاندازند ، Secure NAT Client ها نمی توانند چنین کاری کنند.
نکته قابل توجه در این خصوص این است که در حالت Secure NAT Client درخواست های DNS با استفاده از آدرس DNS ای انجام می شود که بر روی کامپیوتر کلاینت ها تعریف شده است. در این حالت DNS سروری که مشخص شده است می تواند یک DNS سرور داخلی باشد یا یک DNS سرور خارج از شبکه که در اینترنت وجود دارد. مشکلاتی که مربوط به Name Resolution برای Secure NAT Client ها وجود دارد می تواند بر حسب سناریوی موجود متفاوت باشد ، شرایط کلی زیر در خصوص شیوه قرار گیری DNS سرور ممکن است وجود داشته باشد :
- یک DNS سرور که در شبکه داخلی قرار گرفته است
- یک DNS سرور که در شبکه اینترنت قرار گرفته است
خوب با توجه به شرایط بالا ادامه مقاله را جلو می بریم ، در خصوص مشکلاتی که در هر یک از سناریو های بالا ممکن است پیش بیاید صحبت خواهیم کرد و راهکارهای رفع اشکال هر کدام را نیز به شما ارائه خواهیم داد. لطفا به مفاهیمی که در ادامه عنوان می شود به دقت توجه کنید.
سناریوی فایروال TMG در حالتی که DNS سرور در شبکه داخلی قرار دارد
اگر Secure NAT Client شما بر روی کارت شبکه خود آدرس IP یک DNS سرور را دارد که در شبکه داخلی قرار گرفته است ، شما باید مطمئن شوید که این DNS سرور می تواند آدرس های IP وب سایت ها و منابع اینترنتی که در خارج از شبکه داخلی قرار گرفته اند را Resolve کند. البته بیشتر DNS سرورهای ویندوز های سرور شرکت مایکروسافت این قابلیت را دارند که بتوانند از طریق Query گرفتن از DNS سرورهای اینترنتی آدرس IP مقصد مورد نظر را پیدا کنند .
البته این در حالی است که در داخل فایل cache.dns مستقر بر روی سرور ویندوز آدرس Root سرورهای DNS اینترنتی وجود داشته باشد. همچنین DNS سرورهای ویندوز می توانند از قابلیتی به نام forwarders یا Conditional Forwarders برای بدست آوردن آدرس های IP وب سایت های اینترنتی استفاده کنند و به جای DNS سرورهای داخلی کار کنند .
همانطور که گفتم و باز هم تاکید می کنم اگر Secure NAT Client شما به گونه ای تعریف شده است که از DNS سرور داخلی استفاده می کند باید این DNS سرور به تنهایی عملیات Resolve آدرس های اینترنتی را انجام دهد. اگر نتواند DNS سرور شبکه داخلی این عملیات را انجام دهید و به گونه ای نیز پیکربندی نشده است که از قابلیت های Forwarder و Conditional Forwarding استفاده کند ، ممکن است مشکلات زیر برای شما پیش آمده باشد:
- DNS سرور شبکه داخلی به عنوان یک Domain Controller برای اکتیودایرکتوری نصب شده است و DNS نیز در همین حین توسط ویزارد نصب اکتیودایرکتوری یا همان Active Directory DNS Configuration Wizard انجام شده است.
- Access Rule مناسبی برای عبور کردن Query های DNS برای دریافت اطلاعات بر روی TMG تعریف نشده است.
خوب حالا در خصوص مشکلات احتمالی در این خصوص اطلاعاتی داریم ، بهتر است به سراغ درست کردن این مشکلات برویم ، در همین حین اگر تا کنون اطلاعات دقیقی در خصوص قابلیت های Forwarder و Conditional Forwarding در DNS ندارید می توانید به مقاله زیر از مهندس رمضانی مراجعه کنید که بصورت بسیار جامع و کامل در خصوص این قابلیت های ویندوز سرور توضیح داده اند :
تنظیمات DNS در TMG زمانیکه DNS سرور بر روی Domain Controller شبکه داخلی قرار دارد
مشکلی که در خصوص استفاده از DNS سرورهای داخلی که بر روی Active Directory و بر روی Domain Controller نصب می شوند به محدودیت های برخی از نسخه های ویزارد نصب یا همان Active Directory DNS Wizard بر می گردد. خوب ببینیم در این حین چه اتفاقی می افتد ، اگر در حین نصب DNS ویزارد نتواند به اینترنت و به ویژه DNS سرورهای Root دسترسی پیدا کند ، ویزارد DNS بصورت خودکار خود همین DNS سرور را به عنوان DNS سرور ریشه یا Root تعیین می کند.
زمانیکه این اتفاق می افتد ویزارد نمی تواند Root Hint ها را با نام و آدرس IP هایشان که مربوط به DNS سرورهای ریشه اینترنتی است دور هم یکجا جمع کند و در یک فایل قرار دهد. بنابراین همین عمل باعث می شود که DNS سرور شما نتواند برای Resolve کردن اسامی سرورها Query به DNS سرورهای اینترنتی ارسال کند و آدرس های IP متناظر با اسم را پیدا کند. خوشبختانه برای برطرف کردن این مشکل چند راهکار وجود دارد که به شکل زیر می باشند :
- زمانیکه می خواهید کامپیوتری را به Domain Controller تبدیل کنید Zone مورد نظر را بصورت دستی ایجاد کنید. اگر یک Zone ریشه به عنوان نقطه یا ( . ) در کنسول DNS مشاهده شد شما باید این Zone را بصورت دستی حذف کرده و کامپیوتر را Restart کنید.
- زمانیکه می خواهید کامپیوتری را به Domain Controller تبدیل کنید مطمئن شوید که به اینترنت دسترسی دارد ، در این حالت در هنگام نصب Active Directory به هیچ عنوان root zone برای شما ایجاد نخواهد شد.
اولین گزینه ای که عنوان کردیم به این معناست که شما باید Zone خود را قبل از اینکه با استفاده از دستور dcpromo ایجاد شود بصورت دستی در DNS سرور خود بر روی Domain Controller ایجاد کنید . در این حالت باید به چند نکته توجه داشته باشید ، اول اینکه مطمئن شوید که در Zone شما قابلیت dynamic update فعال است و همچنین نوع Zone از Standard Primary می باشد.
بعد از اینکه فرآیند dcpromo انجام شد کامپیوتر Restart می شود. اگر ویزارد در حین نصب نتواند به اینترنت دسترسی پیدا کند و به ویژه نتواند به Root Server های اینترنتی دسترسی پیدا کند یک zone به نام نقطه به عنوان Root در DNS سرور شما ایجاد می کند. اگر چنین چیزی مشاهده کردید حتما این Zone را حذف کنید و مجددا مطمئن شوید که به اینترنت دسترسی دارید و سپس کامپیوتر را مجددا Restart کنید با اینکار DNS سرور شما می تواند عملیات Query گرفتن از Root DNS های اینترنتی را به درستی انجام دهد.
همانطور که مشاهده کردید در دومین راهکار کار بسیار ساده تر است ، چون شما اصلا نیازی نیست کار خاصی انجام دهید و همه مواردی که گفته شد به یکباره توسط ویزارد انجام می شود. در این حالت شما باید مطمئن باشید که DNS سرور شما می تواند فرآیند گرفتن Query از DNS سرورهای ریشه اینترنتی را به درستی انجام دهد.
توجه کنید که صرفا داشتن اینترنت برای سرور کافی نیست ، شما باید مطمئن شوید که بر روی فایروال شما که در اینجا احتمالا TMG است سرور شما می تواند از طریق پورت شماره 53 UDP به اینترنت دسترسی داشته باشد تا بتواند Query های DNS را به درستی انجام دهد. قطعا برای اینکار یک Access Rule در TMG باید نوشته شود.
DNS سرور داخلی نمی تواند از DNS سرورهای خارجی Query بگیرد
برخی اوقات این مشکل برای شما پیش می آید که DNS سرور داخلی شما نمی تواند از DNS سرورهای خارجی Query بگیرد. زمانیکه این اتفاق رخ می دهد به احتمال بسیار زیاد فایروال TMG ترافیک خروجی پروتکل DNS یا همان DNS Outbound Traffic را مسدود کرده است.
اینکار به دو روش انجام می شود ، دسترسی بصورت کامل با استفاده از یک Deny Rule مسدود شده است و یا اینکه هیچ Rule ای برای Allow کردن این ترافیک نوشته نشده است ، در هر صورت سناریو یکی است. در هر کدام از این شرایط پروتکل DNS بر روی پورت 53 نمی تواند از DNS سرورهای اینترنتی Query بگیرد و ترفیک خود را نمی تواند عبور دهد.
راهکار این مشکل بسیار آسان است ، شما فقط باید بر روی فایروال TMG خود یک Rule اضافه کنید که دسترسی پورتی شماره 53 UDP که پورت ویژه DNS می باشد به شبکه External را ایجاد کنید . اما قبل از اینکه اینکار را بکنید تنظیمات DNS سرور خود را آزمایش کنید اینکار را به روش زیر انجام دهید :
Nslookup www.tosinso.com با استفاده از این دستور تنظیمات را تست کنید
- نکته مهم : توجه کنید که حتما دامنه انتهایی که در اینجا .ir است را در هنگام استفاده از nslookup استفاده کنید ، اگر دامنه های com. و ir. و تمامی Top Level Domain ها را در هنگام استفاده از Nslookup قرار ندهید ، این دستور دامنه مورد نظر شما را FQDN محسوب نکرده و درون دامنه یا همان شبکه داخلی خود به دنبال سرور مورد نظر می گردد و درخواست شما از شبکه خارجی Query گرفته نمی شود.
DNS سرور شبکه داخلی به عنوان یک Forwarder پیکربندی شده است
خوب تا اینجا قطعا متوجه شده اید که DNS سرور شبکه داخلی شما می تواند در نقش یک Forwarder نیز عمل کند اگر فقط این قسمت را مطالعه می کنید پیشنهاد می کنم مقاله بالا از مهندس رمضانی در خصوص Forwarder ها در DNS را مطالعه کنید. با استفاده از Forwarder ها شما فرآیند Name Resolution را در واقع تفکیک اختیار می کنید و به DNS سرورهای اینترنتی واگذاری می کنید که خارج از شبکه شما هستند. برخی اوقات DNS سرور شبکه داخلی شما نمی تواند با آدرسی که به عنوان Forwarder تعریف شده است ارتباط برقرار کند.
اگر مشکلی در برقراری ارتباط با Forwarder ها وجود داشته باشد شما باید مطمئن شوید که Query های DNS می تواند از طریق TMG به اینترنت فرستاده شود . علاوه بر این شما باید مطمئن باشید که آدرس IP ای که برای Forwarder در DNS تعریف شده است به درستی وارد شده است.بسیاری اوقات این مشکلات به خاطر وارد کردن آدرس IP نادرست است ، به قول یکی از همکاران یک بزرگ و کوچک را درست وارد نکرده اید !!! ( گرفتن کلید Shift و وارد کردن عدد 1 = یک بزرگ ) به خدااااااا ... :D
Secure NAT Client ها آدرس DNS سرورهای اینترنتی را روی کارت شبکه خود دارند
برخی اوقات ممکن است آدرس IP سرورهای DNS اینترنتی بصورت مستقیم روی کارت شبکه های Secure NAT Client ها قرار گرفته باشد. البته این در شرایط یک سازمان طراحی درستی نیست اما به هر حال این موارد نیز دیده می شود ، اگر کلاینت شما در این حالت برای دسترسی به اینترنت مشکل داشته باشد باید مطمئن شوید که Access Rule متناسب به دسترسی کلاینت به DNS سرورهای اینترنتی در فایروال TMG تعریف شده باشد.
در اینجا هم باز همان مورد قبلی را بررسی کنید که آیا آدرس درستی برای سرور DNS اینترنتی وارد شده است یا خیر ، در برخی اوقات در سازمان های مختلفی دیده ام که آدرس IP مربوط به DNS سرورهای شرکت Sun با آدرس 4.2.2.2 یا 4.2.2.3 را به عنوان آدرس DNS سرور قرار داده اند اما خوب قبل از این مورد باید بررسی کنید که آیا بصورت کامل این سرورها ایران را پشتیبانی می کنند یا خیر ؟ در بسیاری موارد متاسفانه DNS سرورهای بین المللی با آدرس های DNS ایران با پسوند ir. مشکل دارند.
خلاصه
در این دو قسمت شما متوجه شدید که Secure NAT Client بهترین گزینه برای اینترنت دار کردن کلاینت هایی است که دارای سیستم عامل های شرکت مایکروسافت نیستند ، کلاینت هایی مانند Linux و Mac و امثال اینها درکی از روش های دیگر ارتباطی TMG ندارند یا اگر دارند با دشواری های زیادی همراه است. موارد بسیار زیادی پیش می آید که شما کلاینت های خود را در حالت Secure NAT Client قرار می دهید تا براحتی بتوانند از اینترنت استفاده کنند.
به هر حال در این میان مشکلات زیادی ممکن است پیش بیاید که Secure NAT Client شما دچار اختلال یا مشکل شود و شما نیاز به این دارید که درک کلی از مفهوم و شیوه کارکرد این حالت داشته باشید تا بتوانید آن را رفع اشکال کنید. در این دو مقاله ضمن اینکه راجع به ساختار کلی Secure NAT صحبت کردیم روش های رفع اشکال و اختلالات احتمالی آن را نیز با هم مرور کردیم.
در بسیاری اوقات به محض اینکه متوجه بشوید که مشکل از کجاست با توجه به مطالب گفته شده براحتی می توانید مشکل را حل کنید. در این دو مقاله در خصوص مشکلات Secure NAT با پروتکل های پیچیده ، دسترسی به برخی وب سایت ها ، عدم دسترسی به هر گونه پروتکل و همچنین مشکلات Name Resolution آشنا شدیم . امیدوارم مورد توجه شما دوستان قرار گرفته باشد.