توضیحات

توجه : به همراه فایل word این محصول فایل پاورپوینت (PowerPoint) و اسلاید های آن به صورت هدیه ارائه خواهد شد

 مقاله در مورد اصول VPN در لینوكس‌ دارای 30 صفحه می باشد و دارای تنظیمات در microsoft word می باشد و آماده پرینت یا چاپ است

فایل ورد مقاله در مورد اصول VPN در لینوكس‌  کاملا فرمت بندی و تنظیم شده در استاندارد دانشگاه  و مراکز دولتی می باشد.

توجه : در صورت  مشاهده  بهم ريختگي احتمالي در متون زير ،دليل ان کپي کردن اين مطالب از داخل فایل ورد مي باشد و در فايل اصلي مقاله در مورد اصول VPN در لینوكس‌،به هيچ وجه بهم ريختگي وجود ندارد


بخشی از متن مقاله در مورد اصول VPN در لینوكس‌ :

اصول VPN در لینوكس‌

اشاره
VPN یا Virtual Private Network شبكه‌هایی خصوصی هستند كه در محیط اینترنت ساخته می‌شوند. فرض كنید كه شركت یا سازمانی دارای شعب گوناگونی در سطح یك كشور باشد. اگر این سازمانی بخواهد كه شبكه‌های داخلی شعب خود را به‌یكدیگر متصل كند، چه گزینه‌هایی پیش‌رو خواهد داشت؟ به‌طور معمول یكی از ساده‌ترین راه‌حل‌ها، استفاده از اینترنت خواهد بود. اما چگونه چنین سازمانی می‌تواند منابع شبكه‌های LAN درون سازمانی خود را در محیط نا امن اینترنت بین شعب خود به اشتراك بگذارد؟ از طرف دیگر استفاده از ارتباطات تلفنی راه‌دور و یا خطوط

استیجاری (leased line) نیز هزینه‌های بسیار سنگینی دارند. در نتیجه نمی‌توان از چنین روش‌هایی به‌طور دائم برای اتصال مثلاً چاپگر دفتر مركزی به سیستم‌های شعب راه‌دور استفاده كرد. VPNها راه‌حلی هستند كه سازمان‌ها و مراكز دیگر می‌توانند به‌كمك آن شبكه‌های LAN شعب گوناگون خود را از طریق شبكه اینترنت ( البته با حفظ امنیت) به یكدیگر متصل سازند. در طراحی شبكه‌های VPN، مسائل متنوعی مطرح هستند كه هر یك از آنها تاثیر زیادی بر پارامترهای اساسی

شبكه‌های VPN بر جای می‌گذارند. فاكتورهایی همچون مقیاس‌پذیری و Interoperability یا سازگاری علاوه بر كارایی و امنیت شبكه‌ها، ویژگی‌هایی هستند كه طرح‌های گوناگون VPNها را از یكدیگر متمایز می‌سازند. طراحان شبكه‌های VPN باید به مواردی از قبیل وجود دیواره‌های آتش، مسیریاب‌ها و Netmask و بسیاری از عوامل دیگر توجه كافی داشته باشند. شناخت كافی و صحیح از توپولوژی شبكه منجر به تشخیص صحیح نقل و انتقالات بسته‌های اطلاعاتی و در نتیجه درك نقاط ضعف و آسیب‌پذیر شبكه‌ها و مسائل دیگری از این دست خواهد شد. در این نوشته سعی شده است كه علاوه بر موارد فوق، به موضوعاتی مانند نگهداری از شبكه و كارایی آن نیز پرداخته شود .

Gateway یا دروازه
می‌دانیم كه شبكه‌های VPN قابلیت اتصال شبكه‌های گوناگون را به‌یكدیگر دارند و در این زمینه سناریو‌های متفاوتی مانند host-network و یاnetwork-network مطرح شده‌اند. در تمامی شبكه‌های VPN، از دو میزبان برای انجام امور encryption/decryption در ترافیك شبكه VPN استفاده می‌شود كه به نقاط پایانی (end point) شبكه‌های VPN معروف شده‌اند. زمانی كه یكی از این نقاط و یا هردوی آنها، دسترسی به شبكه‌ای از ماشین‌های دیگر داشته باشند، به آن میزبان مربوطه یك دروازه یا Gateway گفته می‌شود.
مفهوم Gateway یكی از مفاهیم و كلیدواژه‌های استاندارد در بین اصطلاحات شبكه تلقی می‌شود. به عنوان مثال، مسیریابی كه یك سازمان را به ISP خود متصل می‌سازد، یك دروازه محسوب می‌شود. البته بر حسب موضوع می‌توان به همان مسیریابی كه تمام ترافیك شبكه از آن عبور می‌كند، دیواره‌آتش نیز نام داد. در اصطلاح VPN، به چنین دروازه‌ای یك نقطه پایانی گفته می‌شود كه در ابتدای شبكه واقع شده است و دسترسی به VPN را فراهم می‌آورد.
طراحان VPN برای تفكیك سناریوهای گوناگون از یكدیگر، از اصطلاحاتی مانند host-to-host ،host-to-gateway و یاgateway-to-gateway استفاده می‌كنند. اصطلاح نخست، بیان كننده نقطه پایانی VPN است (صرف‌نظر از آن‌كه آن نقطه یك میزبان است یا یك gateway) عبارات دوم و سوم به توصیف كننده نوع اتصال هستند كه می‌تواند یك میزبان دیگر و یا یك شبكه دیگر باشد.
خلاصه آن‌كه زمانی كه گفته می‌شود كه شبكه VPN برای اتصال 19216810 به 19216820 آرایش شده است (یعنی از 19216810 تا 19216820)،‌ منظور آن است‌ كه قرار است دو شبكه به یكدیگر ارتباط یابند. در این مثال می‌توانید فرض كنید كه هر یك از این شبكه‌های دارای دروازه‌ای هستند كه توسط نشانی‌های 19216811 و
19216821 شناسایی می‌شوند و مسئول انتقال ترافیك به شبكه‌های خود هستند.

