نظرت إلى الوراء لمعرفة ما إذا كانت تتطلع إلى الوراء - 2 أو إلى مركز البيانات الخاص بي عبر AWS

ننشر أي خدمات موجودة في برنامج Hypervisor المنزلي من خلال خدمة EC2 Amazon Web Services من خلال نسخة مجانية لـ Amazon Linux AMI 2018 باستخدام libreswan و xl2tpd وبقليل من التشويه ...

يمتلك مسؤولو النظام في شركة (غير تابعة لتكنولوجيا المعلومات) ذات خبرة ، عادة بعد فترة من الوقت ، مزرعة افتراضية خاصة بالخوادم في المنزل لاختبار كومة الحلول على أرض الواقع. يمكن أن يكون هذا تقليدًا عاديًا لشبكة فروع المكاتب الموزعة ، واختبار بنية أساسية متكاملة توفر عالية ، ونشر إصدارات جديدة من بعض الحلول ، إلخ.

من الخارج ، يمكن أن ينظر من كمبيوتر منزلي بسيط مضخّ بالذاكرة مع برنامج Hypervisor مدمج و NAS من فئة المستهلك مثل تخزين iSCSI (أو حتى كجهاز ظاهري بسيط على نفس الكمبيوتر الشخصي) إلى خوادم مثبتة على حامل صغير الحجم تم شراؤها لوحدات التحكم المشطوبة بسعر رخيص مع نسب من مراكز البيانات الغربية ، مع نفس BU tsiska للاتصال بالشبكة وتعلق في القناة الليفية نفسه ، واشترى في NAS السوق الثانوية ، ولكن بالفعل درجة رجال الأعمال.

بالطبع ، في عصر الهوس بالغيوم لدينا ، يمكن بسهولة نشر البنية التحتية بأكملها في مراكز البيانات السحابية ، لكن هذا لا يزال غير ممكن دائمًا بسبب التكلفة. لا يهم ما إذا كانت الاختبارات تتطلب العديد من الأجهزة الافتراضية خفيفة الوزن من الخطط المتاحة ، ولكن ماذا لو كنت في الخدمة عليك تحريف عشرات أو حتى مئات "الأجهزة الظاهرية" المنفصلة مع مجموعة واسعة من الخدمات ، وتريد أيضًا الحصول على أرشيف حتى يمكنك الحصول عليه في أي وقت كان هناك عينة ملتوية في التكوينات / الإعدادات قبل عام. أو هناك حاجة لنقل جميع المزالق مع نفس التزامن بين ADDS و ADFS قبل نقل بعض خدمات الأعمال الحالية إلى نفس MS Azure.

المشكلة الرئيسية في هذه الحالة هي نشر (إعادة توجيه) كل هذه البنية التحتية إلى الخارج ، بحيث يمكنك ممارسة ربط المستخدمين من الخارج بـ "موقع الخادم" المنزلي أو بخدمات "السحابة" الخاصة بك ، أو التكامل مع خدمات الجهات الخارجية وما إلى ذلك.

من الجيد أن يكون الاتصال بالمنزل مصممًا لتعريف العمل ، وفي هذه الحالة لا توجد مشاكل مع الطلبات الواردة ، ويكون عنوان IP دائمًا "أبيض" ، ثابت.

ولكن ماذا تفعل عندما يكون مزود "المنزل" المعتاد موجودًا في مكان الإقامة ، والذي يمكن بالإضافة إلى ذلك فقط توفير عنوان من الشبكة الخاصة. أم أنها ستعطي عنوانًا أبيض ، ولكنها تقطع تقليديًا جميع الرسائل الواردة من نطاق المنافذ المميز (<1024)؟ أو أنت طالب فقير مبتذل وببساطة لا يمكنك تحمل معدل شهري مصمم للكيانات القانونية. أو هل يتعين عليك غالبًا تغيير مكان إقامتك ، وسحب "متعلقاتك" الخاصة بالملقم الظاهري إلى الحدبة؟ هناك حالة خاصة ذات صلة أيضًا بأولئك الذين يعيشون خارج CIS ، عندما يوفر المزود بالقوة معداته الخاصة للاتصال بالإنترنت وهناك ببساطة لا يمكنك فعليًا تكوين إعادة توجيه المنافذ التي تحتاجها إلى المزرعة الافتراضية المنزلية بالخارج.

أحد الحلول هو استخدام أي من خدمات VPN التابعة لجهة خارجية. لسوء الحظ ، يسمح عدد قليل منهم بإذن الاتصالات الواردة فيما يتعلق بالنفق ، وغالبًا ما تكون خدمة مدفوعة منفصلة. وفي هذه الحالة أيضًا ، سيكون اختيار عناوين IP الخارجية محدودًا للغاية إذا كنت ترغب في اختبار الموقف مع وجود عنوان IP خارجي في بلد معين ، علاوة على ذلك ، كقاعدة عامة ، لا يوجد ضمان بأن مجموعة من عملاء خدمة VPN الآخرين لا يعلقون على هذا العنوان في الوقت نفسه. ، أو سيكون ثابتًا لفترة طويلة ، وهو أمر مهم لإعداد سجلات نطاقات الخدمة في DNS.

