IPSec سبحانه وتعالى

مساء الخير يا اصدقاء. ليس سراً أن الكثير منا لديه مرة واحدة على الأقل ، ولكن كان عليه أن يتعامل مع الحاجة إلى تكوين VPN. كوني قارئًا نشطًا لحبر ، لاحظت أنه على الرغم من وفرة المقالات حول IPSec ، إلا أنه بالنسبة للكثيرين لا يزال يبدو شيئًا معقدًا ومحملاً. في هذه المقالة سأحاول تبديد هذه الأساطير باستخدام التكوين الخاص بي الذي يعمل بشكل كامل كمثال. في أربعة أمثلة ، سنستعرض تمامًا تكوين حل Linux (Strongswan) الأكثر شيوعًا ، من نفق بسيط مع مصادقة جانبية بمفاتيح PSK إلى اتصال من مضيف إلى مصادقة مع كلا الجانبين بناءً على شهادات من Let's Encrypt. مثير للإعجاب؟ مرحبًا بك في القط!

خلفية


في البداية ، تم التخطيط لشبكة VPN فقط لتنظيم القناة بين جهاز التوجيه المصغر للوالدين وخادم "جانب السرير" المنزلي ، والذي يعمل في الوقت نفسه كجهاز توجيه.

بعد فترة قصيرة ، تمت إضافة Keenetic إلى هذه الشركة من جهازين.
ولكن بمجرد البدء ، اتضح أنه من الصعب إيقافه ، وسرعان ما ظهرت الهواتف والكمبيوتر المحمول على الرسم التخطيطي ، الذين أرادوا الاختباء من العين الإعلانية الواضحة لـ MT_Free وشبكات WiFi غير المشفرة الأخرى.

ثم أصبح ILV المحبوب في النهاية أقوى Banhammer ، الذي وقع بشكل لا يصدق في حب التأرجح علنا ​​في جميع الاتجاهات ، ومن أجل تحييد قلقه لمجرد البشر ، كان عليه أن يدعم قطاع تكنولوجيا المعلومات الأجنبي للحصول على VPS في الخارج.
بالإضافة إلى ذلك ، مواطنة معينة تشبه شابوكلياك ، تتجول في كل مكان مع شبكتها من خلال الحزمة ، وربما تعتقد أن "من يساعد الناس ، يضيع الوقت. لا يمكنك أن تصبح مشهورًا بالأعمال الصالحة "، أردت أن ألق نظرة خاطفة على حركة مرور شخص آخر وأخذها بالقلم الرصاص. سيكون علينا أيضًا الدفاع عن أنفسنا ضد مثل هذا الحب غير المرغوب فيه والشبكة الافتراضية الخاصة في هذه الحالة بالضبط التي طلبها الطبيب.

لتلخيص ملخص قصير. كان من الضروري إيجاد حل يمكنه بشكل مثالي إغلاق العديد من المهام في وقت واحد:

  • الترابط بين موجهات Linux
  • بناء نفق بين لينكس والأسرة الحركية
  • امنح حق الوصول إلى الموارد المنزلية والإنترنت للأجهزة القابلة للارتداء (الهواتف وأجهزة الكمبيوتر المحمولة) من الشبكات غير الموثوق بها
  • إنشاء نفق مشفر بأمان إلى VPS البعيد

لا تنس مبدأ KISS الرائع - حافظ على البساطة ، يا غبي. كلما شاركنا في مكونات أقل ، أصبح من الأسهل تكوين كل منها - كلما كانت أكثر موثوقية.

نظرة عامة على الحلول الموجودة


استعرض بإيجاز ما هو الآن: جد

PPTP

لينين من جميع البروتوكولات. توفي "العفن المتحلل والعسل الزيزفون".

L2TP

هل يستخدم هذا أحد غير مزود واحد؟ مشروع

Wireguard

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

OpenVPN

:

  • دعم منصات متعددة - Windows و Linux و OpenWRT ومشتقاته ، Android
  • تشفير قوي ودعم الشهادة.
  • مرونة التخصيص.

والسلبيات:

  • اعمل بالكامل في مساحة المستخدم.
  • دعم محدود من أجهزة التوجيه المنزلية - krenenko-kosenko على Mikrotik (دون الانتقاص من المزايا الأخرى للغدد) والطبيعي في OpenWRT.
  • صعوبات في إعداد برامج الأجهزة المحمولة: تحتاج إلى تنزيل أو إنشاء المثبت الخاص بك ونسخ التهيئة في مكان ما.
  • إذا كان هناك العديد من الأنفاق ، فإن الرقصات تنتظر مع تحرير وحدات systemd على الخادم.

OpenConnect (تطبيق مفتوح المصدر لبروتوكول Cisco Anyconnect)
هو حل مثير للاهتمام للغاية ، وهو للأسف قليل من المعلومات.

