مقاله در مورد اصول VPN در لینوکس‌

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

 مقاله در مورد اصول VPN در لینوکس‌ دارای ۳۰ صفحه می باشد و دارای تنظیمات در 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 برای اتصال ۱۹۲۱۶۸۱۰ به ۱۹۲۱۶۸۲۰ آرایش شده است (یعنی از ۱۹۲۱۶۸۱۰ تا ۱۹۲۱۶۸۲۰)،‌ منظور آن است‌ که قرار است دو شبکه به یکدیگر ارتباط یابند. در این مثال می‌توانید فرض کنید که هر یک از این شبکه‌های دارای دروازه‌ای هستند که توسط نشانی‌های ۱۹۲۱۶۸۱۱ و
۱۹۲۱۶۸۲۱ شناسایی می‌شوند و مسئول انتقال ترافیک به شبکه‌های خود هستند.

شکل ۱
یک مثال‌
برای کمک به درک بهتر سناریوهای مطرح شده،‌ از یک مثال ساده network-network استفاده می‌کنیم (شکل ۱). همان‌طور که در شکل دیده می‌شود، سناریوی شبکه- شبکه نمایش داده شده، شامل دو شبکه در شهر‌های متفاوت است. در این تصویر شبکه شهر الف با ۲۴/۱۹۲۱۶۸۲۰ شناسایی می‌شود. در این شبکه سیستمی به‌نام Bears با نشانی IP به‌صورت ۱۹۲۱۶۸۱۱ نقش سرور VPN یا gateway را ایفا می‌کند.
در سمت دیگر نیز شبکه شهر ب دارای آرایش مشابهی است و سیستم Falc

on درآن در نشانی ۱۹۲۱۶۸۲۱ در نقش VPN server/Gateway ظاهر شده است.
هر دو شبکه از آدرس‌دهی در ناحیه شبکه خصوصی private network بر اساس مشخصه RFC 1918 بهره می‌برند. در تصویر شماره یک، نشانی‌های خارج از این دو شبکه (مثلاً ۲۸۰۸۸۸ و ۲۷۰۷۷۷) نشانی‌های مسیر‌یابی اینترنتی (Internet-routable) فرضی هست
نشانی‌های اینترنتی خارجی‌
ممکن است که از دیدن نشانی‌های ۲۸۰۸۸۸ و نشانی دیگر که در مثال فوق از آن استفاده شده، تعجب کرده باشید. چنین نشانی‌‌هایی صحیح نیستند و همان‌طور که می‌دانید، هر یک از بخش‌های نشانی‌های IP صحیح در ناحیه‌ای بین صفر تا ۲۵۵ واقع هستند.
در این شبکه، قصد طراح چنین بوده است که از نشانی‌های واقعی قابل مسیر‌یابی اینترنتی استفاده نشود، تا بر اثر اشتباه تایپی امکان بر‌قراری یک ارتباط VPN با سیستم‌ خارجی ناشناس وجود نداشته باشد. در نتیجه در طرح‌هایی که در عمل ارئه می‌شوند، دو راه متصور خواهد بود:
یا باید ازIPهای اختصاصی به عنوان IPهای خارجی استفاده شود، که به معنی آن خواهد بود که کاربر باید چنین نشانی‌هایی را با نشانی‌های واقعی قابل مسیر‌یابی اینترنتی تعویض کند.
راه دوم آن است که از نشانی‌هایی به‌صورت W.X.Y.Z به عنوان نشانی‌خارجی به‌گونه‌ای استفاده شود که
آن w عددی بزرگ‌تر از ۲۵۵ و در نتیجه نشانی اینترنتی غیر موجه باشد.
سناریوی شبکه- شبکه (network-network) فوق را می‌توان تنها با یک تغییر به‌گونه‌ای تغییر داد که تبدیل به شبکه‌ای host-network گردد. برای این‌کار کافی است که رابط اترنت eth0 و تمام شبکه ۲۴/۱۹۲۱۶۸۲۰ را از سیستم Bears برداریم و Bears را به سیستم Falcon متصل سازیم.
به همین طریق می‌توان سناریوی host-network را با برداشتن رابط eth1 و شبکه ۲۴/۱۹۲۱۶۸۲۰ از روی سیستم 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

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

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

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

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

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

از بررسی دو نمونه شبکه‌های 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 به سکو‌های لینوکسی است. اما تاریخ آخرین ارتقای این مجموعه سال ۱۹۹۸ می‌باشد.
Linux x.kernel: پروژه‌ای در دانشگاه آریزونا که هدف آن پیاده‌سازی IPSec در هسته لینوکس می‌باشد. حساسیت زیادی در مورد عدم خروج کد این پروژه از آمریکا وجود دارد.
سازگاری‌
در زمینه سازگاری، حتی نرم‌افزارهایی که بر اساس استاندارد‌های باز و یا RFC توسعه یافته‌اند، نیز دچار مشکلاتی هستند. به عنوان مثال، بسیاری از مدیران شبکه با شرایطی روبرو می‌شوند که محصولات استاندارد تجاری هم به هیچ وجه با یکدیگر سازگاری ندارند.

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

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

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

۱۶۸
بیتی 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 > در شماره ۴۷ ماهنامه شبکه درج شده است.
هزینه‌

خوشبختانه به دلیل رایگان بودن سیستم‌عامل لینوکس، هزینه‌های نصب و راه‌اندازی شبکه‌های 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 را به‌گونه‌ای تنظیم کرده باشید که دسترسی محدود به پورت ۲۵ (یعنی پورت پروتکل SMTP یا پست الکترونیک) را فراهم کند، اما به هیچ وجه از آن‌که چنین پورتی از پروتکل‌های دیگری ممکن است استفاده کند، اطلاعی نخواهید داشت.
مثلاً ممکن است کاربری با اطلاع از این موضوع که Packet filter امکان عبور از پورت ۲۵ را می‌دهد، SSH را بر روی درگاه ۲۵ سیستمی اجرا کند و بدین ترتیب از دیواره‌آتش عبور کند.
مشکل دیگر 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 بر روی پورت ۲۵ نخواهد داشت، زیرا یک 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 لینوکسی برای کرنل‌های قدیمی نسخه ۲ است.

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

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

Packet filter :IPFilter پیش‌گزیده برای NetBSD و FreeBSD محسوب می‌شود. البته می‌توان این ابزار را بر روی هسته‌های لینوکس قدیمی با کرنل‌های نسخه ۲ نیز اجرا کرد.
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، ترجیح می‌دهید، توصیه می‌کنیم که نشانی
۱۹۲۱۶۸۲۵۴۲۵۴ را به دیواره‌آتش تخصیص دهید و از نشانی ۱۹۲۱۶۸۲۵۴۲۵۳ برای رابط خارجی VPN استفاده کنید. بدین ترتیب نشانی سایر شبکه به‌صورت ۲۵۲/۱۹۲۱۶۸۲۵۴۲۵۲ خواهد بود.
تنظیم 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