جدير أيضًا (IMHO) ، على الرغم من بعض الطرق المنحرفة ، بنشر جهاز التوجيه "الظاهري" الخاص بك على بعض الأنظمة الأساسية السحابية الخارجية مع القدرة على تكوين نفق VPN من مزرعة hypervisor المنزلية إلى هذا الجهاز الظاهري في السحابة ، مع إعادة توجيه الاتصالات الواردة الضرورية من واجهة الشبكة الخارجية الغيوم على خدمات hypervisor المنزل. ومن الناحية المثالية ، لدفع أي شيء تقريبا عن كل شيء.

بعد أن فقدت وظيفتي مؤخرًا ، ومعها الوصول إلى مزرعة اختبار دافئة ومريحة للشركات ، ولكن في المقابل حصلت على الكثير من وقت الفراغ لتحديث مهاراتي ، قررت منح الخدمات من برنامج Hypervisor في منزلي الفرصة لرؤية اتصالات العملاء الواردة.

مؤلف هذه السطور "يحب جميع أنواع الانحرافات في البنية التحتية" ، لذلك كموجه افتراضي ، سوف نستخدم مثيل Amazon Web Services (AWS) EC2 t2.micro المجاني لنظام Linux ، والذي بدلاً من AWS: VPC (نظريًا) يمنح مزيدًا من المرونة في تصحيح الأخطاء والميزات ، وطوبولوجيا هذا الانحراف VPN موضح أدناه:



ماذا نرى هنا؟

هناك (750 ساعة من العمل شهريًا خلال العام) آلة افتراضية (مثيل) ، على نظام Linux ، تم نشرها في AWS: EC2. تنقسم المكالمات الواردة من بعض مستخدمي خدماتك المنزلية إلى عنوان IPv4 الأبيض الخارجي لعنوان IP المرن ، ثم من خلال القواعد الواردة (الواردة) في "مجموعات الأمان" ، نحتاج المنافذ إلى الداخل إلى واجهة شبكة المثيل ، ثم تنتقل حزم هذه الطلبات من خلال iptables إلى نفق IPSec إلى جهاز افتراضي لنظام التشغيل Windows 2016 ، حيث يستخدم RRAS ، باستخدام التوجيه ، الخدمة المطلوبة داخل المزرعة الافتراضية المنزلية. نولي اهتمامًا خاصًا لوجود ثلاثة من NAT في آن واحد: واحدة في AWS Linux ، وواحدة على جهاز التوجيه "network office" وواحدة أخرى ، ضمنية ، على جهاز التوجيه المنزلي.

في هذه الحالة (حاليًا) ، يلعب جهاز ظاهري يعمل بنظام Windows Server 2016 دور جهاز التوجيه لمحاكاة شبكة مكتب ومنصة الخادم الخاصة به ، ويتم نشر MS WAP عليه جنبًا إلى جنب مع جهاز منفصل مع MS ADFS وغيرها ، لذلك لا توجد مشكلة في استبداله بأي نظام تشغيل آخر حتى قطعة محلية الصنع لتذوق. مع Windows RRAS ، بالمناسبة ، تصبح الأمور معقدة على طول الطريق ، وكان عليّ التعامل مع لحظات مختلفة غير سارة (حولها أدناه) ، لذلك إذا اخترت عدم إعجاب MS Windows Server كموجه ، فمن المحتمل أن يكون الأمر أسهل.

أولاً ، سننشئ حساب AWS إذا لم يكن لديك حساب بعد. لا توجد مشكلة في إنشاء الحساب نفسه ، فأنت تحتاج فقط إلى الإشارة إلى تفاصيل البطاقة البلاستيكية الخاصة بك ، والتي سيتم خصم 1 دولار منها (ثم إعادتها) كشيك.

هناك نقطتان فقط يجب ذكرهما هنا:

1. تأكد من الذهاب إلى AWS: IAM (إدارة الهوية والوصول) وتمكين MFA (مصادقة متعددة العوامل) لحسابك الجديد ، أو حتى أفضل ، كما توصي AWS - إنشاء حساب منفصل مع MFA كذلك ومواصلة العمل من خلال تقييد الحقوق المقابلة. ذلك. خلاف ذلك ، قد ينتهي بك الأمر في موقف غير سارة عندما يسرق طروادة أوراق اعتماد AWS من جهاز الكمبيوتر الخاص بك ، وعلى سبيل المثال ، شخص ما لي من قلبك على نفقتك الخاصة على خطط مثيل عالية الأداء مكلفة ...
2. لأسباب عملية ، يوصى بإعداد تنبيه للميزانية. يتم ذلك في إعدادات الحساب ، ويسمى عنصر القائمة المقابل "لوحة تحكم إدارة الفواتير والتكلفة". في اللوحة التي تفتح ، حدد عنصر "الميزانيات" على اليسار وتكوين الميزانية الشهرية المخطط لها لتذوق باستخدام المعالج المدمج. لا تنس إعداد تنبيه هناك: في حالة تجاوز المبلغ المحدد ، ستتلقى رسالة على الفور. يعد هذا مفيدًا إذا لم تكن قد عملت مع AWS من قبل وكنت خائفًا من "الحصول" بطريق الخطأ على مجموع مستدير في تجاربك.

