تبیان، دستیار زندگی

اگر کاربران از طریق آدرس IP امکان دسترسی به فایل سرور را داشته باشند، اما با استفاده از نام سرور نتوانند با سرور ارتباط برقرار کنند، محتمل‌ترین دلیل، وجود ایراد در Name Resolution یا تشخیص نام است. تشخیص نام می‌تواند در نام‌ هاست NetBIOS یا DNS مشکل ایجاد کند. 

اگر سیستم‌عامل کلاینت به NetBIOS وابسته باشد، کلاینت‌های *** می‌توانند از طریق سرور *** آدرس سرور WINS را تعیین کنند، اما اگر سیستم‌عامل کلاینت ترجیحاً از DNS استفاده می‌کند، کلاینت‌های *** از طریق یک سرور DNS داخلی به نام سرور شبکه داخلی دسترسی پیدا می‌کنند. 

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

در بعضی مواقع کاربران می‌توانند به سرور *** راه دور متصل شوند، اما نمی‌توانند به هیچ‌کدام از منابع موجود روی شبکه سازمانی دسترسی پیدا کنند. در چنین مواردی کاربران نمی‌توانند نام ‌هاست را شناسایی کرده و حتی قادر نیستند به منابع موجود در شبکه سازمانی Ping کنند. 

رایج‌ترین دلیل وقوع این مشکل این است که کاربران به شبکه‌ای متصل هستند که ID شبکه آن با شبکه سازمانی مستقر در پشت سرور *** یکسان است. به‌عنوان مثال، کاربر به شبکه پرسرعت یک هتل متصل شده و به این ترتیب ID شبکه پس از تخصیص آدرس IP اختصاصی به‌صورت 24/10.0.0.0 اختصاص یافته است. 

حال چنان‌چه شبکه سازمانی نیز روی همین ID شبکه 24/10.0.0.0تعریف شده باشد، آن‌گاه کاربر قادر به اتصال به شبکه سازمانی خود نخواهد بود، زیرا ماشین کلاینت *** آدرس مقصد را به‌صورت شبکه‌ای محلی می‌بیند و اتصال شبکه راه دور را از طریق رابط *** ارسال نمی‌کند. 

دلیل عمده دیگر برای عدم موفقیت در اتصال این است که کلاینت‌های *** اجازه دسترسی به منابع موجود روی شبکه سازمانی را به‌دلیل قوانین تعیین شده از جانب فایروال نمی‌یابند. راه‌حل این مشکل پیکربندی فایروال به‌گونه‌ای است که اجازه دسترسی به منابع شبکه‌ای را به کلاینت‌های *** بدهد.

 کاربران نمی‌توانند از پشت ابزارهای NAT به سرور *** متصل شوند

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

همه ابزارهای NAT و فایروال‌ها در کار با پروتکل‌های *** مبنی بر IPSec از IPSec پشتیبانی می‌کنند. این پروتکل‌های *** شامل پیاده‌سازی‌های اختصاصی مد تونل IPSec و L2TP/IPSec سازگار با RFC خواهند بود. همچنین این دسته از پروتکل‌های *** می‌توانند با استفاده از (Encapsulating) ارتباطات IPSec و در هدر UDP از پیمایش NAT یا (NAT Traversa) پشتیبانی کنند. 

چنان‌چه سرور و کلاینت *** شما از پیمایش NAT پشتیبانی کرده و کلاینت تمایل دارد از L2TP/IPSec برای اتصال به سرور سازگار با NAT استفاده کند، رایج‌ترین دلیل برای این مشکل این است که کلاینت از سیستم‌عامل Windows XP SP2 استفاده می‌کند.

سرویس پک 2 پیمایش NAT Traversal را روی کلاینت‌های L2TP/IPSec به‌اصطلاح می‌شکند. شما می‌توانید این مشکل را از طریق ویرایش رجیستری روی کلاینت *** آن‌گونه که در آدرس زیر توضیح داده شده حل کنید.

http://support.microsoft.com/default.aspx?scid=kb;en-us;885407

 کاربران از سرعت پایین شکایت دارند

سرعت کم یکی از مشکلاتی است که برطرف کردن آن بسیار دشوار است. دلایل زیادی برای کاهش کارایی ارتباط *** وجود دارد و نکته مهم آن هم این است که کاربران بتوانند توضیح دهند دقیقاً در زمان انجام چه کاری با افت کارایی و کاهش در سرعت روبه‌رو می‌شوند. 

یکی از عمده‌ترین موارد هنگام کاهش کارایی ارتباط *** زمانی است که کلاینت در پشت شبکه DSL قرار گرفته و از پروتکل PPPoE استفاده می‌کند. چنین ارتباطات شبکه‌ای معمولاً موجب بروز مشکلات مرتبط با MTU شده که می‌توانند بر هر دو عامل اتصال و کارایی تأثیرگذار باشند. برای اطلاعات بیشتر درخصوص موارد مرتبط با MTU در کلاینت‌های ویندوزی به آدرس زیر مراجعه کنید.

http://support.microsoft.com/default.aspx?scid=kb;en-us;283165