الإيجابيات:

  • يعد الدعم الواسع نسبيًا للعديد من الأنظمة الأساسية - Windows و Android و Mac استنادًا إلى تطبيق Cisco Anyconnect الأصلي من المتجر - خيارًا مثاليًا لتوفير الوصول إلى الشبكة الداخلية للأجهزة القابلة للارتداء.
  • تشفير قوي ، دعم الشهادة ، اتصال 2FA
  • البروتوكول نفسه قائم على TLS بالكامل (على عكس OpenVPN ، الذي يمكن اكتشافه بسهولة على المنفذ 443). بالإضافة إلى TLS ، يتم أيضًا دعم DTLS - خلال الجلسة المحددة ، يمكن للعميل التبديل إلى إرسال البيانات عبر UDP والعكس صحيح.
  • تعايش ممتاز على منفذ واحد لكل من VPN وخادم ويب كامل باستخدام sniproxy.
  • إعداد سهل لكل من الخادم والعملاء.

هنا أيضًا ، لم تكن بدون سلبيات:

  • اعمل بالكامل في مساحة المستخدم.
  • إن TCP أعلى TCP هي فكرة سيئة.
  • لا يوجد دعم من معدات العملاء.
  • تعقيد تثبيت الأنفاق بين لينكسين: ممكن نظريًا وعمليًا - من الأفضل قضاء بعض الوقت على شيء أكثر فائدة.
  • إذا كان هناك العديد من الأنفاق ، فإن الرقصات مع العديد من التكوينات ووحدات تحرير النظام تنتظر.

قد يبدو وكأنه طريق مسدود ، ولكن بعد إلقاء نظرة فاحصة وقضاء بعض الوقت في الدراسة ، أدركت أن IPSec القائم على IKEv2 قادر على استبدال كل شيء آخر. إيجابيات

IKEv2 IPSEC

:

  • مع ظهور IKEv2 ، أصبح تكوين البروتوكول نفسه أسهل ، مقارنة بالإصدار السابق ، ولكن على حساب فقدان التوافق العكسي.
  • بفضل التوحيد القياسي ، يتم توفير العمل في أي مكان وعلى أي شيء - يمكن الحفاظ على القائمة إلى أجل غير مسمى. Linux ، Mikrotik (في أحدث إصدارات RouterOS) ، OpenWRT ، Android ، iPhone. يحتوي Windows أيضًا على دعم أصلي بدءًا من Windows 7.
  • سرعة عالية: معالجة حركة المرور بالكامل في مساحة النواة. جزء مساحة المستخدم مطلوب فقط لإعداد معلمات الاتصال ومراقبة صحة القناة.
  • القدرة على استخدام العديد من طرق المصادقة: باستخدام كل من PSK والشهادات ، وفي أي مجموعة.
  • العديد من أوضاع التشغيل: النفق والنقل. كيف تختلف يمكن قراءتها بما في ذلك على حبري.
  • إعدادات غير متطلبة للعقد المتوسطة: إذا كانت هناك مشاكل ناجمة عن NAT في الإصدار الأول من IKE ، فإن IKEv2 يحتوي على آليات مدمجة للتغلب على NAT والتجزئة الأصلية لرسائل IKE ، مما يسمح لك بإنشاء اتصال على القنوات باستخدام منحنى MTU. واستشرافا للمستقبل ، سأقول أنني لم أواجه في الواقع شبكة WiFi ، حيث يمكن للعميل إنشاء اتصال.

ومع ذلك ، فإن السلبيات تحتوي أيضًا على:

  • تحتاج إلى قضاء بعض الوقت في الدراسة وفهم كيفية عملها.
  • ميزة يمكن أن تخلط مبتدئ: IPSec ، على عكس حلول VPN التقليدية ، لا تنشئ واجهات شبكة. يتم تعيين سياسات معالجة حركة المرور فقط ، ويتم حل كل شيء آخر عن طريق جدار الحماية.

قبل متابعة الإعداد ، نفترض أن القارئ بالفعل على دراية بالمفاهيم والمصطلحات الأساسية. لمساعدة المبتدئين ، يمكنك التوصية بمقالة من Wikipedia و Habr نفسه ، والتي تحتوي بالفعل على مقالات مفيدة ومثيرة للاهتمام حول هذا الموضوع.

الشروع في الإعداد


بعد البت في القرار ، ننتقل إلى التكوين. يحتوي مخطط الشبكة في حالتي على الشكل التالي (تمت إزالته تحت المفسد)

رسم تخطيطي للشبكة

ipsecgw.example.com هو الخادم الرئيسي الذي يعد مركز الشبكة. IP الخارجي 1.1.1.1. شبكة داخلية 10.0.0.0/23 وعنوان آخر 10.255.255.1/30 لإعداد جلسة BGP خاصة مع VPS ؛
ماما هو موجه لينكس مبني على شبكة صغيرة صامتة مثبتة من قبل الوالدين. يصدر ISP عنوان IP ديناميكي. الشبكة الداخلية 10.0.3.0/24 ؛
keenetic - موجه حركي مع تثبيت IPSec. يصدر ISP عنوان IP ديناميكي. الشبكة الداخلية 10.0.4.0/24 ؛
محاربو الطرق - أجهزة محمولة متصلة من شبكات غير موثوقة. يتم إصدار العناوين للعملاء بشكل ديناميكي عند الاتصال من التجمع الداخلي (10.1.1.0/24) ؛
rkn.example.com- VPS خارج نطاق اختصاص ILV محترم. IP الخارجي - 5.5.5.5 ، العنوان الداخلي 10.255.255.2/30 لإعداد جلسة BGP خاصة.