بعد ذلك ، نحن بحاجة إلى AWS: EC2 .

واحدة من أهم الخطوات هي اختيار منطقة AWS (أساسًا مركز بيانات) الذي نريد نشر جهازنا الافتراضي فيه. سيؤثر الموضع بشكل مباشر على الموقع الجغرافي لـ "الموجه الظاهري" الخاص بك ، وبالتالي تأخير الشبكة عند التعامل معه. هذا مهم لأنه لا يوفر AWS الترحيل المباشر بين المناطق (يمكن لخدمة ترحيل خادم AWS المضمنة فقط ترحيل شيء إلى سحابة AWS نفسها) وفي حالة حدوث خطأ في الموقع ، يكون من السهل إعادة إنشاء مثيل جديد مرة أخرى في الموقع المطلوب. بدلاً من ذلك ، سوف تضطر إلى إزالة الصورة من المثيل (الصورة ، EC2 المضمنة) في AWS: S3 (خدمة التخزين) ومن هناك يمكنك سحب هذه الصورة إلى مثيل EC2 في المنطقة الجديدة. في حالتي ، تم اختيار منطقة فرانكفورت في الأصل:



نقوم بإنشاء مثيل جديد ، حدد الخيار "المستوى المجاني فقط" على اليسار ، والذي سيقصر قائمة الصور المقترحة على الصور المجانية فقط. لقد اخترت "Amazon Linux AMI 2018" ( المزيد عن توزيعات Linux في AWS) ، لأنه على "Amazon Linux 2 AMI" xl2tpd لا يعمل بشكل صحيح بسبب طبيعة النواة التي جمعتها أمازون.

يمكنك اختيار أي صورة Linux أخرى مألوفة لك من القائمة المتوفرة. يمكنك أيضًا التعمق في سوق AWS والبحث عن صور بديلة هناك ، فقط اقرأ التعليقات حول التكلفة بعناية: يمكن أن تكون الصورة نفسها وموارد الحوسبة مجانية ، لكن سيتعين عليك دفع تكلفة إضافية على مساحة القرص ، إلخ.

نختار النوع المقترح "t2.micro" ، فهو يوفر 1 وحدة معالجة فردية ووحدة ذاكرة واحدة و 8-30 جيجابايت (SSD / Magnetic) من مساحة القرص و 750 ساعة من العمل مجانًا كل شهر لمدة عام. بما فيه الكفاية لدينا "جهاز التوجيه الظاهري". تجدر الإشارة إلى أن مساحة القرص الحرة ووقت العمل يقضيان في جميع الحالات ، لذلك في حالة وجود صعوبات مالية لا تحتاج إلى إنشاء / تشغيلها أكثر مما يمكنك تحمله إلا مجانًا.

انقر فوق معالج "Next ..." ، في الخطوة الثالثة ، نترك كل القيم الافتراضية ، في الرابع نوافق على 8 غيغابايت المقترحة من قرص SSD الافتراضي ويبدأ المثيل مع زر المراجعة والتشغيل:



بعد ذلك ، سنحصل على نافذة بها رسالة حول إنشاء زوج مفاتيح جديد للاتصال بنا عبر SSH واقتراح لتسمية هذا الزوج وتنزيل المفتاح الخاص بتنسيق * .pem. سنحتاجها حقًا في المستقبل ، لذلك ينصح بحفظها على الفور في مكان آمن. إذا تم فقدان هذا الملف ، فستفقد القدرة على الاتصال عن بعد بالمثيلات التي تستخدمه. في EC2 ، لا توجد طريقة لتجديده مرة أخرى لمثيل موجود ، والطريقة الوحيدة هي توصيل قرص المثيل بمثيل آخر لديه حق الوصول وتحرير المفتاح اللاحق.

بعد فترة ، سيتم إطلاق المثيل ، وسيكون له عنوان IPv4 داخلي (خاص) وخارجي (عام) ، بالإضافة إلى اسمين متطابقين لـ DNS.
قم بتكوين مجموعات الأمان على الفور لضمان تدفق حركة المرور للخدمات التي تحتاجها:



سنحتاج إلى المنافذ الواردة المفتوحة 500 ، 1701 ، 4500 UDP و 4500 TCP لتنظيم نفق IPSec L2TP VPN ، HTTP و HTTPS لنشر خدمات المزرعة المنزلية ، تم إنشاء الوصول الخارجي إلى المثيل عبر SSH تلقائيًا عند إنشاء المثيل ، لأن لا يحتوي EC2 بشكل أساسي على أي وصول مدمج إلى وحدة التحكم في الجهاز الظاهري من خلال واجهة الويب الخاصة به. هناك فقط القدرة على عرض الشاشة:



يُنصح بتكوين الوصول عبر VPN و SSH فقط من عنوان IP للمنزل. لا يهم ترتيب القواعد في مجموعات الأمان.

نظرًا لأننا سنستخدم وثائق NAT متعددة ، توصي AWS بتعطيل "التحقق من مصدر الشبكة / الوجهة" في هذه الحالة:



نظرًا لأننا سنستخدم نفق IPSec ، وليس النقل ، فإن هذا الإعداد ليس له معنى كبير بالنسبة لنا ، ولكن في حالة إيقاف تشغيله ، فمن الأفضل إيقاف تشغيله.

الاتصال من خلال SSH إلى مثيلنا. إذا كنت تستخدم عميل SSH رسومياً ، على سبيل المثال ، PuTTY ، للاتصال ، فإن المساعدة المدمجة في الاتصال ، والتي يطلق عليها RMB في المثيل -> Connect ، ستساعدك:



يحافظ Amazon Linux على نسب من RHEL و CentOS ، لذلك يتم استخدام مدير حزمة yum.

يجب إجراء جميع العمليات الموضحة أدناه مع تصعيد الامتياز ، وبالتالي فإننا نسبقها بـ sudo أو نعمل فقط كجذر.

التحديث الأول:

# yum update 

كبرنامج لتنظيم خادم VPN ، سوف نستخدم مزيجًا من libreswan و xl2tpd.

LibreSwan (شوكة Openswan وتناظرية من strongSwan) هو تطبيق شائع لـ VPN IPSec و IKE (تبادل مفاتيح الإنترنت). يمكنه تجاوز أنواع مختلفة من NAT ومجموعاتها بشكل صحيح ، وهو أمر مهم بشكل خاص عند تنظيم نفق IPSec.

يستخدم xl2tpd أيضًا على نطاق واسع ، وتتمثل ميزته الرئيسية في القدرة المضمنة على المصادقة ونقل معلمات اتصال العميل عبر ppp عند الاتصال (على سبيل المثال ، عناوين IP ، وإعدادات المسار الافتراضي ، وخوادم نظام أسماء النطاقات ، وما إلى ذلك) ، مما يلغي الحاجة إلى نشر DHCP و Radius الإضافي لدينا مهام بسيطة.

نظرًا لأن xl2tpd ليس في مستودعات Amazon Linux القياسية ، نحتاج إلى تمكين EPEL (حزم إضافية لنظام التشغيل Linux):

 # yum-config-manager --enable epel 

تثبيت الحزم اللازمة:

 # yum install libreswan xl2tpd -y 

تمكين توجيه مستوى kernel:

في الملف /etc/sysctl.conf نكتب:

 net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 1 net.ipv4.conf.all.send_redirects = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.conf.default.send_redirects = 0 net.ipv4.conf.lo.accept_redirects = 0 net.ipv4.conf.lo.secure_redirects = 0 net.ipv4.conf.lo.send_redirects = 0 net.ipv4.conf.eth0.accept_redirects = 0 net.ipv4.conf.eth0.secure_redirects = 0 net.ipv4.conf.eth0.send_redirects = 0 net.ipv4.conf.all.rp_filter = 0 net.ipv4.conf.default.rp_filter = 0 net.ipv4.conf.eth0.rp_filter = 0 

تعطيل rp_filter في الجلسة الحالية حتى لا تعيد التشغيل:

 # for f in /proc/sys/net/ipv4/conf/*/rp_filter ; do # echo 0 > $f # done 

نحن نطبق الإعدادات ونتحقق من توفر التوجيه:

 # sysctl -p /etc/sysctl.conf # cat /proc/sys/net/ipv4/ip_forward 

نحتاج إلى ضمان إعادة توجيه الحزم الواردة (فيما يتعلق بالواجهة العامة للمثيل) من منافذ الخدمات المطلوبة إلى نفق IPSec في المستقبل. لهذا ، من الضروري ليس فقط إلغاء تثبيت هذه الحزم ، ولكن أيضًا القيام بالتنكر على واجهة ppp0 .
سنستخدم ميزات iptables المدمجة لهذا الأمر ، والتي في حالة تكوين Amazon Linux مبدئيًا للسماح تمامًا لأي حركة مرور في أي اتجاه:

جعل DNAT من المنافذ المطلوبة:

 # iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to-destination 10.100.0.2:80 # iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 443 -j DNAT --to-destination 10.100.0.2:443 