شكل 1
یك مثال‌
برای كمك به درك بهتر سناریوهای مطرح شده،‌ از یك مثال ساده network-network استفاده می‌كنیم (شكل 1). همان‌طور كه در شكل دیده می‌شود، سناریوی شبكه- شبكه نمایش داده شده، شامل دو شبكه در شهر‌های متفاوت است. در این تصویر شبكه شهر الف با 24/19216820 شناسایی می‌شود. در این شبكه سیستمی به‌نام Bears با نشانی IP به‌صورت 19216811 نقش سرور VPN یا gateway را ایفا می‌كند.
در سمت دیگر نیز شبكه شهر ب دارای آرایش مشابهی است و سیستم Falc

on درآن در نشانی 19216821 در نقش VPN server/Gateway ظاهر شده است.
هر دو شبكه از آدرس‌دهی در ناحیه شبكه خصوصی private network بر اساس مشخصه RFC 1918 بهره می‌برند. در تصویر شماره یك، نشانی‌های خارج از این دو شبكه (مثلاً 280888 و 270777) نشانی‌های مسیر‌یابی اینترنتی (Internet-routable) فرضی هست
نشانی‌های اینترنتی خارجی‌
ممكن است كه از دیدن نشانی‌های 280888 و نشانی دیگر كه در مثال فوق از آن استفاده شده، تعجب كرده باشید. چنین نشانی‌‌هایی صحیح نیستند و همان‌طور كه می‌دانید، هر یك از بخش‌های نشانی‌های IP صحیح در ناحیه‌ای بین صفر تا 255 واقع هستند.
در این شبكه، قصد طراح چنین بوده است كه از نشانی‌های واقعی قابل مسیر‌یابی اینترنتی استفاده نشود، تا بر اثر اشتباه تایپی امكان بر‌قراری یك ارتباط VPN با سیستم‌ خارجی ناشناس وجود نداشته باشد. در نتیجه در طرح‌هایی كه در عمل ارئه می‌شوند، دو راه متصور خواهد بود:
یا باید ازIPهای اختصاصی به عنوان IPهای خارجی استفاده شود، كه به معنی آن خواهد بود كه كاربر باید چنین نشانی‌هایی را با نشانی‌های واقعی قابل مسیر‌یابی اینترنتی تعویض كند.
راه دوم آن است كه از نشانی‌هایی به‌صورت W.X.Y.Z به عنوان نشانی‌خارجی به‌گونه‌ای استفاده شود كه
آن w عددی بزرگ‌تر از 255 و در نتیجه نشانی اینترنتی غیر موجه باشد.
سناریوی شبكه- شبكه (network-network) فوق را می‌توان تنها با یك تغییر به‌گونه‌ای تغییر داد كه تبدیل به شبكه‌ای host-network گردد. برای این‌كار كافی است كه رابط اترنت eth0 و تمام شبكه 24/19216820 را از سیستم Bears برداریم و Bears را به سیستم Falcon متصل سازیم.
به همین طریق می‌توان سناریوی host-network را با برداشتن رابط eth1 و شبكه 24/19216820 از روی سیستم Falcon و تبدیل سیستم‌های Bears و Falcon به تنها سیستم‌هایی كه در VPN قرار دارند، به سناریوی host-host تبدیل ساخت.
البته باید توجه داشت كه قبل از هرگونه تصمیم‌گیری در مورد نوع VPN مناسب، باید ابتدا نیازمندی‌ها با دقت تعیین و تعریف شوند. در ادامه این مقاله چنین ملاحظاتی را مورد نظر قرار خواهیم داد.

توزیع كلیدها a
موضوعKey distribution در بین كلاینت‌های VPN و سرورهای شبكه یكی از نخستین مواردی هستند كه باید در نظر گرفته شوند. توزیع كلیدها می‌تواند شامل دو نوع Key باشد.یعنی كلیدهای متقارن و نامتقارن (symmetric / asymmetric).
انتقال ایمن كلیدها یكی از مهم‌ترین موضوعاتی است كه باید رعایت گردد. در بهترین شرایط شما باید قادر باشید كه از كانال فیزیكی خارج از شبكه كه ایمن هم باشد برای دسترسی به هر دو سیستم‌ها بهره ببرید و تنظیم كلیدها را خود بر عهده گیرید.

البته در عمل و بسیاری از موارد چنین امكانی وجود نخواهد داشت. در صورتیكه شما ناگزیر به توزیع كلیدهای متقارن از راه دور هستید، حداقل اطمینان حاصل كنید كه از پروتكل‌های ایمنی همچون، SFTP-SCP-SSL/TLS استفاده كنید.
به‌خاطر داشته باشید كه پروتكل‌هایی مانند Telnet یا FTP به هیچ وجه امن نیستند و در صورتی‌كه از چنین روش‌هایی برای توزیع كلیدها استفاده كنید، به معنی آن خ