الخطوة الأولى. من البسيط إلى المعقد: الأنفاق باستخدام المفاتيح المشتركة مسبقًا (PSK)


نقوم بتثبيت الحزم الضرورية على كل من علب Linux:

sudo yum install strongswan

على كلا المضيفين ، افتح المنافذ 500 / UDP و 4500 / UDP واسمح بمرور بروتوكول ESP.
قم بتحرير الملف /etc/strongswan/ipsec.secrects (على جانب المضيف ipsecgw.example.com) وأضف السطر التالي:

mama@router.home.local: PSK "Very strong PSK"

على الجانب الثاني بالمثل:

root@root.mama.local: PSK "Very strong PSK"

في هذه الحالة ، المعرّف هو عنوان بريد إلكتروني وهمي. يمكن العثور على مزيد من المعلومات في الويكي الرسمي .

حفظ الأسرار ، والمضي قدما.

على مضيف ipsecgw.example.com ، قم بتحرير الملف /etc/strongswan/ipsec.conf:

config setup //   charon
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0" //  
conn %default //    
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2 //      - IKEv2
    dpdaction = hold
    dpddelay = 5s // 5   DPD (Dead Peer Detection)   
    mobike = yes // Mobile IKE -     IP    
conn mama //  
    left = %defaultroute //Left -  .  %defaultroute       IKE- ,    default route
    right = %any //     IP-
    authby = psk //   -   
    leftid = mama@router.home.local // ID,   ipsec.secrets
    rightid = root@router.mama.local //ID  
    leftsubnet = 10.0.0.0/23,10.1.1.0/24 
    rightsubnet = 10.0.3.0/24
    type = tunnel 
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519! 
    auto = add //  charon        

وبالمثل ، نقوم بتحرير الأقران عن بعد /etc/strongswan/ipsec.conf:

config setup
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
conn %default
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2
    dpdaction = restart
    dpddelay = 5s
    mobike = yes
conn mama
    left = %defaultroute
    right = ipsecgw.example.com
    authby = psk
    leftid = root@router.mama.local
    rightid = mama@router.home.local
    leftsubnet = 10.0.3.0/24
    rightsubnet = 10.0.0.0/23,10.1.1.0/24
    type = tunnel
    ike = aes128gcm16-sha384-x25519!
    esp = aes128gcm16-sha384-x25519!
    auto = route

إذا قارنت التكوينات ، يمكنك أن ترى أنها متطابقة تقريبًا ، فقط يتم تبادل تعريفات النظراء.

التوجيه التلقائي = توجيه يؤدي charon إلى تعيين فخ لحركة المرور التي تقع في توجيهات right / Rightsubnet (محددات حركة المرور). سيبدأ تنسيق معلمات النفق وتبادل المفاتيح فور ظهور حركة المرور التي تقع تحت الظروف المحددة.

على خادم ipsecgw.example.com في إعدادات جدار الحماية ، نحظر التنكر لشبكة 10.0.3.0/24. السماح بإعادة توجيه الحزم بين 10.0.0.0/23 و 10.0.3.0/24 والعكس. على المضيف البعيد ، نقوم بتنفيذ إعدادات مماثلة عن طريق تعطيل التنكر لشبكة 10.0.0.0/23 وإعداد إعادة التوجيه.

نعيد تشغيل strongswan على كلا الخادمين ونحاول تنفيذ الأمر ping على العقدة المركزية:

sudo systemctl restart strongswan
ping 10.0.0.1


تأكد من أن كل شيء يعمل:
sudo strongswan status
Security Associations (1 up, 0 connecting):
        mama[53]: ESTABLISHED 84 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{141}:  INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c4eb45fe_i ca5ec6ca_o
        mama{141}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24


سيكون من المفيد أيضًا التأكد من تعيين المعلمة make_before_break على "نعم" في ملف /etc/strongswan/strongswan.d/charon.conf لدى جميع الأقران. في هذه الحالة ، لن يحذف برنامج charon الذي يخدم بروتوكول IKEv2 اقتران الأمان الحالي أثناء إجراء تغيير المفتاح ، ولكنه سينشئ واحدًا جديدًا أولاً.

الخطوة الثانية ظهور الحركية


كانت المفاجأة السارة هي IPSec VPN المدمج في البرنامج الثابت الرسمي Keenetic. لتنشيطه ، ما عليك سوى الانتقال إلى إعدادات مكونات KeeneticOS وإضافة حزمة IPSec VPN .

نجهز الإعدادات على العقدة المركزية لهذا:

تحرير /etc/strongswan/ipsec.secrects وإضافة PSK للنظير الجديد:

keenetic@router.home.local: PSK "Keenetic+PSK"

تحرير /etc/strongswan/ipsec.conf وإضافة اتصال آخر إلى النهاية:

conn keenetic
    left = %defaultroute
    right = %any
    authby = psk
    leftid = keenetic@router.home.local
    rightid = root@router.keenetic.local
    leftsubnet = 10.0.0.0/23
    rightsubnet = 10.0.4.0/24
    type = tunnel
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
    auto = add

على الجانب الحركي ، يتم التهيئة في WebUI على طول المسار: الإنترنت -> اتصالات ->
اتصالات أخرى
. إنه بسيط للغاية
(3 صور)






إذا كنت تخطط لقيادة كميات كبيرة من حركة المرور عبر النفق ، فيمكنك محاولة تمكين تسريع الأجهزة ، والذي تدعمه العديد من النماذج. ممكّن بواسطة أمر أجهزة محرك التشفير في CLI. لتعطيل عمليات التشفير والتجزئة ومعالجتها باستخدام تعليمات وحدة المعالجة المركزية للأغراض العامة - برنامج محرك التشفير

بعد حفظ الإعدادات ، نقوم باستعادة القوي ونترك Keenetic يفكر لمدة نصف دقيقة. ثم نرى في المحطة اتصال ناجح:

كل شيء يعمل:
sudo strongswan status
Security Associations (2 up, 0 connecting):
    keenetic[57]: ESTABLISHED 39 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{146}:  INSTALLED, TUNNEL, reqid 29, ESP SPIs: ca8f556e_i ca11848a_o
    keenetic{146}:   10.0.0.0/23 === 10.0.4.0/24
        mama[53]: ESTABLISHED 2 hours ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{145}:  INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c5dc78db_i c7baafd2_o
        mama{145}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24


الخطوة الثالثة حماية الأجهزة المحمولة


بعد قراءة مجموعة من الكتيبات ومجموعة من المقالات ، تقرر التوقف عند مجموعة من شهادة مجانية من Let's Encrypt لمصادقة الخادم والتفويض الكلاسيكي عن طريق تسجيل الدخول وكلمة المرور للعملاء. وبالتالي ، نتخلص من الحاجة إلى الحفاظ على البنية التحتية للمفاتيح العمومية الخاصة بنا ، ومراقبة انتهاء صلاحية المفاتيح وإجراء إيماءات غير ضرورية مع الأجهزة المحمولة عن طريق تثبيت الشهادات الموقعة ذاتيًا في القائمة الموثوقة.

قم بتثبيت الحزم المفقودة:

sudo yum install epel-release
sudo yum install certbot

نحصل على الشهادة المستقلة (لا تنس أن تفتح 80 / tcp في إعدادات iptables أولاً):

sudo certbot certonly --standalone -d ipsecgw.example.com

بعد انتهاء سيرتبوت من عملها ، يجب أن نعلم سترونجسوان لرؤية شهادتنا:

  • في الدليل /etc/strongswan/ipsec.d/cacerts أنشئ رابطين رمزيين: أحدهما إلى المتجر الجذري للشهادات الموثوق بها في / etc / pki / tls / certs ؛ وثانية باسم ca.pem تشير إلى /etc/letsencrypt/live/ipsecgw.example.com/chain.pem
  • يتم أيضًا إنشاء ارتباطين رمزيين في دليل /etc/strongswan/ipsec.d/certs: يشير الأول ، الذي يحمل اسم Certificate.pem ، إلى الملف /etc/letsencrypt/live/ipsecgw.example.com/cert.pem. والثاني ، يدعى fullchain.pem ، ويرتبط بـ /etc/letsencrypt/live/ipsecgw.example.com/fullchain.pem
  • في الدليل /etc/strongswan/ipsec.d/private ، ضع الرابط الرمزي key.pem الذي يشير إلى المفتاح الخاص الذي تم إنشاؤه بواسطة certbot والوقوف على المسار /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem

أضف المصادقة عبر RSA إلى ipsec.secrets ومجموعة من تسجيلات الدخول / كلمات المرور للمستخدمين الجدد:

ipsecgw.example.com     : RSA key.pem
username phone          : EAP "Q1rkz*qt"
username notebook       : EAP "Zr!s1LBz"

نعيد تشغيل Strongswan وعند استدعاء قوائم sudo strongswan يجب أن نرى معلومات الشهادة:

List of X.509 End Entity Certificates

  subject:  "CN=ipsecgw.example.com"
  issuer:   "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
  validity:  not before May 23 19:36:52 2020, ok
             not after  Aug 21 19:36:52 2020, ok (expires in 87 days)
  serial:    04:c7:70:9c:a8:ce:57:cc:bf:6f:cb:fb:d3:a9:cf:06:b0:a8
  altNames:  ipsecgw.example.com
  flags:     serverAuth clientAuth
  OCSP URIs: http://ocsp.int-x3.letsencrypt.org
  certificatePolicies:
             2.23.140.1.2.1
             1.3.6.1.4.1.44947.1.1.1
             CPS: http://cps.letsencrypt.org