إعادة توجيه جميع الحزم التي جاءت إلى هذه المنافذ إلى عنوان بوابة Windows:

 # iptables -A FORWARD -p tcp -d 10.100.0.2 --dport 80 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT # iptables -A FORWARD -p tcp -d 10.100.0.2 --dport 443 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT 

هل تتنكر لهذه الحزم:

 # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE 

من المستحسن الاحتفاظ بقواعد iptables بحيث يتم تشديدها تلقائيًا عند إعادة تشغيل المثيل:

 # service iptables save 

في هذه الحالة ، نستخدم DNAT (NAT الوجهة) لمنفذ TCP المطلوب من eth0 لواجهة الشبكة للمثيل في اتجاه عنوان IPv4 10.100.0.2 ، وهو العنوان على واجهة ppp لخدمة RRAS الخاصة بوحدة نظام التشغيل Windows الخاصة بنا في المشرف الرئيسي.

فيما يلي نقطة مهمة للغاية: نظرًا لأن الخدمات داخل برنامج Hypervisor يجب أن تكون قادرة على الاستجابة للطلبات الواردة من مثيل AWS ، فمن الضروري تقديم تنكر (استبدال عنوان المرسل) على واجهة ppp0 للمثيل قبل إرسال الحزمة ، وإلا فإن الإجابة ستذهب في اتجاه مختلف تمامًا: من بوابة Windows في برنامج hypervisor بعد نفق IPSec مباشرة إلى جهاز التوجيه الافتراضي (الموجه المنزلي) ، ونتيجة لذلك ، سيتم تجاهلها بالطبع من جانب العميل من الخدمة ، كما لو كانت مصدرها مصدر غير مرغوب فيه. إذا تم استخدام التنكر في رأس الحزمة عند مدخل نفق vpn ، فسيتغير عنوان المرسل من العنوان في مكان ما على الإنترنت إلى العنوان ppp0 لواجهة مثيل AWS: EC2 ، أي في حالتي في 10.100.0.1

كبديل لاستخدام iptables لتوزيعات Linux الأخرى أو أنظمة * NIX ، يمكنك أن توصي rinetd القديم الجيد ، حيث يتم كل هذا بشكل عام في سطر واحد بتكوينه rinetd.conf :

 <ip source> <port source> <ip destination> <port destination> 

الشيء الوحيد الذي سيحتاج إلى تمكين في هذه الحالة في النواة هو إمكانية توجيه / حركة المرور NAT.

حان الوقت لطهي الطعام libreswan.

يحتوي ملف /etc/ipsec.conf على إرشادات لتنزيل جميع ملفات .conf من /etc/ipsec.d/ ، لذلك ، نقوم بإنشاء ملف تكوين جديد في دليل /etc/ipsec.d/aws_vpn.conf وإضافته إليه:

 config setup #       # plutostderrlog=/var/log/pluto.log # logfile=/var/log/pluto.log # plutodebug = all #  NAT-T -   NAT- nat_traversal=yes oe=off protostack=netkey nhelpers=0 interfaces=%defaultroute conn aws_vpn type=tunnel auto=start forceencaps=yes pfs=no fragmentation=yes authby=secret left=%defaultroute #   <…>      Elastic IP leftid=<…> #   <…>     (172...) leftsubnet=<…>/32 leftnexthop=%defaultroute leftprotoport=17/1701 rightprotoport=17/%any right=%any rightsubnetwithin=0.0.0.0/0 rightsubnet=vhost:%priv 

للبساطة ، سوف نستخدم مصادقة IPSec استنادًا إلى مفتاح مشترك (PSK) ، وليس شهادات ، لذلك يجب علينا تحديده بشكل صريح. يحتوي الملف /etc/ipsec.secrets على إرشادات لتنزيل جميع ملفات .secrets من /etc/ipsec.d/ ، حيث نقوم بإنشاء ملف جديد /etc/ipsec.d/aws_vpn.secrets وتحديد PSK به بالتنسيق:

 <     172...> %any : PSK "< PSK>" 

كمثال:

 172.31.20.120 %any : PSK "Pa$$w0rd" 

نظرًا لأنه سيتم استخدام اتصال ppp داخل نفق IPSec ، وهناك مصادقة خاصة به ، فإننا نقوم بتكوينه أيضًا:
ندخل اسم المستخدم وكلمة المرور في الملف / etc / ppp / chap-secrets في التنسيق:

 <user> * <password> * 

كمثال:

 aws_user * Pa$$w0rd * 

عند الاتصال بعميل ppp ، من الممكن تمرير عدد من الخيارات لتكوين واجهة الشبكة وجدول التوجيه من جانبها.

في ملف /etc/ppp/options.xl2tpd ، عيّن هذه الخيارات:

 #  xl2tpd  ip   ipcp-accept-local ipcp-accept-remote #    defaultroute   Windows-    nodefaultroute noccp auth #   RRAS  Windows-  mschap-v2   require-mschap-v2 #   MTU  MRU mtu 1410 mru 1410 lock 