PPTP پروتکل ساده‌ای برای پیکربندی و تنظیم روی سرور و کلاینت *** است. فقط کافی است که کاربر از نرم‌افزار کلاینت توکار *** که به‌همراه تمام نسخه‌های سیستم‌عامل ویندوز ارائه می‌شود استفاده کرده و نام کاربری و کلمه عبور معتبر اکانتی را که مجوز دسترسی از راه دور را دارد، در اختیار داشته باشد. 

اگر کامپوننت سرور *** براساس مسیریابی ویندوز و Remote Access Service باشد، به‌سادگی تنظیم شده و پس از اجرای یک راهنمای پیکربندی کوتاه به‌طور خودکار اجرا خواهد شد. L2TP/IPSec قدری پیچیده‌تر است. اعتبار کاربر و ماشین وی باید توسط سرور *** تأیید شوند. 

تأیید اعتبار ماشین می‌تواند از طریق یک کلید مشترک (Pre-shared Key) یا ماشین ثبت‌شده صورت گیرد. اگر از کلید مشترک استفاده می‌کنید (که معمولاً به دلایل امنیتی توصیه نمی‌شود)، بررسی کنید که آیا کلاینت *** برای استفاده از همان کلید مشترک پیکربندی شده یا خیر؟ اگر از روش ثبت ماشین استفاده می‌کنید نیز مطمئن شوید که کلاینت *** مجوز مربوطه را دارد یا خیر؟

هنگامی که یک ارتباط *** سایت‌به‌سایت بین سرورهای RRAS ویندوزی ایجاد می‌کنید، این امکان وجود دارد که اتصال *** درظاهر برقرار نشان داده شود، اما ترافیکی میان شبکه‌های متصل‌شده رد و بدل نشود. اشکال در شناسایی نام سرورها ایجاد شده و‌هاست‌ها حتی قادر به پینگ کردن به شبکه راه دور نیز نیستند. 

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

به‌طور معمول سرور *** و کلاینت‌ها به‌طور صحیح پیکربندی می‌شوند تا بتوانند از مُد تونل IPSec یا ارتباط L2tp/IP Sec NAT-T برای ارتباط با یک سرور *** استفاده کنند و در نتیجه ارتباط با شکست مواجه می‌شود. در برخی مواقع این اتفاق را بعد از برقراری اتصال موفق اولین کلاینت مشاهده می‌کنید، اما کلاینت‌های بعدی که در پشت همان ابزار NAT قرار دارند، با شکست در ارتباط روبه‌رو می‌شوند. 

دلیل بروز این مشکل این است که تمام سرورهای IPSec NAT-T *** با RFC سازگار نیستند. سازگاری با RFC نیازمند این است که سرور مقصد NAT-T *** از تماس‌های IKE روی پورت منبع UDP 500 پشتیبانی کرده تا آن‌هابتوانند ارتباطات چندگانه را از چندین کلاینت در پشت یک گیت‌وی *** واحد مالتی‌پلکس کنند. 

حل این مشکل از طریق تماس با فروشنده سرور *** و حصول اطمینان از این‌که پیاده‌سازی *** IPSec NAT-T با RFC سازگاری دارد یا خیر، امکان‌پذیر خواهد بود. اگر این‌گونه نبود، از فروشنده درباره وجود Firmware برای به‌روز رسانی سؤال کنید.

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

دلیل عمده برای این مشکل این است که سرور *** ورودی‌های جدول روزمره را برای تمام IDهای شبکه‌هایی که کاربر نمی‌تواند به آنان متصل شود، در اختیار ندارد. کاربران فقط قادر به اتصال به سرورهایی هستند که روی زیرشبکه سرور *** باشند، اما از طریق سرور *** قادر به ارتباط با IDهای شبکه راه‌دور نیستند.

راه‌حل این مشکل پرکردن جدول مسیریابی روی سرور*** به‌گونه‌ای‌ است که آدرس گیت‌وی تمام IDهای شبکه‌هایی را که *** باید به آنان متصل شود، در آن وجود داشته باشد.

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

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

راه‌حل این مشکل پیکربندی سرور *** به‌گونه‌ای است تا به کلاینت‌ها اجازه دسترسی به اینترنت را بدهد. سرور RRAS ویندوز و بسیاری از فایروال‌ها از چنین پیکربندی پشتیبانی می‌کنند. در برابر اصرار برای غیرفعال کردن تنظیمات پیکربندی کلاینت *** جهت استفاده سرور *** از گیت‌وی پیش‌فرض خود مقاومت کنید. زیرا این کار ویژگی Split Tunneling را که یکی از تهدیدات شناخته‌شده و خطرناک امنیتی محسوب می‌شود، فعال خواهد کرد

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

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

به‌عنوان مثال، شما می‌توانید مجوز کلاینت کاربر را نیز بررسی کنید. به‌این ترتیب، هیچ کاربر دیگری نمی‌تواند با مجوز یک کاربر مجاز وارد شبکه شود. انتخاب دیگر استفاده از کارت‌های هوشمند، ابزارهای بیومتریک و دیگر روش‌های دو فاکتوری تعیین هویت است.