ثم نصف الاتصال الجديد في ipsec.conf :

conn remote-access
    dpddelay = 30s //   DPD ,     
    left = %defaultroute
    leftid = "CN=ipsecgw.example.com"
    leftcert = fullchain.pem //         
    leftsendcert = always
    leftsubnet = 0.0.0.0/0 //      
    right = %any
    rightid = %any
    rightauth = eap-mschapv2 // ,  EAP-MSCHAP2
    rightsendcert = never
    eap_identity = %identity 
    rightsourceip = 10.1.1.0/24 //Strongswan       
    rightdns = 10.0.0.1,10.0.0.3 //   DNS
    type = tunnel
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
    auto = add //      
    dpdaction = restart // ,      DPD

لا تنس تحرير الملف / etc / sysconfig / certbot للإشارة إلى أننا سنقوم أيضًا بتحديث الشهادة على أنها قائمة بذاتها ، مع إضافة CERTBOT_ARGS = "- مستقل" إليها.

أيضًا ، لا تنس تشغيل موقت certbot-تجديد.timer وتعيين الخطاف لإعادة تشغيل Strongswan في حالة إصدار شهادة جديدة. للقيام بذلك ، إما أن تضع نص bash بسيطًا في / etc / allowencrypt / تجديد التجديد / النشر / ، أو قم بتحرير ملف / etc / sysconfig / certbot مرة أخرى.

نعيد تشغيل Strongswan ، ونقوم بتشغيل التنكر لشبكة 10.1.1.0/24 في iptables ونستمر في تكوين الأجهزة المحمولة.

ذكري المظهر


قم بتثبيت تطبيق Strongswan من Google Play .

أطلقنا وخلق جديد

الملف الشخصي


نحن نحفظ الملف الشخصي ، ونتصل ، وبعد ثانية ، لا داعي للقلق بشأن قدرة شخص ما على التجسس علينا.

نحن نفحص:
sudo strongswan statusall
Security Associations (3 up, 0 connecting):
remote-access[109]: ESTABLISHED 2 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{269}:  INSTALLED, TUNNEL, reqid 55, ESP in UDP SPIs: c706edd1_i e5c12f1d_o
remote-access{269}:   0.0.0.0/0 ::/0 === 10.1.1.1/32
        mama[101]: ESTABLISHED 34 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{265}:  INSTALLED, TUNNEL, reqid 53, ESP in UDP SPIs: c8c83342_i c51309db_o
        mama{265}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
    keenetic[99]: ESTABLISHED 36 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{263}:  INSTALLED, TUNNEL, reqid 52, ESP SPIs: c3308f33_i c929d6f1_o
    keenetic{263}:   10.0.0.0/23 === 10.0.4.0/24


شبابيك


فوجئت Windows من الإصدارات الحالية سارة. تتم جميع إعدادات VPN الجديدة عن طريق استدعاء cmdlets PowerShell cmdlets:

Add-VpnConnection -Name "IKEv2" -ServerAddress ipsecgw.example.com -TunnelType "IKEv2"
Set-VpnConnectionIPsecConfiguration -ConnectionName "IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -DHGroup Group14 -PassThru -Force

وهناك شيء آخر ، إذا تم تكوين Strongswan لإصدار عناوين IPv6 للعملاء (نعم ، يمكنه القيام بذلك أيضًا):

Add-VpnConnectionRoute -ConnectionName "IKEv2" -DestinationPrefix "2000::/3"

الجزء الرابع ، النهائي. قطعنا نافذة إلى أوروبا