لأن نحن لسنا بحاجة لتمرير DNS ، يفوز ، الخ عناوين إلى العميل. الأشياء - جميع الخيارات الأخرى تحتاج إلى تعليق.

هنا تحتاج إلى شرح التكوين.

يتمثل السلوك القياسي لاتصالات VPN في تثبيت "مسار افتراضي" جديد في جدول العميل ، مما يفرض على كل حركة المرور منه إلى الإنترنت "الانتقال" عبر خادم vpn. في حالتنا ، هذا خطأ ، لأن الهدف من بوابة Windows هو توفير الوصول المحاكاة إلى شبكة الإنترنت لشبكة المكتب الافتراضية التي تقف وراءها في برنامج Hypervisor ونشر موارد الخدمات الداخلية للخارج عبر AWS: EC2 ، لذلك فمن غير المنطقي توجيه كل حركة المرور عبر المثيل إلى AWS: EC2. هذا هو السبب في أنك بحاجة إلى منع اتصال VPN في RRAS من تغيير المسار الافتراضي (إلى جهاز توجيه منزلي).

من المهم أيضًا اختيار قيم MTU و MRU الصحيحة: نستخدم نفق IPSec وقد لا يتناسب حجم الحمولة النافعة مع حد التغليف ، مما يؤدي إلى تجزئة وعلى الأرجح خطأ. إذا ظهر ، فحاول أولاً وقبل كل شيء تقليل هذه القيم ، على سبيل المثال ، إلى 1280. القيم المشار إليها في التكوين المحدد متوافقة مع عميل Windows VPN.

يبقى لتكوين xl2tpd

نقوم بتهيئة كل ما هو ضروري في ملف التكوين xl2tpd /etc/xl2tpd/xl2tpd.conf :

 [global] port=1701 ipsec saref = yes ; ,      ;debug tunnel = yes ;debug avp = yes ;debug network = yes ;debug state = yes ;debug tunnel = yes [lns default] name = AWSvpnServer ;       ppp ip range = 10.100.0.2-10.100.0.2 ;    ppp0 AWS:EC2  local ip = 10.100.0.1 require authentication = yes require chap = yes refuse pap = yes pppoptfile = /etc/ppp/options.xl2tpd length bit = yes 

نتحقق من كل ما قمنا به

نحاول تشغيل كلتا الخدمتين والتحقق من التكوينات:

 service ipsec start service xl2tpd start ipsec verify 

قد تكون الخدمات قيد التشغيل بالفعل ، وفي هذه الحالة يتم إعادة تشغيلها ببساطة.

إذا كان كل شيء على ما يرام ، فعندئذ يجب أن يكون ناتج التحقق من ipsec مشابهاً للشاشة:



يمكنك تصحيح xl2tpd بشكل تفاعلي عن طريق تشغيله مع مفتاح التبديل -D وتعليقه في "نافذة" منفصلة من محطة SSH باستخدام أداة الشاشة :

 # xl2tpd -D 

في هذه الحالة ، لن تدخل عملية xl2tpd في الخلفية ، ولكنها ستعرض جميع أنشطتها على شاشة الجهاز الطرفي.

في حالة وجود أي مشاكل ، تحتاج إلى إلغاء تثبيت خيارات تصحيح الأخطاء في التكوينات (انظر التعليقات) وإلقاء نظرة على محتويات سجلات النظام وملف /var/log/pluto.log . يجدر أيضًا الانتباه إلى محتويات الخيار virtual_private / virtual-private في ملف /etc/ipsec.conf ، فهو يسرد جميع الشبكات الخاصة المتاحة لتبادل البيانات عبر IPSec. إذا كان لديك عنوان خاص بك لسبب ما ، على سبيل المثال ، إذا كنت تستخدم مجموعتك الخاصة من عناوين IPv4 البيضاء ، فعليك إجراء تغييرات على هذه المعلمة.

دعنا ننتقل إلى الخطوة الأخيرة - إعداد خدمة RRAS في بوابة Windows والتحقق من نشر الخدمات من الإنترنت

من المفترض أن يشتمل برنامج hypervisor في منزلك على جهاز افتراضي يعمل بنظام Windows 2012R2 أو أحدث ، ويتم نشره في وضع الرسوم البيانية (سطح المكتب) ، وهناك محوّلان لشبكة الاتصال في هذا الجهاز الظاهري: أحدهما "ينظر" إلى الشبكة المنزلية ولديه جهاز توجيه منزلي باعتباره المسار الافتراضي والآخر في شبكة "مكتبية" محلية افتراضية ، حيث توجد خدمات منشورة في الخارج. مجال Windows اختياري ، إلا إذا كانت الخدمات نفسها تتطلب ذلك بالطبع.

نقوم بتثبيت جميع الأدوار اللازمة باستخدام Server Manager أو باستخدام الأمر PowerShell Install-WindowsFeature cmdlet:



أشرح هنا تثبيت الأدوار من خلال الرسومات ، لأنه بعد ذلك سوف يكون أكثر ملاءمة للاتصال بمعالج الإعداد من Server Manager وتكوين خدمة RRAS نفسها في الجدول الزمني ، مما يرضينا مع الواجهة القديمة الجيدة من وقت Windows Server 2003:



انقر فوق RMB على الخادم الخاص بك ، وحدد "تكوين وتمكين التوجيه والوصول عن بعد" ثم قم بتكوينه يدويًا:



لا تتردد في اختيار جميع الغربان ، واستكمال المعالج وبدء الخدمة:



أولاً ، دعنا نطلق شبكتنا المحلية الافتراضية بالخارج. نذهب إلى IPv4-> NAT وننشئ واجهة جديدة ، مثل الواجهة الحالية التي سيتم تنفيذ NAT عليها ، حدد الواجهة الخارجية (التي تبدو في الإنترنت ، أو بالأحرى في شبكتك المنزلية) ، ووضع علامة عليها كعمومية وتمكين NAT عليها:



نتحقق من كيفية خروج حركة المرور من الشبكة المحلية الافتراضية عبر بوابتنا. لا نحتاج إلى تكوين جدار حماية Windows حتى الآن.

إذا كان كل شيء على ما يرام ، فسوف ننشئ أخيرًا ما كنا نقاتل من أجله ، اتصال VPN لمثيل AWS الخاص بنا والتحقق من نشر خدماتنا. نذهب في الأداة الإضافية RRAS إلى "واجهات الشبكة" وننشئ واجهة جديدة لطلب الطلب باسم اعتباطي:



حدد اتصال L2TP على الفور ، لذا لن تحاول واجهتنا الجديدة تحديد نوع VPN تلقائيًا ونتيجة لذلك سيتم الاتصال بشكل أسرع:



علاوة على ذلك ، نشير إلى المعالج إلى العنوان العام لسحابة لدينا (في حالتي ، عنوان IP المرن). في الخطوات التالية ، اترك كل شيء كما هو ، لأن لا نحتاج إلى اتصال موقع إلى:



حدد حساب المستخدم الذي قمنا من خلاله بتهيئة اتصال ppp (في الملف / etc / ppp / chap-secrets ). لا يوجد اسم نطاق مطلوب:



يقوم المعالج بإنشاء اتصال جديد. الآن يبقى لتكوينه. سنقوم بضبط مهلة الخمول (وقت الخمول) ، وإزالة CHAP القديمة لصالح MS-CHAPv2 فقط ، وتحديد مفتاح PSK في "الخصائص المتقدمة" (تلك التي تم ضبطها على xl2tpd في الملف /etc/ipsec.d/aws_vpn). أسرار) وإزالة IPv6:



بعد إنشاء واجهة جديدة ، يجب عليك أيضًا الدخول في خصائص خدمة RRAS نفسها ، وتمكين سياسة IPSec لـ L2TP وتحديد PSK. يطلب منهم إعادة تشغيل خدمة RRAS.



يبدو أنه يمكن رفع كل شيء بأمان واجهة جديدة والاستمتاع بالعمل. لكن لا. نظرًا لحقيقة أننا استخدمنا NAT على جانب نسخة AWS: EC2 ، فلن يتمكن عميل Windows VPN من الاتصال بمثل هذه العقدة Nat-Traversal. هذا صحيح سواء بالنسبة لإصدارات العميل (حتى الأحدث في وقت كتابة هذه المقالة من نظام التشغيل Windows 10) ولإصدارات الخادم.

لحسن الحظ ، يوجد حل رسمي لهذه المشكلة في شكل تعديلات في سجل إعدادات خدمة سياسة IPSec متبوعة بإعادة التشغيل:

في
HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ PolicyAgent
إنشاء مفتاح DWORD (32 بت)
تفترض UDPEncapsulationContextOnSendRule = 2
واعادة التشغيل لدينا بوابة ويندوز.

تشتهر خدمة RRAS لسوء الحظ بتقلصها في التكوين والتشغيل ، وحتى بعد إعادة التشغيل ، فإنها تؤدي بداية متأخرة. حتى تتمكن من التسرع بعد إعادة تشغيل الكمبيوتر.
إذا تم كل شيء بشكل صحيح ، فإن الاتصال سيعمل في غضون 5-10 ثواني.

يبقى لجعل نشر الموارد اللازمة على بوابة ويندوز نفسها.

للاختبار ، سنعمل على نشر خادم الويب. أولاً ، تحقق من نفق IPSec وقواعد iptables.

بأيدي يرتجف ، نتحقق من جهاز كمبيوتر تعسفي متصل بالإنترنت:



واو ، وأنها تعمل ...