واهد بود كه كلیدهای خود را تقدیم هكر‌ها كرده‌اید. شاید حتی مناسب‌تر باشد كه از یك متخصص ویژه و یا یكی از كارمندان خود برای سفر به سایت راه دور و انتقال كلیدها از طریق دیسكت استفاده كنید.
بحث كلیدهای نامتقارن ( كه شامل یك جفت كلید عمومی و خصوصی هستند)، موضوعی كاملاً متفاوت است. در این موارد، می‌توان كلید عمومی را بدون نگرانی از بابت امنیت، از روش‌‌های معمولی مانند FTP و یا حتی از طریق پست الكترونیك، انتقال داد.
كلیدهای عمومی به‌خودی خود اطلاعات با ارزشی را نمی‌توانند به هكرها انتقال دهند كه از آن بتوان برای نفوذ به شبكه VPN بهره‌برداری كرد. در این روش، وضعیت به‌گونه‌ای است كه پس از دریافت كلید ‌عمومی، كاربر آن را به‌كمك نرم‌افزار VPN نصب كرده و پس از این مرحله از مدیریت شبكه راه دور در سمت مقابل شبكه VPN می‌خواهد تا كلید را با صدای بلند بخواند.
در این سناریو، در صورتی‌كه كلید به‌گونه‌ای انتقال داده شود كه امكان دستكاری آن توسط هكر فرضی وجود داشته باشد، آنگاه شبكه VPN شما در معرض خطری قرار می‌گیرد كه اصطلاحاً به آن حمله man-in-the-middle گفته می‌شود. به‌طور خلاصه، انتقال ایمن كلید مهم‌ترین فاكتور امنیت یك شبكه محسوب می‌شود.
مقیاس‌پذیری
شبكه‌های VPN هم مانند تمامی بخش‌های دیگر ابر‌ساختار شبكه، باید قابلیت تطابق با ترافیك كاری امور اداری یا تجاری سازمان‌ها را دارا باشد و بتواند با تغییر مقیاس‌های سازمانی هماهنگ گردد.
در صورتیكه از شبكه VPN برای اتصال دفتر مركزی یك سازمان به شعب راه‌دور آن بهره گرفته شود و به عبارت دیگر طرح توسعه محدودی برای آن در نظر گرفته شده باشد، احتمالاً چندان درگیر موضوعمقیاس‌پذیری (Scalability) نخواهید بود.
دلیل این مطلب آن است كه اكثر تكنولوژی‌های VPN تا حدودی می‌توانند پاسخگوی نیازمندی‌های توسعه سازمانی باشند.

اما اگر قرار باشد از شبكه VPN در یك ساختار سازمانی بزرگ استفاده شود و كاربران زیادی بخواهند از VPN بهره‌برداری كنند، آنگاه موضوع مقیاس‌پذیری تبدیل به یكی از موارد اصلی در فهرست موضوعات با اهمیت خواهد شد. برای تعریف مقیاس‌پذیری از سه مورد نام برده می‌شود:
قابلیت پشتیبانی از اتصالات بیشتر
سهولت نگهداری و پشتیبانی‌

هزینه‌
پارامترهای فوق تا حد زیادی به نوع و طراحی VPN وابسته هستند. از طرف دیگر توپولوژی انتخاب شده برای شبكه VPN تعیین كننده‌ترین فاكتور سنجش مقیاس‌پذیری محسوب می‌شود.
توپولوژی ستاره‌ای
در ادامه یك شبكه VPN نمونه از نوع network-network را بررسی خواهیم كرد كه در طراحی آن از توپولوژی ستاره‌ای استفاده شده است.
در توپولوژی ستاره، هر یك از سایت‌‌های راه‌دور دارای یك ارتباط VPN با هاب VPN مركزی هستند. هاب VPN مركزی باید قابلیت پشتیبانی از تعداد n ارتباط VPN را داشته باشد كه در اینجا تعداد n برابر است با تعداد سایت‌های راه‌دور. در چنین شبكه‌ای هر جفت از سیستم‌هایی كه قصد ارتباط با یكدیگر را داشته باشند، باید ترافیك خود را به‌صورت ایمن از بین هاب مركزی به مقصد نهایی هدایت كنند.
مزیت اصلی چنین مدلی در آن است كه اضافه كردن سایت‌های جدید (در واقع توسعه پذیری) در چنین آرایشی بسیار سرراست است. اما نقاظ ضعف این آرایش را می‌توان به‌صورت زیر برشمرد:
در شبكه‌های VPN از نوع ستاره‌ای، یك نقطه آسیب‌پذیر مركزی وجود دارد كه در صورت از كار افتادن آن، كل شبكه از كار خواهد ایستاد.
در صورتی‌‌كه كارایی در سیستم هاب مركزی دچار اشكال و نقص شود، در آن صورت كارایی در تمام سیستم‌های VPN راه دور نیز دچار مشكل خواهند شد.
اشكال دیگر آرایش‌های ستاره‌ای آن است كه حتی دو سیستم كه از نظر جغرافیایی نیز به‌یكدیگر نزدیك هستند، باز هم باید از ارسال و دریافت بسته‌های داده از طریق هاب مركزی برای ارتباطات بین خود كمك بگیرند.
البته بسیاری از طراحان شبكه‌های VPN با آرایش ستاره‌ای، بسیاری از مشكلات فوق را به‌وسیله نصب تعداد بیشتری از هاب‌ها در نقاط مختلف شبكه، رفع می‌كنند و بدین ترتیب بار ترافیك شبكه را بین چند هاب تقسیم می‌كنند.
توپولوژی Full Mesh

شكل 3
در شكل 3 نمونه‌ای از یك شبكه VPN در آرایش Mesh كامل را مشاهده می‌كنید. در این شبكه‌ها، هر دو سیستم موجود در شبكه مستقیماً با یكدیگر ارتباط دارند. شبكه‌های Mesh كامل، دارای چندین مزیت و یك اشكال عمده هستند. مزایای چنین شبكه‌هایی عبارتند از:
در این شبكه‌های، خبری از یك نقطه آسیب‌پذیر مركزی نیست و سایت‌ها برای ارتباط با یكد

یگر وابسته به یك هاب مركزی نیستند.
كارایی كلی شبكه به كارایی یك سیستم وابسته نیست.
سایت‌هایی كه از نظر جغرافیایی به یكدیگر نزدیك هستند، در این شبكه‌ها مستقیماً با یكدیگر ارتباط خواهند داشت.

مشكل شبكه‌های VPN در آرایش Mesh كامل، آن است كه در صورت نیاز به اضافه كردن یك گره جدید در شبكه، باید برای هر گره موجود در شبكه یك ارتباط جدید افزوده شود.

شكل 2
همان‌طور كه ملاحظه می‌كنید، اگرچه چنین آرایشی فقط یك نقطه ضعف دارد، اما این نقطه ضعف به‌تنهایی اشكال بزرگ و مهمی محسوب می‌شود.

در چنین شبكه‌هایی، به‌جای آن‌كه نیاز به مدیریت كلیدها در یك سیستم مركزی داشته باشید، ناگزیر به تنظیم كلیدها در یكایك گره‌ها خواهید بود. شبكه‌ای شامل هزار گره را مجسم كنید. تنظیم دستی كلیدها در چنین شبكه‌ای، امری غیر ممكن خواهد بود.

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