بعد أن رأيت بذرة المزود "تم حظر الموقع بقرار الكعب الأيسر للنائب الخامس للمدعي العام لقرية ترودوفي موزولي من مقاطعة بوغوزابييت" ، ظهر VPS صغير غير واضح (مع اسم المجال الذي يبدو جيدًا rkn.example.com) على بعد ألف كيلومتر من القرود التي ترغب في التلويح بحاجز للحجب وحجب شبكات الحجم. / 16 مرة. وكان الغزل على VPS الصغير هذا إنشاءًا رائعًا لزملاء من NIC.CZ يسمى BIRD. توفي طائر الإصدار الأول باستمرار في حالة من الذعر من نشاط القرود بالهراوات ، الذين حظروا ما يقرب من 4 ٪ من الإنترنت في ذروة نشاط المخاض ، تاركين التفكير العميق أثناء إعادة التكوين ، لذلك تم تحديثه إلى الإصدار 2.0.7. إذا كان القراء مهتمين ، فسأنشر مقالًا عن الانتقال من BIRD إلى BIRD2 ، والذي تغير فيه تنسيق التكوين بشكل كبير ،لكن الإصدار الجديد أصبح أسرع بكثير ولا توجد مشاكل في إعادة التشكيل بعدد كبير من المسارات. وبما أننا نستخدم بروتوكول التوجيه الديناميكي ، فيجب أن تكون هناك واجهة شبكة تحتاج من خلالها إلى توجيه حركة المرور. بشكل افتراضي ، لا يقوم IPSec بإنشاء واجهات ، ولكن نظرًا لمرونته ، يمكننا استخدام أنفاق GRE الكلاسيكية ، والتي سنحميها في المستقبل. كمكافأة ، سيقوم مضيفو ipsecgw.example.com و rkn.example.com بمصادقة بعضهما البعض باستخدام شهادات التجديد الذاتي Lets Encrypt. لا يوجد PSK ، فقط الشهادات ، المتشددين فقط ، ليس هناك الكثير من الأمان.بشكل افتراضي ، لا يقوم IPSec بإنشاء واجهات ، ولكن نظرًا لمرونته ، يمكننا استخدام أنفاق GRE الكلاسيكية ، والتي سنحميها في المستقبل. كمكافأة ، سيقوم مضيفو ipsecgw.example.com و rkn.example.com بمصادقة بعضهما البعض باستخدام شهادات التجديد الذاتي Lets Encrypt. لا يوجد PSK ، فقط الشهادات ، المتشددين فقط ، ليس هناك الكثير من الأمان.بشكل افتراضي ، لا يقوم IPSec بإنشاء واجهات ، ولكن نظرًا لمرونته ، يمكننا استخدام أنفاق GRE الكلاسيكية ، والتي سنحميها في المستقبل. كمكافأة ، سيقوم مضيفو ipsecgw.example.com و rkn.example.com بمصادقة بعضهما البعض باستخدام شهادات التجديد الذاتي Lets Encrypt. لا يوجد PSK ، فقط الشهادات ، المتشددين فقط ، ليس هناك الكثير من الأمان.

نعتقد أن VPS جاهز ، وقد تم تثبيت Strongswan و Certbot بالفعل.

على مضيف ipsecgw.example.com (عنوان IP الخاص به هو 1.1.1.1) ، نصف واجهة gif0 الجديدة:
sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="1.1.1.1"
PEER_OUTER_IPADDR="5.5.5.5"
MY_INNER_IPADDR="10.255.255.1/30"
PEER_INNER_IPADDR="10.255.255.2/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"

معكوسة على المضيف vps.example.com (عنوان IP هو 5.5.5.5):

sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="5.5.5.5"
PEER_OUTER_IPADDR="1.1.1.1"
MY_INNER_IPADDR="10.255.255.2/30"
PEER_INNER_IPADDR="10.255.255.1/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"

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

الطبخ VPS


أولاً ، نحصل على شهادة أخرى لاسم النطاق rkn.example.com. قم بإنشاء روابط رمزية في /etc/strongswan/ipsec.d كما هو موضح في القسم السابق.

قم بتعديل ipsec.secrets بإضافة سطر واحد إليها:

rkn.example.com     : RSA key.pem

تحرير ipsec.conf:

config setup
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
    strictcrlpolicy = yes
conn %default
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2
    dpdaction = restart
    dpddelay = 5s
    mobike = yes
conn rkn
    left = %defaultroute
    right = ipsecgw.example.com
    authby = pubkey
    leftcert = fullchain.pem
    leftsendcert = always
    leftauth = pubkey
    rightauth = pubkey
    leftid = "CN=rkn.example.com"
    rightid = "CN=ipsecgw.example.com"
    rightrsasigkey = /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
    leftsubnet = %dynamic
    rightsubnet = %dynamic
    type = transport
    ike = aes256gcm16-sha384-x25519!
    esp = aes256gcm16-sha384-x25519!
    auto = route

على جانب المضيف ، تمت إضافة ipsecgw.example.com أيضًا إلى ipsec.conf في قسم الإعداد المعلمة الصارمة = نعم ، والتي تتضمن فحص CRL الصارم. ووصف اتصال آخر:

conn rkn
    left = %defaultroute
    right = rkn.example.com
    leftcert = fullchain.pem
    leftsendcert = always
    leftauth = pubkey
    rightauth = pubkey
    rightrsasigkey = /etc/strongswan/ipsec.d/certs/rkn.exapmle.com.pem
    leftid = "CN=ipsecgw.example.com"
    rightid = "CN=rkn.example.com"
    leftsubnet = %dynamic
    rightsubnet = %dynamic
    type = transport
    ike = aes256gcm16-sha384-x25519!
    esp = aes256gcm16-sha384-x25519!
    auto = route
    dpdaction = restart

يتم عكس Conf Confs تقريبًا. يمكن للقارئ اليقظ بالفعل الانتباه إلى نقطتين:

  • left / Rightsubnet =٪ dynamic - يوجه Strongswan إلى تطبيق السياسات على جميع أنواع الزيارات بين أقرانهم
  • rightrsasigkey. IKE SA IKE AUTH ERROR , Strongswan RSA- . openssl. (ipsecgw RKN) sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > ~/ipsecgw.example.com.pem sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > ~/rkn.example.com.pem, scp ,

لا تنسَ تكوين شهادات جدار الحماية والتجديد التلقائي. بعد إعادة تشغيل Strongswan على كلا الخادمين ، ابدأ تنفيذ الأمر ping على الجانب البعيد من نفق GRE وشاهد اتصال ناجح. على VPS (rkn):