أثناء تثبيت الأدوار اللازمة ، تم تثبيت MS IIS "الأصلي" بالقوة ، لكننا نريده أكثر سهولة. لهذا ، على نظام Windows ، HFS (خادم ملفات HTTP) مناسب تمامًا - إنه مجاني ، ولا يحتاج إلى تثبيت ، ويعطي صفحة معينة ورأس HTTP ، ويمكن أن يعمل على منفذ تعسفي (8080 بشكل افتراضي ، لذلك سيكون من الضروري إعادة التكوين إلى 80) ، وأيضاً يكتب على الفور في وحدة التحكم الخاصة به من أين جاء الاتصال ، وهو مناسب جدًا لتصحيح أخطاء نشر العديد من موارد الويب على نظام Windows الأساسي. لاستخدامها ، يجب عليك أولاً إيقاف موقع MS IIS من أجل إلغاء ربط الخادم المضمن من المنفذ المطلوب. نظرًا لأننا لا نريد تثبيت وحدة تحكم إدارة MS IIS (في الواقع ، ستكون وحدة التحكم MS IIS 6 موجودة للتوافق ، ولكن لا يمكن التحكم في IIS 7+ من خلاله) ، سنفعل ذلك من خلال PowerShell:

 Stop-WebSite -Name "Default Web Site" 

أو ببساطة من خلال أداة إدارة iisreset:

 iisreset /stop 

بعد ذلك ، تحتاج إلى السماح لحركة المرور الواردة إلى المنفذ 80 في جدار حماية Windows المدمج.
نبدأ HFS والتحقق من:



كل شيء رائع. لقد حققنا أنه من أي مكان على الإنترنت ، يمكنك رؤية خادم الويب الذي يعيش في منزلنا كجهاز افتراضي في برنامج hypervisor التعسفي.

اللمسة الأخيرة: نعلم RRAS إعادة توجيه كل هذه الطلبات من الخارج إلى شبكة المكتب الافتراضية ، حيث وفقًا للأسطورة ، لدينا خادم ويب آخر.

للقيام بذلك ، نذهب مرة أخرى إلى الأداة الإضافية لإدارة RRAS في IPv4-> NAT و RMB على واجهة VPN الخاصة بنا ، حيث نختار علامة التبويب "الخدمات والمنافذ" ، ونضع علامة عليها في قائمة خادم الويب ونحدد خادم الويب في الشبكة الافتراضية الداخلية التي نرغب في نشر مواردها الإنترنت:



انقر فوق موافق و ... كل شيء جاهز. نتحقق - كل شيء يجب أن تعمل بشكل جيد.

بهذه الطريقة البسيطة ، يمكنك بسرعة نشر أي خدمات وموارد تقريبًا ، من المواقع وخوادم البريد إلى بعض عمليات الدمج المعقدة. بطبيعة الحال ، بالنسبة لمعظمها ، ستحتاج إلى امتلاك مجال DNS الخاص بك مع القدرة على إنشاء نطاقات فرعية فيه وتحرير السجلات اللازمة. يُنصح أيضًا باستخدام شهادات طبقة المقابس الآمنة (SSL) لنشر موارد الويب ، وذلك بفضل LetsEncrypt والخدمات المماثلة المتوافقة مع ACME ، كل هذا يمكن أن يتم مجانًا تمامًا وبتحديث تلقائي.

عند إعادة تشغيل المثيل ، لا يتغير عنوان IPv4 العمومي - فقط عند إيقافه ، لكن يوصى باستخدام عنوان IPv4 ثابت في AWS: EC2. ثابت ، بمعنى أنه عندما تقوم بإيقاف تشغيل المثيل الخاص بك ، فسيظل مخصصًا له ، ولن يقع في المجموعة المجانية العامة. بالطبع ، هذا ضروري حتى لا تهتم في كل مرة بإعادة تكوين سجلات DNS في المجالات ، ولم يلغ أي شخص TTL بالتخزين المؤقت. يكلف الكثير من المال ويسمى ، كما ذكرنا أعلاه ، IP المرن .

أتمتة العملية البدائية

أخيرًا ، أود أن أذكر ميزة أخرى رائعة لـ AWS: EC2 - التكوين السريع للمثيل الذي تم نشره. هناك العديد من خيارات النشر السريع في AWS: EC2 ، حتى الخدمات الخاصة (والمعقدة إلى حد ما ، لكنها قوية للغاية) ، ولكن هناك أبسطها: في الخطوة 3 في المعالج لإنشاء مثيل جديد في أسفله ، يوجد حقل "بيانات المستخدم" . يمكنك وضع برنامج نصي في bash أو حتى PowerShell فيه (في حالة مثيل لنظام Windows) ، وسيتم تنفيذ هذا البرنامج النصي تلقائيًا فور إنشاء المثيل.
أي يمكنك تعديل جميع الأوامر والتكوينات المذكورة أعلاه قليلاً لإنشاء نص bash الخاص بك واستخدامه لرفع مثل هذا الموجه AWS: EC2 الظاهري بسرعة. تعرف على المزيد حول هذه الميزة .

شكرا لأخذ الوقت الكافي لقراءة هذا المقال.