در بعضی از شبكه‌های VPN، به‌جای قرار دادن كلیدها بر روی هر سرور، از روش دیگری استفاده كرده‌اند كه درآن اطلاعات كلیدها از یك منبع مركزی برداشت می‌شود. به عنوان مثال، در راه حلی به‌نام FreeS/WAN ترتیبی اتخاذ شده است كه اطلاعات Keyها از DNS استخراج شوند. ضمناً در این روش اطلاعات به‌روش موسوم به opportunistic encryption رمز می‌شوند.
همان‌طور كه گفته شد، یكی از مسائل مهم دیگر در شبكه‌های VPN مسئله مسیریابی است. در شبكه‌های
VPN درصورتی‌كه نخواهید از شیوه‌های تنظیم پارامترهای مسیر‌یابی به‌شكل دستی استفاده كنید، ممكن است ناگزیر به انتشار اطلاعات مسیر‌یابی به شیوه‌های خودكار ( مثلاً از طریق اجرای

پروتكل مسیر‌یابی IGP مانند RIP یا OSFP در شبكه) باشید.
پیاده‌سازی‌های رایگان IPSec برای سكوهای لینوكس و BSD
free S/WAN: یكی از پیشرو‌ترین اجراهای IPSec برای سكوی لینوكس به‌شمار می‌رود و از طر

ف بسیاری از متخصصان استفاده از آن توصیه شده است.
NIST Cerberus: یك پیاده‌سازی IPSec مرجع برای سكوی لینوكس است.
KAME: اجرای IPSec و IPV6 رای هسته‌های BSD است. پروژه KAME هنوز فعال است و توسط كارمندانی كه از سوی بسیاری از شركت‌های بزرگ ژاپنی حقوق دریافت می‌كنند، توسعه داده می‌شود.
OpenBSD: به‌صورت عادی در درون خود IPSec را پیاده‌سازی كرده است.
Pipsec: در واقع انتقال یافته كد BSD IPSec به سكو‌های لینوكسی است. اما تاریخ آخرین ارتقای این مجموعه سال 1998 می‌باشد.
Linux x.kernel: پروژه‌ای در دانشگاه آریزونا كه هدف آن پیاده‌سازی IPSec در هسته لینوكس می‌باشد. حساسیت زیادی در مورد عدم خروج كد این پروژه از آمریكا وجود دارد.
سازگاری‌
در زمینه سازگاری، حتی نرم‌افزارهایی كه بر اساس استاندارد‌های باز و یا RFC توسعه یافته‌اند، نیز دچار مشكلاتی هستند. به عنوان مثال، بسیاری از مدیران شبكه با شرایطی روبرو می‌شوند كه محصولات استاندارد تجاری هم به هیچ وجه با یكدیگر سازگاری ندارند.

در نتیجه در چنین مواقعی ممكن است نیازمندی‌های وابسته به سازگاری منجر به زیر‌پا گذاشتن برخی از تصمیمات و استراتژی‌های شبكه VPN شود.

نخستین موردی كه باید به آن پاسخ داد آن است كه آیا اصولاً ممكن است شرایطی پیش‌آید كه لازم باشد به شبكه VPN دیگری كه به شما تعلق ندارد متصل شوید؟ اگر قرار باشد كه به تجهیزاتی كه به شما تعلق ندارند (و در نتیجه كنترلی بر آن‌ها ندارید) متصل شوید، بهترین گزینه آن خواهد بود كه از استاندارد‌هایی كه كمك بگیریم كه بیشترین سازگاری را ارئه می‌دهند.
از دیدگاه سازگاری، FreeS/WAN انتخاب مناسبی است. IPSec استاندارد دیگری است كه

بسیاری از تولید كنندگان آن را در درون محصولات خود پیاده‌سازی كرده‌اند. اگرچه بعضی از تولید كنندگان تنها بخشی از این استاندارد را در محصولات خود پیاده‌سازی كرده‌اند، با این حال، به‌طور معمول می‌توان در هر دو سمت شبكه‌های VPN به‌گونه‌ای تنظیمات را انجام داد كه مجموعه‌ای از ویژگی‌های مشترك قابل استفاده باشند.
FreeS/WAN از استاندارد رمزگذاری 56 بیتی DES استفاده نمی‌كند و به‌جای آن از رمزنگاری

168
بیتی tripleDES پشتیبانی می‌كند. این موضوع اگرچه از سوی برنامه‌نویسان FreeS/WAN به‌جهت ایجاد امنیت بیشتر انجام شده است، اما باعث عدم سازگاری با محصولات دیگر شده است.
بسیاری از شركت‌ها به‌جهت پشتیبانی از riple DES ،IPSec را نیز در محصولات خود گنجانیده‌اند.
چنین مسایلی تنها برخی از مشكلاتی هستند كه ممكن است در راه اتصال به شبكه‌های خارجی با آن‌ها روبرو شوید.
در نهایت، مسأله سازگاری را می‌توان در این پرسش خلاصه كرد: آیا زمانی نیاز به اتصال شبكه‌هایی خواهیم داشت كه در اختیار و كنترل ما نباشند؟ اگر پاسخ شما به چنین پرسشی مثبت است، باید به استفاده از راه‌حل‌های استاندارد فكر كنید.
در صورتیكه چنین نیازی نداشته باشید، موضوع سازگاری دیگر چندان برای شما اهمیت نخواهد داشت و به‌جای آن می‌توانید توان خود را معطوف به راه‌حل‌هایی كنید كه به نیازمندی‌های توسعه احتمالی آینده شما را به بهترین شكل پاسخ می‌دهند.
چند سكویی
موضوع دیگری كه در زمان انتخاب و تصمیم‌گیری در مورد پیاده‌سازی شبكه‌های VPN اهمیت می‌یابد، این مسئله است كه آیا پكیج VPN ‌انتخاب شده باید بر روی سكو‌های گوناگون اجرا گردد. برخی از بسته‌های VPN بر اساس رابط‌های نرم افزاری كه دارند، در سكوهای مختلف كار می‌كنند. به عنوان مثال، درایور TUN/TAP دارای چنین رابطی است كه توسط cIPe به‌كار گرفته می‌شود. نتیجتا cIPe كمتر به معماری سكو وابسته خواهد بود و به محض آن كه درایور به سكوی جدیدی انتقال داده‌ شود، می‌توان آن را به‌سرعت به شبكه اضافه نمود.