sudo strongswan status
Routed Connections:
         rkn{1}:  ROUTED, TRANSPORT, reqid 1
         rkn{1}:   5.5.5.5/32 === 1.1.1.1/32
Security Associations (1 up, 0 connecting):
         rkn[33]: ESTABLISHED 79 minutes ago, 5.5.5.5[CN=rkn.example.com]...1.1.1.1[CN=ipsecgw.example.com]
         rkn{83}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cb4bc3bb_i c4c35a5a_o
         rkn{83}:   5.5.5.5/32 === 1.1.1.1/32


وعلى الجانب المضيف ipsecgw
تحت المفسد
Routed Connections:
         rkn{1}:  ROUTED, TRANSPORT, reqid 1
         rkn{1}:   1.1.1.1/32 === 5.5.5.5/32
Security Associations (4 up, 0 connecting):
remote-access[10]: ESTABLISHED 5 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{12}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c7a31be1_i a231904e_o
remote-access{12}:   0.0.0.0/0 === 10.1.1.1/32
    keenetic[8]: ESTABLISHED 22 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{11}:  INSTALLED, TUNNEL, reqid 6, ESP SPIs: cfc1b329_i c01e1b6e_o
    keenetic{11}:   10.0.0.0/23 === 10.0.4.0/24
        mama[4]: ESTABLISHED 83 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{8}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c4a5451a_i ca67c223_o
        mama{8}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
         rkn[3]: ESTABLISHED 83 minutes ago, 1.1.1.1[CN=ipsecgw.example.com]...5.5.5.5[CN=rkn.example.com]
         rkn{7}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c4c35a5a_i cb4bc3bb_o
         rkn{7}:   1.1.1.1/32 === 5.5.5.5/32


يتم تثبيت النفق ، تذهب الأصوات ، في tcpdump ، من الواضح أن ESP ينتقل فقط بين المضيفين. يبدو من الممكن أن نفرح. ولكن لا يمكنك الاسترخاء دون التحقق من كل شيء حتى النهاية. نحن نحاول إعادة إصدار شهادة VPS و ...

طاه ، كل شيء مكسور


نبدأ في فهم وإيجاد ميزة غير سارة في Let's Encrypt ، وهي جميلة في كل شيء آخر - مع أي إعادة إصدار للشهادة ، يتغير المفتاح الخاص المرتبط بها أيضًا. المفتاح الخاص تغير - والجمهور تغير. للوهلة الأولى ، فإن الوضع ميئوس منه بالنسبة لنا: حتى إذا تمكنا من استخراج المفتاح العام بسهولة أثناء إعادة إصدار الشهادة باستخدام الخطاف في سيرتبوت وتمريره إلى الجانب البعيد عبر SSH ، فليس من الواضح كيفية جعل Strongswan البعيد يعيد قراءته. ولكن المساعدة أتت من حيث لم ينتظروا - يستطيع systemd مراقبة التغييرات في نظام الملفات وتشغيل الخدمات المرتبطة بالحدث. سوف نستفيد من هذا.

سننشئ مستخدم خدمة Keywatcher على كل مضيف له الحقوق الأكثر تقييدًا ، وننشئ مفاتيح SSH لكل منهم ، ونقوم بتبادلها بين المضيفين.

على مضيف ipsecgw.example.com ، أنشئ دليل / opt / ipsec-pubkey الذي نضع فيه سكريبتَين.

sudo vi /opt/ipsec-pubkey/pubkey-copy.sh

#!/bin/sh
if [ ! -f /home/keywatcher/ipsecgw.example.com.pem ]; then
  /usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > /home/keywatcher/ipsecgw.example.com.pem;
  /usr/bin/chown keywatcher:keywatcher /home/keywatcher/ipsecgw.example.com.pem;
  /usr/bin/chmod 0600 /home/keywatcher/ipsecgw.example.com.pem;
  sudo -u keywatcher /usr/bin/scp /home/keywatcher/ipsecgw.example.com.pem rkn.example.com:/home/keywatcher/ipsecgw.example.com.pem;
  status=$?;
  if [ $status -eq 0 ]; then
    rm -f /home/keywatcher/ipsecgw.example.com.pem;
    logger "Public key ipsecgw.example.com.pem has been successfully uploaded to remote host";
  else
    logger "Public key ipsecgw.example.com.pem has not been uploaded to remote host due to error";
  fi
  else
    logger "Public key ipsecgw.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0

sudo vi /opt/ipsec-pubkey/key-updater.sh

#!/bin/sh
/usr/bin/cp /home/keywatcher/rkn.example.com.pem /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
logger "Public key of server rkn.example.com has been updated, restarting strongswan daemon to re-read it"
/usr/bin/systemctl restart strongswan
exit 0

على VPS (المضيف rkn.example.com) ، نقوم بالمثل بإنشاء دليل بنفس الاسم ، حيث نقوم أيضًا بإنشاء نصوص مشابهة ، مع تغيير اسم المفتاح فقط. كود ، حتى لا تشوش المادة ، تحت

