اصول 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.asp?p=25946
http://ibilio.org/pub/linux/docs
http://www.astaro.com
http://www.impsec.org/linux