IPSec
PSec استاندارد عملی امنیت IP محسوب می‌شود. در این استاندارد، از رمزنگاری برای احراز هویت و همچنین برای رمزنگاری بسته‌های IP استفاده می‌شود. Authentication یا احراز هویت، تضمین كننده آن خواهد بود كه بسته‌ها واقعاً از طرف فرستنده‌ای كه ادعا می‌كند، ارسال شده‌اند.

رمزنگاری داده‌ها نیز تضمین می‌كند كه اطلاعات در بین راه توسط افراد غیر مجاز خوانده نشده‌اند. بسیاری از تولیدكنندگان بزرگ نظیر مایكروسافت یا Cisco در حال حركت به‌سمت IPSec هستند.

IPSec از سوی دیگر بخشی اجتناب‌ناپذیر از استاندارد IPV 6 (نسل بعدی پروتكل اینترنت) است كه از هم اكنون بر روی IPV 4 به‌كار گرفته شده است. IPSec از سه پروتكل مستقل تشكیل شده است. AH یا Authentication Header كه مسوول تایید هویت در سطح بسته‌ها است. ESP یا Encapsulation Security Payload كه تامین كننده رمزنگاری و تایید هویت است و IKE یا Internet Key Exchange كه مسوول كلید‌های ارتباطی و پارامترهای آن است.

كاربران باید در كنار IPSec از سرورهای DNS با قابلیتDNSSEC برای انتشار كلیدهای عمومی استفاده كنند.

(نسخه‌های فعلی BIND از DNSSEC پشتیبانی می‌كنند) ضمناً در این‌باره مقاله‌ای تحت عنوان <امنیت اطلا‌عات در حین انتقال به وسیله IPSec > در شماره 47 ماهنامه شبكه درج شده است.
هزینه‌

خوشبختانه به دلیل رایگان بودن سیستم‌عامل لینوكس، هزینه‌های نصب و راه‌اندازی شبكه‌های VPN متكی به لینوكس، از هزینه‌های راه‌حل‌های تجاری متداول كمتر هستند. هزینه‌های راه‌حل‌های VPN لینوكسی بیشتر معطوف سخت‌افزار و هزینه‌های پشتیبانی و خدمات نرم‌افزاری خواهد بود.
در صورت استفاده از سیستم‌عامل‌های دیگر، علاوه بر هزینه سیستم‌عامل، باید هزینه‌های

مجوزهای نرم‌افزار‌های VPN را نیز در نظر داشت.

اگرچه VPNهای لینوكسی ارزان هستند، اما بسته‌های VPN موجود برای سكوهای وینتل كمیاب هستند و در نتیجه انتخاب مناسبی برای كاربران VPN محسوب نمی‌شوند (مگر آنكه كاربران همگی لینوكسی باشند). بدین ترتیب در صورتیكه موضوع سكوی كاربران چندان مورد توجه نباشند، راه‌حل‌های لینوكسی بهترین روش پیاده‌سازی شبكه‌های network-network محسوب می‌شوند.

Tunnel Encapsulation
به‌طور معمول VPNها لایه‌ای بر روی شبكه عمومی اینترنت تشكیل می‌دهند كه در آن اطلاعات خصوصی در بسته‌های معمولی TCP/IP جایگذاری و یا به اصطلاح فنی‌تر كپسوله می‌شوند. بدین ترتیب جریانی كه چنین كپسول‌هایی را از یك نقطه به نقطه دیگر هدایت می‌كند، مانند تونلی عمل می‌كند كه دو نقطه را به‌یكدیگر متصل می‌سازد و راه و روزنه‌ای در بین ورودی و خروجی آن وجود ندارد.