المفسد
sudo vi /opt/ipsec-pubkey/pubkey-copy.sh
#!/bin/sh
if [ ! -f /home/keywatcher/rkn.example.com.pem ]; then
  /usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > /home/keywatcher/rkn.example.com.pem;
  /usr/bin/chown keywatcher:keywatcher /home/keywatcher/rkn.example.com.pem;
  /usr/bin/chmod 0600 /home/keywatcher/rkn.example.com.pem;
  sudo -u keywatcher /usr/bin/scp /home/keywatcher/rkn.example.com.pem ipsecgw.example.com:/home/keywatcher/rkn.example.com.pem;
  status=$?;
  if [ $status -eq 0 ]; then
    rm -f /home/keywatcher/rkn.example.com.pem;
    logger "Public key rkn.example.com.pem has been successfully uploaded to remote host";
  else
    logger "Public key rkn.example.com.pem has not been uploaded to remote host";
  fi
  else
    logger "Public key rkn.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0

sudo vi /opt/ipsec-pubkey/key-updater.sh


#!/bin/bash
/usr/bin/cp /home/keywatcher/ipsecgw.example.com.pem /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem;
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
logger "Public key of server ipsecgw.example.com has been updated, restarting connection"
/usr/bin/systemctl restart strongswan
exit 0


مطلوب البرنامج النصي pubkey-copy.sh لاستخراج الجزء العام من المفتاح ونسخه إلى المضيف البعيد عند إصدار شهادة جديدة. للقيام بذلك ، في / etc / letencrypt / تجديد التجديدات / نشر الدليل على كلا الخادمين ، قم بإنشاء نص مصغر آخر:


#!/bin/sh
/opt/ipsec-pubkey/pubkey-copy.sh > /dev/null 2>&1
/usr/bin/systemctl restart strongswan
exit 0

يتم حل نصف المشكلة ، وإعادة إصدار الشهادات ، واستخراج المفاتيح العامة ونسخها بين الخوادم ، وقد حان الوقت لنظام systemd مع وحدات المسار الخاصة به.

على خادم ipsecgw.example.com في دليل / etc / systemd / system ، أنشئ ملف keyupdater.path

[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/rkn.example.com.pem
[Install]
WantedBy=multi-user.target

وبالمثل على مضيف VPS:

[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/ipsecgw.example.com.pem
[Install]
WantedBy=multi-user.target

وأخيرًا ، على كل خادم نقوم بإنشاء خدمة مرتبطة بهذه الوحدة ، والتي سيتم إطلاقها عند تحقق الشرط (PathChanged) - تغيير الملف وإغلاقه بعد التسجيل. نقوم بإنشاء الملفات /etc/systemd/system/keyupdater.service ونكتب:

[Unit]
Description= Starts the IPSec key updating script
Documentation= man:systemd.service
[Service]
Type=oneshot
ExecStart=/opt/ipsec-pubkey/key-updater.sh
[Install]
WantedBy=multi-user.target

لا تنسى إعادة قراءة تكوينات systemd مع sudo systemctl daemon-reload وتعيين التشغيل التلقائي لوحدات المسار عبر sudo systemctl تمكين keyupdater.path && sudo systemctl start keyupdater.

بمجرد أن يكتب المضيف البعيد الملف الذي يحتوي على المفتاح العام إلى الدليل الرئيسي لمستخدم مراقب المفاتيح ويتم إغلاق واصف الملف ، سيقوم systemd تلقائيًا بتشغيل الخدمة المقابلة ، والتي ستنسخ المفتاح إلى الموقع المطلوب وإعادة تشغيل Strongswan. سيتم تثبيت النفق باستخدام المفتاح العام الصحيح للجانب الثاني.

يمكنك الزفير والاستمتاع بالنتيجة.

بدلا من الاستنتاج


كما رأينا للتو الجحيم أمن بروتوكول الإنترنت ليس كما مخيفة كما رسمها. كل ما تم وصفه هو تكوين كامل التشغيل قيد الاستخدام حاليًا. حتى بدون الكثير من المعرفة ، يمكنك تكوين VPN وحماية بياناتك بشكل موثوق.

بالطبع ، ظلت لحظات إعداد iptables خارج نطاق المقالة ، ولكن تبين أن المقالة نفسها كانت ضخمة بالفعل ، وقد كتب الكثير عن iptables.

هناك نقاط في المقالة يمكن تحسينها ، سواء رفض إعادة تشغيل برنامج Strongswan ، وإعادة قراءة التكوينات والشهادات ، ولكن لم أستطع تحقيق ذلك.

ومع ذلك ، لم تكن عمليات إعادة تشغيل البرنامج الخفي مخيفة: فقد واحد أو اثنين من الأصوات بين النظراء ، واستعادة عملاء الجوّال الاتصال بأنفسهم.

آمل أن يدفع الزملاء في التعليقات إلى الحل الصحيح.

All Articles