topleecher
04-30-2011, 11:53 AM
آشنايي با OpenVPN
ايجاد زيرساخت يك محيط اطلاعاتي با قابليت دسترسي به منابع داده مختلف از طريق فناوري
http://www.shabakeh-mag.com/Data/Articles/Items/2011/4/1004640.jpg آيا تا به حال پيش‌آمده‌است که بخواهيد مجموعه‌اي از سرورهاي مرتبط به هم را در محيط‌هاي مجزا از هم و مربوط به سرويس‌دهندگان مختلف قرار دهيد تا برنامه‌هاي مرتبط به هم در اين سرورها، از طريق مسيرهاي ارتباطي نظير LAN با هم ارتباط برقرار كنند؟
آيا تا به حال پيش‌آمده‌است که بخواهيد مجموعه‌اي از سرورهاي مرتبط به هم را در محيط‌هاي مجزا از هم و مربوط به سرويس‌دهندگان مختلف قرار دهيد تا برنامه‌هاي مرتبط به هم در اين سرورها، از طريق مسيرهاي ارتباطي نظير LAN با هم ارتباط برقرار كنند؟ به ياد داشته‌باشيد كه معمولاً در اين شرايط براي ارتباط ميان سرورها، موانع امنيتي و كنترلي متعددي شامل لايه‌هاي مختلفي از ديواره آتش و NAT وجود خواهد داشت. شايد هم به دلايل مالي يا به منظور بهبود كيفيت خدمات، مي‌خواهيد ميزبان جديدي را براي سرويس‌هاي خود انتخاب كنيد، اما ترجيح مي‌دهيد فرآيند مهاجرت به محيط جديد را به صورت تدريجي و نه لحظه‌اي انجام دهيد تا از مشكلات ناشي از پايين‌بودن سرويس‌ها براي مدت طولاني هنگام انتقال ناگهاني جلوگيري كنيد. در سناريوي ديگري ممكن است بخواهيد بخشي از زيرساخت سخت‌افزاري مورد نياز را براي پياده‌سازي سرويس‌هاي خود، و نه همه آن‌ها، از طريق ابر محاسباتي Amazon EC2 فراهم كنيد. اگر به هر يك از پرسش‌هاي فوق جواب مثبت بدهيد، در اين صورت شما به شدت به يك زيرساخت IT نياز داريد تا بتواند امكان ارتباط بدون دردسر را بين چندين منبع اطلاعات و سرويس فراهم كند.
ابتدا به بررسي يك برنامه ساده، اما توزيع‌شده مي‌پردازيم كه شامل چندين سرويس و يك استك (Stack) از نوع LAMP است. به طور معمول، چنين سرويسي در ابتدا از طريق سرويس‌هاي وب و پايگاه‌داده Apache و MySQL روي يك سرور سخت‌افزاري پياده‌سازي مي‌شود. با رشد كسب‌وكار و افزايش ميزان مراجعه به سايت، شما از ميزبان خود درخواست مي‌کنيد تا يك سرور ديگر را به همراه يك Instance جديد از سرويس Apache در اختيار شما قرار دهد. همچنين ممكن است براي ارتقاي كارايي، ماشين مجزاي ديگري را درخواست كرده و از آن به عنوان سرور اختصاصي پايگاه‌داده استفاده كنيد. اين يک معماري ساده براي يك زيرساخت IT است كه همه نيازها و سرويس‌هاي آن از طريق يك منبع تهيه شده‌است. يعني همه سرويس‌ها در يك محيط فيزيكي منفرد پياده‌سازي شده و تمام آن‌ها توسط يك ارائه‌دهنده، پشتيباني و كنترل مي‌شوند.
در مقايسه با روش فوق در يك زيرساخت كه در آن از چندين مرجع براي پياده‌سازي سرويس‌هاي مورد نظر شما استفاده مي‌شود، ديگر شما به يك ميزبان يا ارائه‌دهنده خدمات سخت‌افزاري يا يك مركز داده محدود نمي‌شويد. در اين حالت شما مي‌توانيد به صورت كاملاً آزادانه سرويس‌هاي مختلف را از ميزبان‌هاي مختلف با يكديگر تركيب كرده، سازگار كنيد و محيطي ايجاد كنيد كه بيشترين تناسب را با كسب‌وكار شما داشته‌باشد و براي اين منظور بهترين معماري ممكن را ارائه كرده‌باشيد و در عين حال بتوانيد سرويس‌هايي مختلف از ميزبان‌هاي متعدد را آن‌طور كه نياز داريد، با هم تركيب كنيد. در اين حالت برنامه‌هاي شما هنوز مي‌توانند با هم ارتباط برقرار كنند، اما در اين حالت به جاي يك LAN فيزيكي، از يك LAN مجازي استفاده مي‌كنيد كه براي پياده‌سازي آن از ارتباطات اينترنتي سريع استفاده شده‌است. به اين ترتيب، مي‌توانيد سرويس‌هاي خود را از لحاظ موقعيت جغرافيايي نيز پراكنده كنيد و در نتيجه آن تحمل خطاي سرويس و دسترسي‌پذيري به آن نيز افزايش مي‌يابد، در حالي كه تغييرات زيادي را در برنامه خود ايجاد نكرده‌ايد. اگر سرويس‌هاي شما در يك محيط منفرد و فيزيكي و روي يك شبكه LAN كار مي‌كند، در اين صورت به احتمال بسيار زياد اين سرويس‌ها در سطح يك LAN مجازي و روي زيرساختي با منابع اطلاعاتي متعدد نيز كار خواهد كرد.
علاوه‌بر‌اين، در اين حالت مي‌توانيد از مزيت‌هاي خاص يك ميزبان خاص براي پياده‌سازي بخشي از سرويس‌هاي خود استفاده كنيد. در ادامه سراغ سيستم LAMP Stack مي‌رويم كه در ابتداي مقاله به آن اشاره شد و فرض مي‌كنيم كه مي‌خواهيم بخشي از آن را از طريق Amazon EC2 پياده‌سازي كنيم. در دورنمايي خاص از اين محيط مي‌توانيد چندين Instance را از سرور Apache تصور كنيد كه براي پاسخ‌گويي به بار كنوني اجرا شده‌اند و ممكن است ترجيح دهيد تا پايگاه‌داده MySQL روي يك سخت‌افزار واقعي قرار گيرد كه در جايي خارج از ماشين‌هاي مجازي EC2 پياده‌سازي شده‌است.
در نهايت، اين كار به شما اجازه مي‌دهد تا زيرساخت محيط IT سازمان خود را به خارج از مركز داده كنوني گسترش دهيد يا اجازه مي‌دهد تا سرويس‌هاي خارجي از برنامه‌هاي مستقر در مركز داده شما استفاده كنند. تصور كنيد، يك ميزبان محاسباتي قدرتمند از نوع كلاستر شده را براي چند ساعت اجاره‌كرده‌ايد و مي‌خواهيد محاسباتي را انجام دهيد كه به داده‌هاي سازمان شما به عنوان خوراك اطلاعاتي و ورودي داده نيازمند هستند. در اين‌صورت مشاهده خواهيد کرد كه يك زيرساخت محاسباتي با چندين منبع داده، ايده‌آل‌ترين حالت ممكن است كه مي‌تواند سناريوها و حالت‌هاي مختلف را پياده‌سازي و پشتيباني كند.
در اين مقاله، براي پياده‌سازي زيرساخت چندمنبعي روشي را تشريح مي‌كنيم كه ما آنرا با استفاده از OpenVPN در شركت CohesiveFT (به آدرس www.cohesiveft.com) پياده‌سازي كرديم و محيط عملياتي حاصل از اواسط تابستان سال 2007 مورد استفاده قرار گرفته‌است. علت انتخاب OpenVPN آن بود كه اين روش از استاندارد رمزنگاري OpenSSL پشتيباني كرده و روي سيستم‌عامل‌هاي مختلف قابل اجرا است و براي پياده‌سازي آن به بسته‌هاي اصلاحي در سطح هسته سيستم‌عامل يا ساير مدل‌هاي جانبي نياز نداريم. آخرين مزيت مورد اشاره، مهم‌ترين مورد نيز به شمار مي‌رود. در حال حاضر اغلب راهکارهاي مبتني بر سرور ميزبان از نوع VPS(سرنام Virtual Private Server)بهترين حالت ممكن براي ميزباني سرويس‌هاي شما است و قيمت آن نيز معمولاً كمتر از ساير روش‌هاي ميزباني است. اين دسته از ميزبان‌ها با استفاده از روش‌هاي مختلف مجازي‌سازي، هسته‌هاي سيستم‌عامل مهمان را كه براي محيط و سرويس مورد نظر ما سفارشي شده‌اند، تهيه و ارائه مي‌کنند. در نتيجه شما به احتمال به بازسازي هسته سيستم‌عامل براي پياده‌سازي VPS مورد نظر خود نيازي نخواهيد داشت. البته به احتمال زياد انجام اين كار نيز غيرممكن است، اما در عوض در وقت شما صرفه‌جويي مي‌شود و همچنين با اجتناب از اين گونه تغييرات، در صورت نياز، پشتيباني و خدمات فني مورد نظر شما نيز سريع‌تر فراهم مي‌شود.
در ميان مواردي كه به عنوان جايگزين براي OpenVPN مطرح هستند، مي‌توان به Openswan اشاره كرد كه كدتغييريافته پروژه‌اي به نام FreeS/WAN است، اما با توجه به مستندات موجود در صفحه ويکيOpenswanظ (wiki.openswan.org/index.php/Openswan/Install)، اين روش براي پشتيباني از مبادلات NAT به اصلاحيه براي هسته سيستم‌عامل نيازمند است. همچنين پروتكل OpenVPN با ديواره‌آتش نيز سازگار است و مي‌تواند تمام ترافيك را از طريق يك تونل UDP (كه پورت پيش‌فرض آن، 1194 است) انتقال دهد. هنگامي كه اين قابليت با رمزنگاري SSL تركيب شود، مي‌تواند ساختار نفوذناپذيري ايجاد كند، به‌طوري كه وقتي پكت‌هاي داده در بستر اينترنت مبادله مي‌شوند، نفوذ به آن‌ها تا حد بسيار زيادي دشوار است.
OpenVPN يكي از بهترين گزينه‌ها است و به جز يك مورد، همه قابليت‌هاي مورد نياز ما را فراهم مي‌كند. اين مورد نيز ضريب تحمل خطاي مناسب يا به اصطلاح fault tolerance است. وقتي شما از VPN استفاده مي‌كنيد تا در سطح سازمان به كاربران دوردست دسترسي داشته‌باشيد، راه حل بسيار آساني در برابر شما است، به اين ترتيب كه شما چندين سرور OpenVPN را پياده‌سازي مي‌كنيد و هر سرور را براي ناحيه شبكه مربوط به آن تنظيم مي‌كنيد (به‌عنوان مثال، سرور 255.255.0.0 10.5.00و سرور255.255.0.0 10.6.0.0). در يك سناريوي معمولي آدرس پوياي تعيين‌شده براي يك سرور دوردست، خيلي اهميت ندارد، زيرا شما ديواره آتش، برنامه‌ها و سرويس‌ها را طوري تنظيم مي‌كنيد كه به هر دو زيرشبكه (Subnet) دسترسي داشته‌باشيد.
سرويس Amazon EC2
ابر محاسباتي EC2 (سرنامElastic Compute Cloud يا ابر محاسباتي انعطاف‌پذير) يك سرويس تحت وب است كه به كاربران امكان مي‌دهد تا در زيرساخت مجازي به ميزباني آمازون به دورنمايي انعطاف‌پذير و قابل ارتقا دسترسي داشته‌باشد و بتواند در صورت لزوم ماشين‌هاي جديد را به مجموعه سرورهاي خود افزايش دهد. اين كار به سادگي و با استفاده از تعداد API كه در اختيار شما قرار مي‌گيرد، انجام مي‌شود. كاربران مي‌توانند به اين ماشين‌ها دسترسي كامل در سطح كاربر Root داشته‌باشند و تقريباً هر نوع سيستم‌عامل يا برنامه‌اي را در ماشين‌هاي مجازي خود در محيط آمازون نصب كنند.
APIهاي راه‌اندازي شده از طريق سرويس‌هاي تحت وب، به كاربران امكان راه‌اندازي دوباره ماشين‌ها را از دوردست مي‌دهد و مي‌توانند در صورت لزوم امكانات سيستم‌هاي خود را با استفاده از ده‌ها يا حتي صدها ماشين ارتقا دهند. به علاوه در اين روش، هزينه سخت‌افزار يك پيش‌نياز براي ارتقا به حساب نمي‌آيد و آمازون تنها هزينه مربوط به ظرفيت اضافي درخواستي را دريافت مي‌كند. با ورود ماشين‌هاي جديد به محيط محاسبات مجازي آمازون، مديران سيستم به دنبال روش‌هايي هستند تا از طريق اينترنت بين ماشين‌هاي مجازي جديد كه در محيط Amazon EC2 قرار دارند و ماشين‌هاي كنوني كه در مراكز داده قرار دارند، ارتباطات امني را فراهم كنند. اين مقاله تكنيكي را بررسي مي‌كند كه مي‌توان با استفاده از آن يك زيرساخت ساختار چندمنبعي را با استفاده از OpenVPN ايجاد كرد.
اگرچه اين راهكار، زماني كه شما يك زيرساخت چندمنبعي ايجاد مي‌كنيد، روش مناسبي نيست، مگر آن‌كه بخواهيد آدرس IP سرورها را در بازه‌هاي زماني مشخص تغيير دهيد. براي برآورده كردن نياز به افزونگي و تحمل خطا ما به يك جفت سرور OpenVPN در وضعيت فعال نياز داريم تا يك آدرس و فضاي مشترك را به اشتراك بگذاريم، به طوري كه همه ميزبان‌ها بتوانند در هر زمان با استفاده از آدرس IP استاتيك به يكديگر دسترسي داشته‌باشند و اهميتي نداشته‌باشد كه كدام سرور OpenVPN در هر يك از دو طرف مسير، ارتباط بين دو سرور را برقرار مي‌كند. سپس اگر ما يكي از سرورهاي OpenVPN را از دست دهيم، سرور ديگر ارتباط را برقرار مي‌كند و اگر هر دو فعال باشند، در اين صورت هر دو سرور، درخواست ارتباط از جانب كلاينت‌ها را مي‌پذيرند تا بار كاري بين آن‌ها، به اشتراك گذاشته‌شود. اين قابليت در نسخه اصلي OpenVPN وجود نداشت، در نتيجه ما يك ديمن (daemon) يا سرويس‌پس‌زمينه و مستقل را طراحي كرديم تا توزيع بار كاري در حالت فعال-فعال (Active-Active) را تسهيل كند. مي‌توانيد كد مورد نياز را براي اين برنامه به همراه ساير پيوندهاي مفيد و سناريوهاي موردي و فهرستي از ايميل‌ها از آدرسcohesiveft.com/multisourced-infra ا.wwwپيدا كنيد.
ايجاد يك LAN مجازي
شما به دو ماشين نياز داريد كه ديمن OpenVPN، در وضعيت Server ، روي آن‌ها اجرا شود (ما اين دو ماشين را با نام سرورهاي vpnsrvA و vpnsrvB در نظر مي‌گيريم و فرض مي‌كنيم كه آدرس IP فيزيكي آن‌ها در شبكه شما، به ترتيب 192.168.7.1 و 192.168.17.1 است). در كنار آن‌ها دو زيرشبكه اختصاصي را يكي براي داده (با آدرس فرضي 10.10.100.0/24) و ديگري براي مديريت (10.200.200.0/24) در نظر مي‌گيريم. همه برنامه‌ها و سرويس‌هاي شما در زيرشبكه داده اجرا خواهند شد و vpnsrvA و vpnsrB وضعيت زمان اجرا و اطلاعات مسيريابي را در زير شبكه مديريتي مبادله خواهند كرد. اين دو ماشين را به‌عنوان دو سوييچ مجازي شبكه براي شبكه LAN خود در نظر بگيريد. همچنين توجه داشته‌باشيد كه اين دو حتماً لازم نيست كه در كلاس C باشند. شما مي‌توانيد، شبكه داده بزرگ‌تر را در نظر بگيريد، به ويژه اگر بنا داريد تا تعداد زيادي از ميزبان‌ها را به يكديگر متصل كنيد.
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn_s.jpg
شكل 1 - زيرساخت چندمنبعي با استفاده از ارتباطات مبني بر OpenVPN
دو سرور vpnsrvA و vpnsrvB را مطابق كد فهرست 1-الف و 1-ب تنظيم كنيد. در صورت لزوم مي‌توانيد از ساير گزينه‌ها نيز براي تنظيمات اختياري استفاده كنيد. توجه داشته‌باشيد كه ستون با نام Server در فايل تنظيمات يك ميان‌بر است و نمي‌توان از آن براي هر دو سرور vpnsrvA و vpnsrvB استفاده كرد. اين ميان‌بر در اصل به مجموعه‌اي از دستورات تبديل مي‌شود كه آدرس 10.100.100.1 را به هر دو سرور منتسب مي‌كنند (براي جزئيات بيشتر به صفحه توضيحات قابل دسترس از طريق دستور خط‌فرمان man براي OpenVPN مراجعه كنيد). ما به تنظيمات در حالت فعال-فعال نياز داريم، در نتيجه vpnsrvA و vpnsrvB در يك زيرشبكه قرار مي‌گيرند، اما آدرس IP آن‌ها متفاوت است. براي برآورده كردن اين منظور، ما با استفاده از دستوراتي وضعيت vpnsrvB را كامل‌تر كرده و آدرس IP با مقدار 10.100.00.101 را به آن منتسب مي‌كنيم.
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn2_s.jpg
فهرست 1-الف - تنظيمات سرور OpenVPN به ازاي سرور vpnsrvA
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn3_s.jpg
فهرست1-ب - تنظيمات سرور OpenVPN به ازاي سرور vpnsrvB
نكته مهم ديگر، اين است كه دايركتوري تنظيمات كلاينت (معمولاً با نام ccd شناخته مي شود) و دايركتوري كليدها (با نام keys يا كليدها شناخته مي‌شود) بايد در هر دو سرور vpnsrvA و vpnsrvB در وضعيتي معادل قرار گيرند. يكي از آسان‌ترين كارها براي رسيدن به اين هدف استفاده از Rsync است. Rsync به شما اجازه مي‌دهد تا كارها را به سادگي و بدون نياز به درگير شدن با ساير مؤلفه‌ها انجام دهيم. همچنين ما هميشه مي‌توانيم جهت Rsync را تغيير دهيم و به اين ترتيب، هر يك از سرورها را كه درنظر داريم، به سرور اصلي يا Master تغيير دهيم. فعلاً، اجازه دهيد فرض كنيم كه vpnsrvA سرور اصلي است و vpnsrvB با استفاده از Rsync و در قالب سرور پشتيبان، از اطلاعات كليدي و ccd موجود در سرور vpnsrvA، يك نسخه mirror نگهداري مي‌كند. شما كليدها را (ترجيحاً با استفاده از بسته easy-rsa كه به همراه OpenVPN ارائه مي‌شود) ايجاد كرده و مدخل‌هاي ccd را در سرور اصلي به‌روزرساني مي‌كنيد. حال مي‌توانيد چندين ميزبان را در سطح شبكه تنظيم کرده و به‌عنوان كلاينت‌هاي سرويس OpenVPN تعريف كنيد(كدفهرست 2).
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn4_s.jpg
فهرست 2- تنظيمات كلاينت براي سرويس OpenVPN
هر ميزبان جفت كليد اعتبارسنجي مختص به خود را دارد و راهنماي ifconfig-push در مدخل ccd براي اين ميزبان، آدرس‌هاي IP آنرا تنظيم خواهد كرد. ما آدرس IP مجازي را بر مبناي جفت كليد اعتبارسنجي آن به يك ميزبان مرتبط مي‌كنيم و اين كار به روشي كه براي تنظيمات DHCP به كار مي‌رود، بسيار شبيه است. يعني نگاشت آدرس IP به ميزبان بر مبناي آدرسEthenet MAC (آدرس يكتاي MAC مربوط به كارت شبكه) انجام مي‌شود. بنابراين، هر كلاينت بايد جفت كليد اعتبارسنجي مختص به خود را داشته‌باشد. توجه داشته‌باشيد كه ما از قابليت ذاتي OpenVPN در بررسي متوالي (round-robin) بين چند سرور به منظور ارتباط دوباره بعد از قطع تماس نيز استفاده مي‌كنيم. اين قابليت از طريق ويژگي و گزينه‌اي به نام keep-alive كنترل مي‌شود. بعد از انجام اين كار بايد بتوانيد كلاينت‌هاي OpenVPN را فعال كنيد آن‌ها نيز بايد بتوانند دست‌کم با سرور OpenVPN مربوط به خود ارتباط برقرار كنند و از طريق IP شماره 10.100.100.1 يا 10.100.100.101 به آن مراجعه كنند. اگر كلاينت شما به vpnsrvA متصل مي‌شود و شما ديمن يا سرويس روي vpnsrvA را غيرفعال كنيد، در اين صورت كلاينت مي‌تواند اين تغيير را تشخيص داده و به صورت خودكار دوباره به vpnsrvB متصل شود.
يك نكته كوتاه درباره ديواره‌هاي آتش در شبكه مجازي اين است که رابط اصلي شما در شبكه داده، با نام tun0 شناخته مي‌شود. بنابراين، تمام قوانيني را كه شما در تنظيمات تك‌منبعي، براي رابط eth0 تعريف مي‌كرديد، دوباره براي tun0 تعريف كنيد. رابط Ethernet جهت ارائه مجوز به ماشين كلاينت براي ارتباط UDP به پورت 1194 (OpenVPN) از هر دو سرور vpnsrvA و vpnsrvB به اختيارات بيشتري نياز خواهد داشت.
تنظيماتي كه ما قبلاً ايجاد كرده‌ايم، به نوعي براي تحمل خطا به كار مي‌رود. اگر vpnsrvA از دسترس خارج شود، تمام كلاينت‌ها به vpnsrvB متصل خواهند شد و مبادلات از سر گرفته مي‌شود. به عبارت ديگر، اين افزونگي از نوع active-passive است. اما در صورتي كه دو سرور vpnsrvA و vpnsrvB فعال باشند، چه اتفاقي خواهد افتاد. اجازه دهيد فرض كنيم، ميزبان 1 و 2 ديمن يا سرويس Openvpn را در حالت كلاينت اجرا كرده‌اند. host1 به vpnsrvA متصل شد و آدرس IP شماره 10.100.100.25 به آن اختصاص داده‌شد و host2 به vpnsrvB متصل و آدرس IP شماره 10.100.100.41 به آن اختصاص داده‌شد. جدول مسيريابي در vpnsrvA مطابق كد فهرست3 خواهد بود. در اين سناريو زماني كه host1 سعي مي‌كند تا دسترسي به آدرس 10.100.100.101 را از طريق دستور ping كنترل كند، پكت‌هاي ارسالي ابتدا به vpnsrvA مسيردهي مي‌شوند، اما دوباره به همان كارت شبكه tun0 مسيردهي مي‌شوند، زيرا vpnsrvA در مورد وجود vpnsrvB چيزي نمي‌داند. زماني كه host1 سعي مي‌كند با دستور ping به host2 متصل شود، vpnsrvA نيز مطابق آنچه در مسيردهي 10.100.100.0/24 گفته‌شده، اين پكت‌ها را پس مي‌فرستد و در نتيجه هر دو عمليات با خطا برخورد كرده و متوقف مي‌شوند.
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn6_s.jpg
فهرست3 - بخشي از جدول routing در vpnsrvA
ما براي برطرف كردن اين نقيصه، يك ديمن يا سرويس مسيردهي پويا با نام Cube-routed ايجاد كرديم (قابل دريافت از آدرس www.cohesiveft.com/multisourced-infra). اين ديمن اطلاعات مسيردهي را بين vpnsrvA و vpnsrvB به اشتراك مي‌گذارد و جدول‌هاي مسيردهي را با كلاينت‌ها با توجه به آن‌ها به يكي از اين دو سرور متصل مي‌شوند، تقريباً به طور لحظه‌اي به‌روزرساني مي‌كنند. ساختار داخلي آن خيلي پيچيده نيست. يك رشته، از طريق رابط مديريت خود، به ديمن ارائه دهنده سرويس محلي OpenVPN متصل مي‌شود (به گزينه‌هاي مديريت در فايل تنظيمات OpenVPN مراجعه كنيد) و به طور منظم دستور Status را براي به‌روزرساني فهرست كلاينت‌هاي متصل به سرور محلي اجرا مي‌كند. رشته ديگري به طور همزمان با فرآيند فوق، اين اطلاعات را براي يک Instance از Cuberotued كه روي سرور دوردست قرار دارد، ارسال مي‌كند. به‌طور همزمان رشته سوم نيز به‌صورت منظم، فهرستي از كلاينت‌هاي متصل به نمونه دوردست از Cube-routed را تهيه مي‌كند. در نهايت، رشته چهارم جدول مسيردهي محلي را بر مبناي دو قانون زير به روزرساني مي‌كند:
1- يك Route ميزبان را به ازاي هر يك از ميزبان‌هاي متصل به سرور OpenVPN دوردست اضافه مي‌كند.
2- به ازاي هر يك از ميزبان‌هاي متصل به سرور OpenVPN محلي، آدرس Route ميزبان را پاك مي‌كند.
نمونه‌هاي Rube-route نيز اطلاعات مديريتي را از طريق زيرشبكه مديريتي كه قبلاً انتخاب كرديم، مبادله مي‌كنند. تونل دوم با نام tun1 را بين vpnsrvA و vpnsrvB ايجاد كنيد. vpnsrvA يك سرور با آدرس IP به شماره 10.200.200.1 و vpnsrvB نيز كلاينت آن با آدرس IP به شماره 10.200.200.1 است. شما مي‌توانيد فايل‌هاي تنظيمات را بر مبناي اطلاعات كدفهرست 1 و 2 به‌عنوان نمونه ايجاد كنيد، اما حتماً آدرس IPها را تغيير دهيد و از پورت ديگري استفاده كنيد. به‌عنوان مثال، مي‌توانيد پورت 11940را به سرور و كلاينت اضافه كنيد. هر دو ديمن مربوط به OpenVPN را فعال كنيد و با ping زدن به IPهاي 10.200.200.1 و 10.200.200.5 وجود ارتباط بين آن‌ها را كنترل كنيد.
در هر دو vpnsrvA و vpnsrvB مطابق كدفهرست 4-الف و4-ب يك فايل تنظيمات براي سرويس cube-routed ايجاد كنيد و هر دو Instance را به عنوان كاربر Root با معرفي فايل تنظيمات به عنوان تنها پارامتر آغاز كنيد (توجه كنيد كه OpenVPN بايد از قبل در حال اجرا باشد و رابط‌هاي tun0 و tun1 روي هر دو سرور vpnsrvA و vpnsrvB فعال باشد).
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn7_s.jpg
فهرست 4-الف - بخشي از جدول routing در vpnsrvA
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn8_s.jpg
قهرست4-ب - فايل تنظيمات سرويس cobe-routed براي vpnsrvB
بعد از فعال‌كردن همه سرويس‌ها و بعد از چند دقيقه از زمان آغاز، در مثال فوق، host1 مي‌تواند با host2 ارتباط برقرار كند، هرچند آن‌ها به سرورهاي OpenVPN متفاوتي متصل مي‌شوند. بنابراين، شما توانسته‌ايد يك آدرس مجازي LAN با قابليت تحمل‌خطا ايجاد كنيد كه در عين حال از مزيت رمزنگاري داده مبادله‌شدن نيز بهره مي‌برد.
نتيجه‌گيري
اين پياده‌سازي نيز محدوديت‌هايي دارد. نخست برنامه‌هايي كه با روش broadcast يا multicast کار مي‌كنند، نمي‌توانند از ابزارهاي tun ارائه شده در استاندارد OpenVPN استفاده كنند. شما مي‌توانيد از همان چيدمان شبكه استفاده كنيد كه در اينجا به آن اشاره شده، اما در استاندارد OpenVPN ابزارهاي tun را با ابزارهاي نوع tap جايگزين كنيد. دوم تأخير ارتباطات شبكه‌اي در اينترنت، به مراتب بيشتر از شبكه‌هاي Ethernet است. اگر اين نقيصه، براي برنامه‌هاي شما مشكل‌ساز است، به‌احتمال شما بايد در اين قسمت از زيرساخت از همان روش‌هاي تك‌منبع قديمي استفاده كنيد. سوم، از آنجا كه ما از تونل‌هاي مبتني بر UDP استفاده مي‌كنيم، در نتيجه رابط‌هاي OpenVPN بيشتر از شبكه‌هاي Ethernet قطع و وصل مي‌شوند، به ويژه اين مشكل در زمان اشباع ترافيك شبكه بيشتر مشاهده مي‌شود. شما مي‌توانيد مكانيزم‌هاي ذخيره‌سازي داده را براي اجتناب از ارتباط‌هاي طولاني مدت TCP پياده‌سازي كنيد يا روي منطق مديريت استثنا در شبكه تمركز كنيد و به‌منظور كاهش تأثيرهاي منفي روش UDP از تونل‌هاي TCP استفاده كنيد. درنهايت شما در اين تنظيمات دو سرور OpenVPN ايجاد مي‌كنيد. دو سرور OpenVPN در بيشتر موارد كافي است و در تعداد ميزبان‌هاي واقعي كه به زيرساخت اطلاعاتي چندمنبعي متصل هستند، تأثيري ندارد. اگر به هر دليلي شما به بيش از دو سرور OpenVPN نياز داشته‌باشيد، در اين صورت پياده‌سازي به‌اشتراك‌گذاري Route بين Instanceهاي سرويس Cube-Routed مشكل‌تر مي‌شود. در چنين حالتي ممكن است بخواهيد به جاي روش سوكت‌هاي خام، از يك سيستم پيام‌رساني استفاده كنيد (به‌عنوان مثال از RabbitMQ). به طور كلي در موردي كه ما آنرا پياده سازي كرديم به خوبي مشهود بود كه مزاياي يك زيرساختار چند منبعي در برابر نواقص و محدوديت‌هاي آن ناچيز است، به ويژه آن‌كه اگر شما در معماري چندمنبعي خود اين محدوديت‌ها را نيز در نظر بگيريد.
زيرساخت چندمنبعي، نمونه توسعه يافته، روش تك‌منبعي در نسل قبل است و همانند معماري سرويس‌گرا بعد از برنامه‌هاي تك‌منظور ارائه شد و توانست انعطاف‌پذيري، سرعت بالا در پياده‌سازي سيستم‌ها و دسترسي‌پذيري بيشتري را فراهم كند. اين روش مي‌تواند به شما كمك كند تا با استفاده از يك روش اپن‌سورس و آزمايش‌شده به نام OpenVPN بتوانيد معماري هوشمندتري را به‌منظور اجتناب از محدود شدن به يك ميزبان در اختيار داشته‌باشيد.
ايجاد زيرساخت يك محيط اطلاعاتي با قابليت دسترسي به منابع داده مختلف از طريق فناوري
http://www.shabakeh-mag.com/Data/Articles/Items/2011/4/1004640.jpg آيا تا به حال پيش‌آمده‌است که بخواهيد مجموعه‌اي از سرورهاي مرتبط به هم را در محيط‌هاي مجزا از هم و مربوط به سرويس‌دهندگان مختلف قرار دهيد تا برنامه‌هاي مرتبط به هم در اين سرورها، از طريق مسيرهاي ارتباطي نظير LAN با هم ارتباط برقرار كنند؟
آيا تا به حال پيش‌آمده‌است که بخواهيد مجموعه‌اي از سرورهاي مرتبط به هم را در محيط‌هاي مجزا از هم و مربوط به سرويس‌دهندگان مختلف قرار دهيد تا برنامه‌هاي مرتبط به هم در اين سرورها، از طريق مسيرهاي ارتباطي نظير LAN با هم ارتباط برقرار كنند؟ به ياد داشته‌باشيد كه معمولاً در اين شرايط براي ارتباط ميان سرورها، موانع امنيتي و كنترلي متعددي شامل لايه‌هاي مختلفي از ديواره آتش و NAT وجود خواهد داشت. شايد هم به دلايل مالي يا به منظور بهبود كيفيت خدمات، مي‌خواهيد ميزبان جديدي را براي سرويس‌هاي خود انتخاب كنيد، اما ترجيح مي‌دهيد فرآيند مهاجرت به محيط جديد را به صورت تدريجي و نه لحظه‌اي انجام دهيد تا از مشكلات ناشي از پايين‌بودن سرويس‌ها براي مدت طولاني هنگام انتقال ناگهاني جلوگيري كنيد. در سناريوي ديگري ممكن است بخواهيد بخشي از زيرساخت سخت‌افزاري مورد نياز را براي پياده‌سازي سرويس‌هاي خود، و نه همه آن‌ها، از طريق ابر محاسباتي Amazon EC2 فراهم كنيد. اگر به هر يك از پرسش‌هاي فوق جواب مثبت بدهيد، در اين صورت شما به شدت به يك زيرساخت IT نياز داريد تا بتواند امكان ارتباط بدون دردسر را بين چندين منبع اطلاعات و سرويس فراهم كند.
ابتدا به بررسي يك برنامه ساده، اما توزيع‌شده مي‌پردازيم كه شامل چندين سرويس و يك استك (Stack) از نوع LAMP است. به طور معمول، چنين سرويسي در ابتدا از طريق سرويس‌هاي وب و پايگاه‌داده Apache و MySQL روي يك سرور سخت‌افزاري پياده‌سازي مي‌شود. با رشد كسب‌وكار و افزايش ميزان مراجعه به سايت، شما از ميزبان خود درخواست مي‌کنيد تا يك سرور ديگر را به همراه يك Instance جديد از سرويس Apache در اختيار شما قرار دهد. همچنين ممكن است براي ارتقاي كارايي، ماشين مجزاي ديگري را درخواست كرده و از آن به عنوان سرور اختصاصي پايگاه‌داده استفاده كنيد. اين يک معماري ساده براي يك زيرساخت IT است كه همه نيازها و سرويس‌هاي آن از طريق يك منبع تهيه شده‌است. يعني همه سرويس‌ها در يك محيط فيزيكي منفرد پياده‌سازي شده و تمام آن‌ها توسط يك ارائه‌دهنده، پشتيباني و كنترل مي‌شوند.
در مقايسه با روش فوق در يك زيرساخت كه در آن از چندين مرجع براي پياده‌سازي سرويس‌هاي مورد نظر شما استفاده مي‌شود، ديگر شما به يك ميزبان يا ارائه‌دهنده خدمات سخت‌افزاري يا يك مركز داده محدود نمي‌شويد. در اين حالت شما مي‌توانيد به صورت كاملاً آزادانه سرويس‌هاي مختلف را از ميزبان‌هاي مختلف با يكديگر تركيب كرده، سازگار كنيد و محيطي ايجاد كنيد كه بيشترين تناسب را با كسب‌وكار شما داشته‌باشد و براي اين منظور بهترين معماري ممكن را ارائه كرده‌باشيد و در عين حال بتوانيد سرويس‌هايي مختلف از ميزبان‌هاي متعدد را آن‌طور كه نياز داريد، با هم تركيب كنيد. در اين حالت برنامه‌هاي شما هنوز مي‌توانند با هم ارتباط برقرار كنند، اما در اين حالت به جاي يك LAN فيزيكي، از يك LAN مجازي استفاده مي‌كنيد كه براي پياده‌سازي آن از ارتباطات اينترنتي سريع استفاده شده‌است. به اين ترتيب، مي‌توانيد سرويس‌هاي خود را از لحاظ موقعيت جغرافيايي نيز پراكنده كنيد و در نتيجه آن تحمل خطاي سرويس و دسترسي‌پذيري به آن نيز افزايش مي‌يابد، در حالي كه تغييرات زيادي را در برنامه خود ايجاد نكرده‌ايد. اگر سرويس‌هاي شما در يك محيط منفرد و فيزيكي و روي يك شبكه LAN كار مي‌كند، در اين صورت به احتمال بسيار زياد اين سرويس‌ها در سطح يك LAN مجازي و روي زيرساختي با منابع اطلاعاتي متعدد نيز كار خواهد كرد.
علاوه‌بر‌اين، در اين حالت مي‌توانيد از مزيت‌هاي خاص يك ميزبان خاص براي پياده‌سازي بخشي از سرويس‌هاي خود استفاده كنيد. در ادامه سراغ سيستم LAMP Stack مي‌رويم كه در ابتداي مقاله به آن اشاره شد و فرض مي‌كنيم كه مي‌خواهيم بخشي از آن را از طريق Amazon EC2 پياده‌سازي كنيم. در دورنمايي خاص از اين محيط مي‌توانيد چندين Instance را از سرور Apache تصور كنيد كه براي پاسخ‌گويي به بار كنوني اجرا شده‌اند و ممكن است ترجيح دهيد تا پايگاه‌داده MySQL روي يك سخت‌افزار واقعي قرار گيرد كه در جايي خارج از ماشين‌هاي مجازي EC2 پياده‌سازي شده‌است.
در نهايت، اين كار به شما اجازه مي‌دهد تا زيرساخت محيط IT سازمان خود را به خارج از مركز داده كنوني گسترش دهيد يا اجازه مي‌دهد تا سرويس‌هاي خارجي از برنامه‌هاي مستقر در مركز داده شما استفاده كنند. تصور كنيد، يك ميزبان محاسباتي قدرتمند از نوع كلاستر شده را براي چند ساعت اجاره‌كرده‌ايد و مي‌خواهيد محاسباتي را انجام دهيد كه به داده‌هاي سازمان شما به عنوان خوراك اطلاعاتي و ورودي داده نيازمند هستند. در اين‌صورت مشاهده خواهيد کرد كه يك زيرساخت محاسباتي با چندين منبع داده، ايده‌آل‌ترين حالت ممكن است كه مي‌تواند سناريوها و حالت‌هاي مختلف را پياده‌سازي و پشتيباني كند.
در اين مقاله، براي پياده‌سازي زيرساخت چندمنبعي روشي را تشريح مي‌كنيم كه ما آنرا با استفاده از OpenVPN در شركت CohesiveFT (به آدرس www.cohesiveft.com) پياده‌سازي كرديم و محيط عملياتي حاصل از اواسط تابستان سال 2007 مورد استفاده قرار گرفته‌است. علت انتخاب OpenVPN آن بود كه اين روش از استاندارد رمزنگاري OpenSSL پشتيباني كرده و روي سيستم‌عامل‌هاي مختلف قابل اجرا است و براي پياده‌سازي آن به بسته‌هاي اصلاحي در سطح هسته سيستم‌عامل يا ساير مدل‌هاي جانبي نياز نداريم. آخرين مزيت مورد اشاره، مهم‌ترين مورد نيز به شمار مي‌رود. در حال حاضر اغلب راهکارهاي مبتني بر سرور ميزبان از نوع VPS(سرنام Virtual Private Server)بهترين حالت ممكن براي ميزباني سرويس‌هاي شما است و قيمت آن نيز معمولاً كمتر از ساير روش‌هاي ميزباني است. اين دسته از ميزبان‌ها با استفاده از روش‌هاي مختلف مجازي‌سازي، هسته‌هاي سيستم‌عامل مهمان را كه براي محيط و سرويس مورد نظر ما سفارشي شده‌اند، تهيه و ارائه مي‌کنند. در نتيجه شما به احتمال به بازسازي هسته سيستم‌عامل براي پياده‌سازي VPS مورد نظر خود نيازي نخواهيد داشت. البته به احتمال زياد انجام اين كار نيز غيرممكن است، اما در عوض در وقت شما صرفه‌جويي مي‌شود و همچنين با اجتناب از اين گونه تغييرات، در صورت نياز، پشتيباني و خدمات فني مورد نظر شما نيز سريع‌تر فراهم مي‌شود.
در ميان مواردي كه به عنوان جايگزين براي OpenVPN مطرح هستند، مي‌توان به Openswan اشاره كرد كه كدتغييريافته پروژه‌اي به نام FreeS/WAN است، اما با توجه به مستندات موجود در صفحه ويکيOpenswanظ (wiki.openswan.org/index.php/Openswan/Install)، اين روش براي پشتيباني از مبادلات NAT به اصلاحيه براي هسته سيستم‌عامل نيازمند است. همچنين پروتكل OpenVPN با ديواره‌آتش نيز سازگار است و مي‌تواند تمام ترافيك را از طريق يك تونل UDP (كه پورت پيش‌فرض آن، 1194 است) انتقال دهد. هنگامي كه اين قابليت با رمزنگاري SSL تركيب شود، مي‌تواند ساختار نفوذناپذيري ايجاد كند، به‌طوري كه وقتي پكت‌هاي داده در بستر اينترنت مبادله مي‌شوند، نفوذ به آن‌ها تا حد بسيار زيادي دشوار است.
OpenVPN يكي از بهترين گزينه‌ها است و به جز يك مورد، همه قابليت‌هاي مورد نياز ما را فراهم مي‌كند. اين مورد نيز ضريب تحمل خطاي مناسب يا به اصطلاح fault tolerance است. وقتي شما از VPN استفاده مي‌كنيد تا در سطح سازمان به كاربران دوردست دسترسي داشته‌باشيد، راه حل بسيار آساني در برابر شما است، به اين ترتيب كه شما چندين سرور OpenVPN را پياده‌سازي مي‌كنيد و هر سرور را براي ناحيه شبكه مربوط به آن تنظيم مي‌كنيد (به‌عنوان مثال، سرور 255.255.0.0 10.5.00و سرور255.255.0.0 10.6.0.0). در يك سناريوي معمولي آدرس پوياي تعيين‌شده براي يك سرور دوردست، خيلي اهميت ندارد، زيرا شما ديواره آتش، برنامه‌ها و سرويس‌ها را طوري تنظيم مي‌كنيد كه به هر دو زيرشبكه (Subnet) دسترسي داشته‌باشيد.
سرويس Amazon EC2
ابر محاسباتي EC2 (سرنامElastic Compute Cloud يا ابر محاسباتي انعطاف‌پذير) يك سرويس تحت وب است كه به كاربران امكان مي‌دهد تا در زيرساخت مجازي به ميزباني آمازون به دورنمايي انعطاف‌پذير و قابل ارتقا دسترسي داشته‌باشد و بتواند در صورت لزوم ماشين‌هاي جديد را به مجموعه سرورهاي خود افزايش دهد. اين كار به سادگي و با استفاده از تعداد API كه در اختيار شما قرار مي‌گيرد، انجام مي‌شود. كاربران مي‌توانند به اين ماشين‌ها دسترسي كامل در سطح كاربر Root داشته‌باشند و تقريباً هر نوع سيستم‌عامل يا برنامه‌اي را در ماشين‌هاي مجازي خود در محيط آمازون نصب كنند.
APIهاي راه‌اندازي شده از طريق سرويس‌هاي تحت وب، به كاربران امكان راه‌اندازي دوباره ماشين‌ها را از دوردست مي‌دهد و مي‌توانند در صورت لزوم امكانات سيستم‌هاي خود را با استفاده از ده‌ها يا حتي صدها ماشين ارتقا دهند. به علاوه در اين روش، هزينه سخت‌افزار يك پيش‌نياز براي ارتقا به حساب نمي‌آيد و آمازون تنها هزينه مربوط به ظرفيت اضافي درخواستي را دريافت مي‌كند. با ورود ماشين‌هاي جديد به محيط محاسبات مجازي آمازون، مديران سيستم به دنبال روش‌هايي هستند تا از طريق اينترنت بين ماشين‌هاي مجازي جديد كه در محيط Amazon EC2 قرار دارند و ماشين‌هاي كنوني كه در مراكز داده قرار دارند، ارتباطات امني را فراهم كنند. اين مقاله تكنيكي را بررسي مي‌كند كه مي‌توان با استفاده از آن يك زيرساخت ساختار چندمنبعي را با استفاده از OpenVPN ايجاد كرد.
اگرچه اين راهكار، زماني كه شما يك زيرساخت چندمنبعي ايجاد مي‌كنيد، روش مناسبي نيست، مگر آن‌كه بخواهيد آدرس IP سرورها را در بازه‌هاي زماني مشخص تغيير دهيد. براي برآورده كردن نياز به افزونگي و تحمل خطا ما به يك جفت سرور OpenVPN در وضعيت فعال نياز داريم تا يك آدرس و فضاي مشترك را به اشتراك بگذاريم، به طوري كه همه ميزبان‌ها بتوانند در هر زمان با استفاده از آدرس IP استاتيك به يكديگر دسترسي داشته‌باشند و اهميتي نداشته‌باشد كه كدام سرور OpenVPN در هر يك از دو طرف مسير، ارتباط بين دو سرور را برقرار مي‌كند. سپس اگر ما يكي از سرورهاي OpenVPN را از دست دهيم، سرور ديگر ارتباط را برقرار مي‌كند و اگر هر دو فعال باشند، در اين صورت هر دو سرور، درخواست ارتباط از جانب كلاينت‌ها را مي‌پذيرند تا بار كاري بين آن‌ها، به اشتراك گذاشته‌شود. اين قابليت در نسخه اصلي OpenVPN وجود نداشت، در نتيجه ما يك ديمن (daemon) يا سرويس‌پس‌زمينه و مستقل را طراحي كرديم تا توزيع بار كاري در حالت فعال-فعال (Active-Active) را تسهيل كند. مي‌توانيد كد مورد نياز را براي اين برنامه به همراه ساير پيوندهاي مفيد و سناريوهاي موردي و فهرستي از ايميل‌ها از آدرسcohesiveft.com/multisourced-infra ا.wwwپيدا كنيد.
ايجاد يك LAN مجازي
شما به دو ماشين نياز داريد كه ديمن OpenVPN، در وضعيت Server ، روي آن‌ها اجرا شود (ما اين دو ماشين را با نام سرورهاي vpnsrvA و vpnsrvB در نظر مي‌گيريم و فرض مي‌كنيم كه آدرس IP فيزيكي آن‌ها در شبكه شما، به ترتيب 192.168.7.1 و 192.168.17.1 است). در كنار آن‌ها دو زيرشبكه اختصاصي را يكي براي داده (با آدرس فرضي 10.10.100.0/24) و ديگري براي مديريت (10.200.200.0/24) در نظر مي‌گيريم. همه برنامه‌ها و سرويس‌هاي شما در زيرشبكه داده اجرا خواهند شد و vpnsrvA و vpnsrB وضعيت زمان اجرا و اطلاعات مسيريابي را در زير شبكه مديريتي مبادله خواهند كرد. اين دو ماشين را به‌عنوان دو سوييچ مجازي شبكه براي شبكه LAN خود در نظر بگيريد. همچنين توجه داشته‌باشيد كه اين دو حتماً لازم نيست كه در كلاس C باشند. شما مي‌توانيد، شبكه داده بزرگ‌تر را در نظر بگيريد، به ويژه اگر بنا داريد تا تعداد زيادي از ميزبان‌ها را به يكديگر متصل كنيد.
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn_s.jpg
شكل 1 - زيرساخت چندمنبعي با استفاده از ارتباطات مبني بر OpenVPN
دو سرور vpnsrvA و vpnsrvB را مطابق كد فهرست 1-الف و 1-ب تنظيم كنيد. در صورت لزوم مي‌توانيد از ساير گزينه‌ها نيز براي تنظيمات اختياري استفاده كنيد. توجه داشته‌باشيد كه ستون با نام Server در فايل تنظيمات يك ميان‌بر است و نمي‌توان از آن براي هر دو سرور vpnsrvA و vpnsrvB استفاده كرد. اين ميان‌بر در اصل به مجموعه‌اي از دستورات تبديل مي‌شود كه آدرس 10.100.100.1 را به هر دو سرور منتسب مي‌كنند (براي جزئيات بيشتر به صفحه توضيحات قابل دسترس از طريق دستور خط‌فرمان man براي OpenVPN مراجعه كنيد). ما به تنظيمات در حالت فعال-فعال نياز داريم، در نتيجه vpnsrvA و vpnsrvB در يك زيرشبكه قرار مي‌گيرند، اما آدرس IP آن‌ها متفاوت است. براي برآورده كردن اين منظور، ما با استفاده از دستوراتي وضعيت vpnsrvB را كامل‌تر كرده و آدرس IP با مقدار 10.100.00.101 را به آن منتسب مي‌كنيم.
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn2_s.jpg
فهرست 1-الف - تنظيمات سرور OpenVPN به ازاي سرور vpnsrvA
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn3_s.jpg
فهرست1-ب - تنظيمات سرور OpenVPN به ازاي سرور vpnsrvB
نكته مهم ديگر، اين است كه دايركتوري تنظيمات كلاينت (معمولاً با نام ccd شناخته مي شود) و دايركتوري كليدها (با نام keys يا كليدها شناخته مي‌شود) بايد در هر دو سرور vpnsrvA و vpnsrvB در وضعيتي معادل قرار گيرند. يكي از آسان‌ترين كارها براي رسيدن به اين هدف استفاده از Rsync است. Rsync به شما اجازه مي‌دهد تا كارها را به سادگي و بدون نياز به درگير شدن با ساير مؤلفه‌ها انجام دهيم. همچنين ما هميشه مي‌توانيم جهت Rsync را تغيير دهيم و به اين ترتيب، هر يك از سرورها را كه درنظر داريم، به سرور اصلي يا Master تغيير دهيم. فعلاً، اجازه دهيد فرض كنيم كه vpnsrvA سرور اصلي است و vpnsrvB با استفاده از Rsync و در قالب سرور پشتيبان، از اطلاعات كليدي و ccd موجود در سرور vpnsrvA، يك نسخه mirror نگهداري مي‌كند. شما كليدها را (ترجيحاً با استفاده از بسته easy-rsa كه به همراه OpenVPN ارائه مي‌شود) ايجاد كرده و مدخل‌هاي ccd را در سرور اصلي به‌روزرساني مي‌كنيد. حال مي‌توانيد چندين ميزبان را در سطح شبكه تنظيم کرده و به‌عنوان كلاينت‌هاي سرويس OpenVPN تعريف كنيد(كدفهرست 2).
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn4_s.jpg
فهرست 2- تنظيمات كلاينت براي سرويس OpenVPN
هر ميزبان جفت كليد اعتبارسنجي مختص به خود را دارد و راهنماي ifconfig-push در مدخل ccd براي اين ميزبان، آدرس‌هاي IP آنرا تنظيم خواهد كرد. ما آدرس IP مجازي را بر مبناي جفت كليد اعتبارسنجي آن به يك ميزبان مرتبط مي‌كنيم و اين كار به روشي كه براي تنظيمات DHCP به كار مي‌رود، بسيار شبيه است. يعني نگاشت آدرس IP به ميزبان بر مبناي آدرسEthenet MAC (آدرس يكتاي MAC مربوط به كارت شبكه) انجام مي‌شود. بنابراين، هر كلاينت بايد جفت كليد اعتبارسنجي مختص به خود را داشته‌باشد. توجه داشته‌باشيد كه ما از قابليت ذاتي OpenVPN در بررسي متوالي (round-robin) بين چند سرور به منظور ارتباط دوباره بعد از قطع تماس نيز استفاده مي‌كنيم. اين قابليت از طريق ويژگي و گزينه‌اي به نام keep-alive كنترل مي‌شود. بعد از انجام اين كار بايد بتوانيد كلاينت‌هاي OpenVPN را فعال كنيد آن‌ها نيز بايد بتوانند دست‌کم با سرور OpenVPN مربوط به خود ارتباط برقرار كنند و از طريق IP شماره 10.100.100.1 يا 10.100.100.101 به آن مراجعه كنند. اگر كلاينت شما به vpnsrvA متصل مي‌شود و شما ديمن يا سرويس روي vpnsrvA را غيرفعال كنيد، در اين صورت كلاينت مي‌تواند اين تغيير را تشخيص داده و به صورت خودكار دوباره به vpnsrvB متصل شود.
يك نكته كوتاه درباره ديواره‌هاي آتش در شبكه مجازي اين است که رابط اصلي شما در شبكه داده، با نام tun0 شناخته مي‌شود. بنابراين، تمام قوانيني را كه شما در تنظيمات تك‌منبعي، براي رابط eth0 تعريف مي‌كرديد، دوباره براي tun0 تعريف كنيد. رابط Ethernet جهت ارائه مجوز به ماشين كلاينت براي ارتباط UDP به پورت 1194 (OpenVPN) از هر دو سرور vpnsrvA و vpnsrvB به اختيارات بيشتري نياز خواهد داشت.
تنظيماتي كه ما قبلاً ايجاد كرده‌ايم، به نوعي براي تحمل خطا به كار مي‌رود. اگر vpnsrvA از دسترس خارج شود، تمام كلاينت‌ها به vpnsrvB متصل خواهند شد و مبادلات از سر گرفته مي‌شود. به عبارت ديگر، اين افزونگي از نوع active-passive است. اما در صورتي كه دو سرور vpnsrvA و vpnsrvB فعال باشند، چه اتفاقي خواهد افتاد. اجازه دهيد فرض كنيم، ميزبان 1 و 2 ديمن يا سرويس Openvpn را در حالت كلاينت اجرا كرده‌اند. host1 به vpnsrvA متصل شد و آدرس IP شماره 10.100.100.25 به آن اختصاص داده‌شد و host2 به vpnsrvB متصل و آدرس IP شماره 10.100.100.41 به آن اختصاص داده‌شد. جدول مسيريابي در vpnsrvA مطابق كد فهرست3 خواهد بود. در اين سناريو زماني كه host1 سعي مي‌كند تا دسترسي به آدرس 10.100.100.101 را از طريق دستور ping كنترل كند، پكت‌هاي ارسالي ابتدا به vpnsrvA مسيردهي مي‌شوند، اما دوباره به همان كارت شبكه tun0 مسيردهي مي‌شوند، زيرا vpnsrvA در مورد وجود vpnsrvB چيزي نمي‌داند. زماني كه host1 سعي مي‌كند با دستور ping به host2 متصل شود، vpnsrvA نيز مطابق آنچه در مسيردهي 10.100.100.0/24 گفته‌شده، اين پكت‌ها را پس مي‌فرستد و در نتيجه هر دو عمليات با خطا برخورد كرده و متوقف مي‌شوند.
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn6_s.jpg
فهرست3 - بخشي از جدول routing در vpnsrvA
ما براي برطرف كردن اين نقيصه، يك ديمن يا سرويس مسيردهي پويا با نام Cube-routed ايجاد كرديم (قابل دريافت از آدرس www.cohesiveft.com/multisourced-infra). اين ديمن اطلاعات مسيردهي را بين vpnsrvA و vpnsrvB به اشتراك مي‌گذارد و جدول‌هاي مسيردهي را با كلاينت‌ها با توجه به آن‌ها به يكي از اين دو سرور متصل مي‌شوند، تقريباً به طور لحظه‌اي به‌روزرساني مي‌كنند. ساختار داخلي آن خيلي پيچيده نيست. يك رشته، از طريق رابط مديريت خود، به ديمن ارائه دهنده سرويس محلي OpenVPN متصل مي‌شود (به گزينه‌هاي مديريت در فايل تنظيمات OpenVPN مراجعه كنيد) و به طور منظم دستور Status را براي به‌روزرساني فهرست كلاينت‌هاي متصل به سرور محلي اجرا مي‌كند. رشته ديگري به طور همزمان با فرآيند فوق، اين اطلاعات را براي يک Instance از Cuberotued كه روي سرور دوردست قرار دارد، ارسال مي‌كند. به‌طور همزمان رشته سوم نيز به‌صورت منظم، فهرستي از كلاينت‌هاي متصل به نمونه دوردست از Cube-routed را تهيه مي‌كند. در نهايت، رشته چهارم جدول مسيردهي محلي را بر مبناي دو قانون زير به روزرساني مي‌كند:
1- يك Route ميزبان را به ازاي هر يك از ميزبان‌هاي متصل به سرور OpenVPN دوردست اضافه مي‌كند.
2- به ازاي هر يك از ميزبان‌هاي متصل به سرور OpenVPN محلي، آدرس Route ميزبان را پاك مي‌كند.
نمونه‌هاي Rube-route نيز اطلاعات مديريتي را از طريق زيرشبكه مديريتي كه قبلاً انتخاب كرديم، مبادله مي‌كنند. تونل دوم با نام tun1 را بين vpnsrvA و vpnsrvB ايجاد كنيد. vpnsrvA يك سرور با آدرس IP به شماره 10.200.200.1 و vpnsrvB نيز كلاينت آن با آدرس IP به شماره 10.200.200.1 است. شما مي‌توانيد فايل‌هاي تنظيمات را بر مبناي اطلاعات كدفهرست 1 و 2 به‌عنوان نمونه ايجاد كنيد، اما حتماً آدرس IPها را تغيير دهيد و از پورت ديگري استفاده كنيد. به‌عنوان مثال، مي‌توانيد پورت 11940را به سرور و كلاينت اضافه كنيد. هر دو ديمن مربوط به OpenVPN را فعال كنيد و با ping زدن به IPهاي 10.200.200.1 و 10.200.200.5 وجود ارتباط بين آن‌ها را كنترل كنيد.
در هر دو vpnsrvA و vpnsrvB مطابق كدفهرست 4-الف و4-ب يك فايل تنظيمات براي سرويس cube-routed ايجاد كنيد و هر دو Instance را به عنوان كاربر Root با معرفي فايل تنظيمات به عنوان تنها پارامتر آغاز كنيد (توجه كنيد كه OpenVPN بايد از قبل در حال اجرا باشد و رابط‌هاي tun0 و tun1 روي هر دو سرور vpnsrvA و vpnsrvB فعال باشد).
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn7_s.jpg
فهرست 4-الف - بخشي از جدول routing در vpnsrvA
http://www.shabakeh-mag.com/data/gallery/2011/4/openvpn8_s.jpg
قهرست4-ب - فايل تنظيمات سرويس cobe-routed براي vpnsrvB
بعد از فعال‌كردن همه سرويس‌ها و بعد از چند دقيقه از زمان آغاز، در مثال فوق، host1 مي‌تواند با host2 ارتباط برقرار كند، هرچند آن‌ها به سرورهاي OpenVPN متفاوتي متصل مي‌شوند. بنابراين، شما توانسته‌ايد يك آدرس مجازي LAN با قابليت تحمل‌خطا ايجاد كنيد كه در عين حال از مزيت رمزنگاري داده مبادله‌شدن نيز بهره مي‌برد.
نتيجه‌گيري
اين پياده‌سازي نيز محدوديت‌هايي دارد. نخست برنامه‌هايي كه با روش broadcast يا multicast کار مي‌كنند، نمي‌توانند از ابزارهاي tun ارائه شده در استاندارد OpenVPN استفاده كنند. شما مي‌توانيد از همان چيدمان شبكه استفاده كنيد كه در اينجا به آن اشاره شده، اما در استاندارد OpenVPN ابزارهاي tun را با ابزارهاي نوع tap جايگزين كنيد. دوم تأخير ارتباطات شبكه‌اي در اينترنت، به مراتب بيشتر از شبكه‌هاي Ethernet است. اگر اين نقيصه، براي برنامه‌هاي شما مشكل‌ساز است، به‌احتمال شما بايد در اين قسمت از زيرساخت از همان روش‌هاي تك‌منبع قديمي استفاده كنيد. سوم، از آنجا كه ما از تونل‌هاي مبتني بر UDP استفاده مي‌كنيم، در نتيجه رابط‌هاي OpenVPN بيشتر از شبكه‌هاي Ethernet قطع و وصل مي‌شوند، به ويژه اين مشكل در زمان اشباع ترافيك شبكه بيشتر مشاهده مي‌شود. شما مي‌توانيد مكانيزم‌هاي ذخيره‌سازي داده را براي اجتناب از ارتباط‌هاي طولاني مدت TCP پياده‌سازي كنيد يا روي منطق مديريت استثنا در شبكه تمركز كنيد و به‌منظور كاهش تأثيرهاي منفي روش UDP از تونل‌هاي TCP استفاده كنيد. درنهايت شما در اين تنظيمات دو سرور OpenVPN ايجاد مي‌كنيد. دو سرور OpenVPN در بيشتر موارد كافي است و در تعداد ميزبان‌هاي واقعي كه به زيرساخت اطلاعاتي چندمنبعي متصل هستند، تأثيري ندارد. اگر به هر دليلي شما به بيش از دو سرور OpenVPN نياز داشته‌باشيد، در اين صورت پياده‌سازي به‌اشتراك‌گذاري Route بين Instanceهاي سرويس Cube-Routed مشكل‌تر مي‌شود. در چنين حالتي ممكن است بخواهيد به جاي روش سوكت‌هاي خام، از يك سيستم پيام‌رساني استفاده كنيد (به‌عنوان مثال از RabbitMQ). به طور كلي در موردي كه ما آنرا پياده سازي كرديم به خوبي مشهود بود كه مزاياي يك زيرساختار چند منبعي در برابر نواقص و محدوديت‌هاي آن ناچيز است، به ويژه آن‌كه اگر شما در معماري چندمنبعي خود اين محدوديت‌ها را نيز در نظر بگيريد.
زيرساخت چندمنبعي، نمونه توسعه يافته، روش تك‌منبعي در نسل قبل است و همانند معماري سرويس‌گرا بعد از برنامه‌هاي تك‌منظور ارائه شد و توانست انعطاف‌پذيري، سرعت بالا در پياده‌سازي سيستم‌ها و دسترسي‌پذيري بيشتري را فراهم كند. اين روش مي‌تواند به شما كمك كند تا با استفاده از يك روش اپن‌سورس و آزمايش‌شده به نام OpenVPN بتوانيد معماري هوشمندتري را به‌منظور اجتناب از محدود شدن به يك ميزبان در اختيار داشته‌باشيد.