بر همین اساس گفته می‌شود كه هرچیزی كه قابلیت كپسوله شدن داشته باشد، را می‌توان بصورت تونلی نیز انتقال داد. به عنوان مثال، شما می‌توانیدپروتكل NetBIOS ،Novel Netware ،SCSI یا حتی IPV 6 را بر روی شبكه‌ای با پروتكل IPV4 تونل بزنید. به‌خاطر داشته باشید كه استفاده از تونل الزاماً به معنی رمزنگاری داده‌ها نیست، هرچند كه در اكثر كاربردها، به رمزنگاری احتیاج دارید.
تعامل VPN و دیواره‌آتش‌
شبكه‌های VPN یكی از ابزارهای برقراری ارتباط بین دو نقطه هستند كه سابقه آنها به اندازه ابزارهای امنیتی مانند دیواره‌های‌آتش نیست. دیواره‌های‌آتش فناوری پذیرفته شده‌ای است كه تقریباً در هر شبكه‌‌ای می‌توان آن را یافت. بنابراین در زمان انتخاب یك راه‌حل VPN باید دقت شود كه بین بسته VPN انتخاب‌شده و دیواره آتش موجود سازگاری كافی وجود داشته باشد.
انواع دیواره‌های آتش‌
Packet filterها ساده‌ترین شكل دیواره‌های آتش هستند. یك فایروال مبتنی بر اصول Packet filter تمام بسته‌های IP عبوری از دیواره‌آتش را با فهرست ACL یا همان Access Control List درونی خود مقایسه می‌كند و در صورتی‌كه آن بسته مجاز به عبور از دیواره آتش باشد،‌ به آن بسته اجازه عبور داده می‌شود و در صورتی‌كه بسته‌ای غیرمجاز، یا به‌سادگی از محیط شبكه حذف می‌گردد و یا آنكه یك پیام خطای ICMP به معنی Reject صادر می‌شود.
Packet filterها فقط به پنج مورد نگاه می‌كنند، نشانی‌های IP مبدا و مقصد در بسته‌های عبوری، درگاه‌های مبدا و مقصد و نهایتاً پروتكل‌ها ( مثلا ًUDP یا TCP و نظایر این‌ها).
از آن‌جایی ‌كه تمامی اطلاعات فوق در سربار بسته‌های عبوری قرار گرفته‌اند، انجام چنین بررسی‌هایی بر روی بسته‌های عبوری بسیار سریع خواهد بود. به دلیل سادگی و سرعت روش عملكرد دیواره‌های آتش ازنوع Packet
filter می‌توان چنین ابزارهایی در درون مسیر‌یاب‌ها جایگذاری كرد و بدین ترتیب از نیاز به نصب یك دیواره‌آتش مستقل بی‌نیاز گردید.
ز طرف دیگر، یكی از اشكالات دیواره‌های آتش از نوع Packet filter نیز در همین موضوع یعنی عدم بررسی دقیق محتویات بسته‌های عبوری نهفته است. به عنوان مثال ممكن است شما یك Packet filter را به‌گونه‌ای تنظیم كرده باشید كه دسترسی محدود به پورت 25 (یعنی پورت پروتكل SMTP یا پست الكترونیك) را فراهم كند، اما به هیچ وجه از آن‌كه چنین پورتی از پروتكل‌های دیگری ممكن است استفاده كند، اطلاعی نخواهید داشت.
مثلاً ممكن است كاربری با اطلاع از این موضوع كه Packet filter امكان عبور از پورت 25 را می‌دهد، SSH را بر روی درگاه 25 سیستمی اجرا كند و بدین ترتیب از دیواره‌آتش عبور كند.
مشكل دیگر Packet filterها آن است كه این ابزارها امكان مدیریت موثر بر پروتكل‌های ارتباطات چند گانه دینامیك را ندارند. به عنوان مثال، پروتكل FTP می‌تواند كانالی باز كند كه از طریق آن فرامینی نظیر user ،RECV و LIST قابل ارسال باشند.
زمانی كه بین دو میزبان اطلاعاتی مانند فایل یا خروجی فرمان LIST در حال عبور باشد، كانال دیگری بین دو سیستم برقرار می‌گردد و برای آن‌كه چنین داده‌هایی بتوانند عبور كنند، لازم است كه یك ACL برای كاركرد FTP فراهم شود. نقطه ضعفPacket filter ‌ها در همین جا آشكار می‌شود. واقعیت آن است كه Packet filterها دارای مكانیسمی برای خواند
Application Gateway
Application gatewayها یك گام فراتر از packet filterها برمی‌دارند. AGها به‌جای آن‌كه فقط به اطلاعات موجود در سربار (header) بسته‌های داده‌ نگاه كنند، به لایه Application توجه می‌كنند. به‌طور معمول به هر یك از AGها، پروكسی گفته می‌شود.
مثلاً پروكسی SMTP كه از پروتكلSMTP پشتیبانی می‌كند. چنین پروكسی‌هایی مسؤول بررسی اطلاعات عبوری برای تعیین صحت كاربرد پروتكل‌های به‌كار رفته هستند.

فرض كنید كه ما در حال راه‌اندازی یك SMPT application gateway هستیم. لازم خواهد بود كه state ارتباطات را با دقت بررسی كنیم. مثلاً این‌كه آیا كلاینت درخواست HELO/ELHO را ارسال كرده است؟ آیا این كلاینت قبل از ارسال درخواست DATA اقدام به ارسال MAIL FROM كرده است؟ تا زمانی كه از پروتكل‌ها تبعیت شده باشد، یك پروكسی دخالتی در ارسال فرامین بین كلاینت و سرور نخواهد كرد.
یك AG باید درك كاملی از پروتكل داشته باشد و وقایع هر دو سمت یك اتصال را پردازش كند. همانطور كه دیده می‌شود، چنین مكانیسمی نیاز به كاركرد پردازنده مركزی خواهد داشت و از عملكرد ابزارهایی مانند Packet filter پیچیده‌تر هستند.
اما در برابر چنین پیچیدگی‌هایی، امنیت بیشتری فراهم خواهد گردید و امكان نفوذ از طریقی مانند اجرای SSH بر روی پورت 25 نخواهد داشت، زیرا یك AG متوجه خواهد شد كه SMTP مورد استفاده نیست.
اما مواقعی وجود دارند كه لازم است اجازه عبور به پروتكلی داده شود كه AG به‌طور كامل از آن پشتیبانی نمی‌كند.SSH یا HTTPS نمونه‌هایی از چنین پروتكل‌هایی محسوب می‌شوند. از آن‌جایی‌كه در این پروتكل‌ها اطلاعات رمزنگاری می‌شوند، امكان بررسی اطلاعات ارسالی و دریافتی برای AGها وجود نخواهد داشت. در این مواقع امكان آن وجود دارد كه دیواره‌آتش به‌گونه‌ای تنظیم شود كه به بسته‌های مربوطه اجازه عبور بدهد. به چنین حالتی در اصطلاح plug گفته می‌شود.
این اصطلاح از نام بخشی از مجموعه ابزار دیواره‌آتش FWTK برداشت شده است كه در آن از فرمانی به‌نام plug-gwاستفاده می‌شود.
به‌دلیل توان پردازش موردنیاز AGها، امكان ادغام چنین ابزارهایی در تجهیزات استاندارد مسیر‌یابی، به‌راحتی فراهم نیست. اما برخی از مسیر‌یاب‌های جدید دارای قابلیت عملكرد مشابه AG هستند. اما همانطور كه گفته شد، برای استفاده از چنین مسیر‌یاب‌هایی باید از پردازنده‌های قوی استفاده شود.
توجه داشته باشید كه حتی AGها را نیز می‌توان به خطا انداخت. به عنوان مثال می‌توانید پروتكل دلخواهی را بر روی SMTP تونل بزنید. چنین كلاینتی می‌تواند داده‌ها را در بخش DATA یك تبادل انتقال دهد و سرور نیز می‌تواند در درون پیام خطا پاسخ دهد.

طبیعت HTTP این موضوع را حتی ساده‌تر می‌كند. SOAP و NET. فقط دو نمونه پذیرفته شده از تونل‌زنی پروتكل‌ها برروی HTTP محسوب می‌شوند. Http tunnel ابزار رایگانی است كه می‌توانید از آن برای تونل‌زنی پروتكل‌ها بر روی HTTP استفاده كنید. این ابزار را می‌توانید از نشانی httptunnel.com دریافت كنید.
نصب دیواره‌آتش‌

امروزه دیگر كاربری را نمی‌توان یافت كه در كنار VPN از دیواره‌آتش استفاده نكند. اما موضوع این است كه استفاده از دیواره‌آتش در كنار VPN نیازمند به طراحی دقیق است و مسایل و نكات بسیاری در طراحی چنین سیستم‌هایی باید مورد توجه قرار گیرد.
سرور VPN بر روی دیواره‌آتش‌
طبیعی‌ترین راه‌حل آن است كه نرم‌افزار VPN را بر روی دیواره ‌آتش نصب كنیم. همان‌طور كه بسیاری از فایروال‌های تجاری دارای اجزای VPN به‌صورت امكانات اختیاری اضافی هستند. در چنین آرایشی شبكه دارای یك نقطه ورودی خواهد بود كه دارای كاربردهای زیر است:
دیواره‌آتش امكان دسترسی به اینترنت را فراهم می‌كند.
دیواره‌آتش امكان دسترسی به شبكه را به سمت خارج محدود می‌كند.
سرویس VPN ترافیك خروجی به سمت كلاینت‌های راه‌دور و شبكه‌های دیگر را رمزنگاری می‌كند.
مزایای قرار دادن VPN بر روی دیواره‌آتش به قرار زیر هستند:
مدیریت و كنترل پارامتر‌های امنیتی فقط از یك نقطه انجام می‌شوند و ماشین‌های كمتری به مدیریت نیاز دارند.
شما می‌توانید با استفاده از همان دیواره‌آتش و ابزارهای موجود برای اعمال سیاست‌های امنیتی بر روی ترافیك VPN نیز بهره ببرید.
اما قرار گیری VPN بر روی دیواره‌‌های آتش دارای معایبی نیز هست:
به دلیل آن‌كه تمام پارامترهای امنیتی از یك نقطه قابل مدیریت هستند، چنین سیستمی باید خیلی ایمن و مطمئن باشد.
اشتباه در تنظیمات دیواره‌آتش منجر به هدایت ترافیك اینترنت به درون VPN خواهد شد.
ترافیك اینترنت و VPN در رقابت با یكدیگر منابع بیشتری از سیستم طلب می‌كنند و در نتیجه ماشین مورد نظر باید از نظر منابع غنی‌ باشد.
دیواره‌های آتش متداول برای لینوكس‌
(Firewall Toolkit (FWTK این ابزار نخستین application gateway در دسترس عموم برای لینوكس محسوب می‌شود و اساس محصول تجاری Gauntlet نیز بوده است. اگرچه از این ابزار به‌طور رسمی در سال‌های اخیر پشتیبانی نشده است، اما با این وجود هنوز در بسیاری از كاربردها از آن استفاده می‌شود. شما می‌توانید آن را از نشانی www.fwtk.org دریافت كنید.
IPF: یكPacket filter لینوكسی برای كرنل‌های قدیمی نسخه 2 است.

Packet filiter :IPChains جدیدتری برای كرنل‌های نسخه 2/2 است. اگرچه برنامه ساده‌ای محسوب می‌شود، اما می‌توان از طریق مدول‌های كرنل از پروتكل‌ها دیگری نیز پشتیبانی كرد. به عنوان مثال، به‌كمك مدول ipmasqftp می‌توان پشتیبانی از پروتكل FTP را نیز اضافه كرد.مشكل عمده IPChains در آن است كه فیلتر‌های بسته‌های كرنل قبل از آن‌كه مدول‌ها بتوانند بسته‌ها را ببینند انجام می‌شود. معنی این مطلب آن است كه باید دسترسی inbound به درگاه‌هایی كه احتمالاً از طرف كرنل به‌كار گرفته خواهند شد را فراهم كنید.

IPTables: نرم‌افزار دیواره آتش برای كرنل‌های 4/2 لینوكس است كه به‌ نام Netfilter نیز شناخته می‌شود. این ابزار از قابلیت‌های Packet filtering و applicaton gateway به‌طور همزمان پشتیبانی می‌كند.

Packet filter :IPFilter پیش‌گزیده برای NetBSD و FreeBSD محسوب می‌شود. البته می‌توان این ابزار را بر روی هسته‌های لینوكس قدیمی با كرنل‌های نسخه 2 نیز اجرا كرد.
Dante: به‌طور معمول از دانته در بسته‌های نرم‌افزاری تجاری بزرگ‌تر استفاده می‌شود. این ابزار در واقع یك
Packet filter در لایه circuit محسوب می‌شود و از دید كاربران پنهان است.
T.REX: این ابزار یك مجموعه نرم‌افزار بسیار پیچیده است كه از قابلیت‌های دیواره‌آتش و application gateway به همراه امكاناتی از قبیل intrusion-detection ،authentication و logging پیشرفته نیز برخوردار است. شما می‌توانید این ابزار را به‌صورت رایگان از نشانی www.opensourcefirewall.com دریافت كنید.
سرور VPN به موازات دیواره‌آتش‌
آرایش دیگری كه برای كاربردهای VPN مناسب به نظر می‌رسد، استفاده موازی از سرور VPN و دیواره آتش است. البته سیستم‌های درونی هنوز به دیواره ‌آتش به عنوان مسیر‌یاب خواهند نگریست. اما می‌توان مسیر‌یاب را به‌گونه‌ای تنظیم كرد كه شبكه پشت VPN را بشناسد و به‌جای تنظیم قوانین مسیر‌یابی در دیواره‌آتش، آن‌ها را در سرور ‌ VPN تنظیم كرد.
مزایای استفاده از سرور VPN و دیواره‌آتش به‌صورت موازی به شرح زیر هستند:
ترافیك VPN به هیچ وجه امكان عبور از دیواره‌آتش را نمی‌یابد. در نتیجه نیازی به تغییر دادن تنظیمات دیواره‌آتش برای پشتیبانی از بسته‌های VPN ‌نخواهد بود. زیرا برخی از پروتكل‌های VPN توسط دیواره‌‌های آتش پشتیبانی نمی‌شوند.
مقیاس‌پذیری سیستم‌های موازی بسیار سهل‌تر انجام می‌شوند. به عنوان مثال، در صورتی‌كه در یابید كه سرور VPN تحت بار زیادی قرار گرفته است، می‌توانید به‌راحتی سرور‌های VPN جدیدی به شبكه اضافه كرده و بار را بین آنها توزیع كنید.
معایب سرور‌های VPN موازی با دیواره‌های آتش شامل موارد زیر است:
سرور VPN مستقیماً به اینترنت اتصال خواهد داشت. در این حالت شما باید از امنیت كامل چنین سیستمی اطمینان داشته باشید. در غیر این صورت یك هكر ممكن است با نفوذ به درون سرور VPN به تمامی شبكه دسترسی بیابد.
در آرایش موازی، شما دارای دو ماشین متصل به اینترنت خواهید بود و باید از تنظیمات صحیح دو سیستم اطمینان داشته باشید. بدین ترتیب حجم كارهای حساس و هزینه‌های مربوط به آنها افزایش خواهد یافت.
سرور VPN در پشت دیواره‌آتش‌

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

طریق اینترنت.
محدودیت‌های ترافیكی VPN تنها بر روی سرور VPN واقع شده‌اند و این موضوع نوشتن و تنظیم قوانین دسترسی را راحت‌تر می‌كند.
اما معایب چنین آرایشی به‌صورت زیر هستند:
به‌دلیل عبور تمام ترافیك از یك سیستم، تاخیر‌های ناخواسته افزایش می‌یابند.
به‌دلیل آن كه دیواره‌آتش در این روش مسئول تفكیك ترافیك VPN از اینترنت خواهد بود و به‌دلیل رمز بودن ترافیكVPN، لازم خواهد بود كه نوعی Packet filter ساده با ACL یا plug proxy به‌كار گرفته شود.
تنظیم دیواره‌آتش برای عبور دادن ترافیك رمزنگاری شده VPN به سرور VPN در برخی از مواقع دشوار خواهد بود. برخی از دیواره‌‌های آتش نمی‌دانند با پروتكل‌هایی غیر از ICMP ،TCP یا UDP چه باید بكنند.
این موضوع به آن معنی است كه پشتیبانی كردن دیواره‌آتش از VPN ‌هایی كه از پروتكل‌هایIP متفاوت نظیر بسته‌های ESP برای IPSec یا بسته‌های GRE برای VPNهای PPTP استفاده می‌كنند، دشوار و در بعضی از موارد غیر ممكن خواهد بود.
در این وضعیت، تمام ترافیك VPN دوبار از یك رشته كابل شبكه عبور خواهد كرد. یك‌بار از سمت كلاینت‌ها به طرف سرور VPN ‌و یك‌بار به‌صورت رمزنگاری شده از سرور VPN به‌سمت كلاینت‌ها. این موضوع ممكن است باعث كارایی شبكه شود.
یك راه‌حل مسأله تأخیر، آن خواهد بود یك كارت شبكه دیگر (eth 1) به سرور VPN افزوده شود كه مستقیماً توسط یك كابل crossover به دیواره‌آتش اتصال یافته باشد. البته در صورتیكه ترجیح دهید، می‌توانید از یك هاب استفاده كرده و یك قطعه یا segment واقعی شبكه ایجاد كنید. بدین‌ترتیب می‌توان ترافیك رمزنگاری شده را به‌جای عبور دادن از شبكه اصلی از این مسیر جدید به مقصد هدایت نمود.
(هرچند كه روش نخست به‌دلیل ساده‌تر بودن از سرعت بیشتری نیز برخوردار خواهد بود). در هر صورت اگر حالت دوم را به روش اتصال نقطه به نقطه اول یعنیVPN-to-Firewall، ترجیح می‌دهید، توصیه می‌كنیم كه نشانی
192168254254 را به دیواره‌آتش تخصیص دهید و از نشانی 192168254253 برای رابط خارجی VPN استفاده كنید. بدین ترتیب نشانی سایر شبكه به‌صورت 252/192168254252 خواهد بود.
تنظیم VPN با دیواره‌آتش اختصاصی‌
در هر یك از آرایش‌هایی كه تشریح گردید، امكان محدود كردن ترافیك عبوری از اتصال VPN وجود دارد. چنین حالتی زمانی مفید واقع خواهد شد كه شبكه‌ها یا میزبان‌های طرف ارتباط در سطوح امنیتی متفاوت قرار داشته باشند. در حالتی كه سرور VPN و دیواره‌آتش بر روی یك سیستم نصب شده باشند، چنین كاربردی را می‌توان به‌سادگی با
استفاده از نرم‌افزار دیواره‌آتش موجود انجام داد.

در حالاتی كه از سرور VPN جداگانه‌ای استفاده می‌كنید، ممكن است از یك ماشین مستقل به عنوان دیواره‌آتش در جلوی سرور VPN استفاده كنید و یا آن‌كه به Packet filter موجود در هسته لینوكس اكتفا كنید. به عنوان مثال، اگر قصد داشته باشید كه به ترافیك ایمیل‌ها اجازه عبور از VPN بدهید، می‌توانید با اجرای تنظیمات بالا‌ در سیستم سرور VPN چنین وضعیتی را پیاده‌سازی كنید.

منابع:

http://linas.org/linux/vpn.html
http://www.informit.com/articles/article.aspp=25946
http://ibilio.org/pub/linux/docs
http://www.astaro.com
http://www.impsec.org/linux

برای دریافت اینجا کلیک کنید

سوالات و نظرات شما

برچسب ها

سایت پروژه word, دانلود پروژه word, سایت پروژه, پروژه دات کام,

آخرین مطالب وبلاگ

نظرات مشتریان

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

Copyright © 2014 cpro.ir