اصول IPsec VPN: امن‌سازی ترافیک در سراسر شبکه‌های نامورد‌اعتماد

اتصال دو سایت در سراسر اینترنت عمومی ترافیک را در معرض رهگیری قرار می‌دهد مگر اینکه به‌درستی رمزگذاری شود، و IPsec چارچوب استانداردی برای ساخت تونل‌های امن و احراز‌هویت‌شده بین سایت‌ها فراهم می‌کند. این مقاله فرآیند مذاکره دومرحله‌ای IKE را توضیح می‌دهد، تمایز بین پروتکل‌های AH و ESP را پوشش می‌دهد، پیکربندی یک VPN سایت-به-سایت پایه IPsec را مرور می‌کند، و دستورات تأیید ضروری را پوشش می‌دهد.

VPN IPsecIKE فاز ۱ و ۲پیکربندی VPN سایت-به-سایت

~6 دقیقه مطالعه · آخرین به‌روزرسانی ۲۱ شهریور ۱۴۰۵

چرا اتصال سایت-به-سایت به رمزگذاری نیاز دارد

اتصال دو سایت اداره در سراسر اینترنت عمومی، به‌جای یک مدار خصوصی اختصاصی مانند اتصال MPLS که پیش‌تر در این مجموعه بحث شد، یعنی ترافیک در سراسر زیرساختی که توسط اشخاص ثالث کنترل می‌شود و بالقوه توسط هرکسی در طول آن مسیر قابل‌مشاهده است سفر می‌کند. IPsec (IP Security) یک چارچوب استاندارد برای رمزگذاری و احراز‌هویت این ترافیک فراهم می‌کند، که یک اتصال اینترنت عمومی را برای حمل ارتباط حساس سایت-به-سایت امن می‌کند.

فرآیند مذاکره دومرحله‌ای IKE

پیش از اینکه هر داده واقعی‌ای بتواند رمزگذاری و فرستاده شود، دو نقطه پایانی VPN باید ابتدا به‌طور امن پارامترهای رمزنگاری‌ای که استفاده خواهند کرد را مذاکره کنند — این مذاکره توسط IKE (Internet Key Exchange) مدیریت می‌شود، که در دو فاز متمایز رخ می‌دهد.

IKE Phase 1: یک کانال مدیریتی امن و احراز‌هویت‌شده
  بین خود دو همتای VPN برقرار می‌کند -- این کانال
  فقط برای محافظت از خود فرآیند مذاکره استفاده
  می‌شود، هنوز نه ترافیک داده واقعی

IKE Phase 2: از کانال امن برقرارشده در Phase 1
  برای مذاکره پارامترهای واقعی‌ای که ترافیک داده
  واقعی را محافظت خواهند کرد استفاده می‌کند --
  و یک IPsec Security Association (SA) برای
  ترافیک واقعی برقرار می‌کند

پیکربندی IKE Phase 1

Router(config)# crypto isakmp policy 10
Router(config-isakmp)# encryption aes 256
Router(config-isakmp)# hash sha256
Router(config-isakmp)# authentication pre-share
Router(config-isakmp)# group 14
Router(config-isakmp)# lifetime 86400

Router(config)# crypto isakmp key MySharedSecret address 203.0.113.2

-- ISAKMP (Internet Security Association and
-- Key Management Protocol) چارچوبی است که IKE
-- درون آن عمل می‌کند -- پارامترهای سیاست Phase 1
-- باید دقیقاً روی هر دو همتای VPN تطبیق داشته
-- باشند، از نظر اصولی مشابه با تطبیق نیازمندی
-- همسایه که پیش‌تر در این مجموعه درباره شکل‌گیری
-- همسایه OSPF و EIGRP بحث شد

تنظیم group 14 گروه Diffie-Hellman استفاده‌شده برای تبادل کلید اولیه را مشخص می‌کند — یک شماره گروه بالاتر معمولاً امنیت قوی‌تری را به قیمت سربار محاسباتی اضافی در طول خود مذاکره فراهم می‌کند، هرچند این هزینه فقط یک‌بار به‌ازای هر ایجاد تونل پرداخت می‌شود، نه به‌ازای هر بسته.

پیکربندی IKE Phase 2 (مجموعه تبدیل IPsec)

Router(config)# crypto ipsec transform-set MY-TRANSFORM esp-aes 256 esp-sha256-hmac

Router(config)# crypto map VPN-MAP 10 ipsec-isakmp
Router(config-crypto-map)# set peer 203.0.113.2
Router(config-crypto-map)# set transform-set MY-TRANSFORM
Router(config-crypto-map)# match address VPN-TRAFFIC

Router(config)# interface gigabitethernet 0/0
Router(config-if)# crypto map VPN-MAP

خط match address VPN-TRAFFIC به یک لیست دسترسی، که پیش‌تر در این مجموعه بحث شد، ارجاع می‌دهد که دقیقاً مشخص می‌کند کدام ترافیک باید از میان تونل رمزگذاری‌شده فرستاده شود — ترافیک منطبق با این ACL رمزگذاری و از میان VPN فرستاده می‌شود، در حالی که ترافیک منطبق‌نشده با آن به‌طور معمول در حالت غیررمزگذاری‌شده بر اساس جدول مسیریابی استاندارد فوروارد می‌شود.

AH در مقابل ESP: دو پروتکل IPsec

AH (Authentication Header):
  احراز هویت و بررسی یکپارچگی فراهم می‌کند
  (تأیید اینکه داده دستکاری نشده و واقعاً
  از فرستنده ادعاشده آمده)
  رمزگذاری فراهم نمی‌کند -- داده برای هرکسی
  که آن را رهگیری کند خوانا باقی می‌ماند
  به‌ندرت به‌تنهایی در استقرارهای مدرن استفاده می‌شود

ESP (Encapsulating Security Payload):
  هم احراز هویت/یکپارچگی و هم رمزگذاری فراهم
  می‌کند (هم تأیید اینکه داده تغییرنیافته و هم
  محرمانه‌نگه‌داشتن محتوایش از رهگیری)
  پروتکل غالب استفاده‌شده در تقریباً همه
  استقرارهای VPN IPsec مدرن، چون محرمانگی
  تقریباً همیشه مورد نیاز است

از آنجا که ESP به‌تنهایی از قبل هم بررسی یکپارچگی و هم محرمانگی‌ای که بیشتر استقرارها واقعاً نیاز دارند فراهم می‌کند، AH به‌ندرت به‌طور مستقل در عمل پیکربندی می‌شود — پیکربندی transform-set نشان‌داده‌شده در بالا از esp-aes و esp-sha256-hmac استفاده می‌کند، هر دو صراحتاً مبتنی‌بر-ESP، که این ترجیح تقریباً-جهانی را منعکس می‌کند.

حالت Tunnel در مقابل حالت Transport

Tunnel Mode: کل بسته IP اصلی (شامل هدر اصلی‌اش)
  رمزگذاری و کپسوله می‌شود درون یک بسته IP جدید --
  برای VPN های سایت-به-سایت استفاده می‌شود، جایی
  که ترافیک یک شبکه خصوصی کامل نیاز دارد محافظت
  شود همان‌طور که در سراسر اینترنت عمومی عبور می‌کند

Transport Mode: فقط بار محموله بسته اصلی
  رمزگذاری می‌شود، در حالی که هدر IP اصلی
  قابل‌مشاهده باقی می‌ماند -- برای ارتباط
  هاست-به-هاست استفاده می‌شود جایی که هر دو
  نقطه پایانی از قبل آدرس‌های عمومی و
  مسیریابی‌پذیر دارند و فقط خود داده نیاز به
  محافظت دارد

VPN های سایت-به-سایت، رایج‌ترین کاربرد سازمانی IPsec، عملاً همیشه از حالت tunnel استفاده می‌کنند، چون آدرس‌های داخلی خصوصی، که پیش‌تر در این مجموعه درباره آدرس‌دهی IPv4 بحث شد، نیاز دارند کاملاً پنهان و محافظت شوند همان‌طور که ترافیک در سراسر اینترنت عمومی بین سایت‌ها عبور می‌کند.

تأیید وضعیت IKE Phase 1 و Phase 2

Router# show crypto isakmp sa

dst             src             state          conn-id
203.0.113.2     203.0.113.1     QM_IDLE        1001

-- "QM_IDLE" تأیید می‌کند Phase 1 با موفقیت
-- تکمیل شده و کانال مدیریتی پایدار و بی‌کار
-- است، آماده برای پشتیبانی مذاکرات Phase 2
-- در صورت نیاز

Router# show crypto ipsec sa

  local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
  remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
    #pkts encaps: 1204, #pkts encrypt: 1204
    #pkts decaps: 1198, #pkts decrypt: 1198

شمارنده‌های بسته در show crypto ipsec sa تأیید می‌کنند ترافیک واقعاً در هر دو جهت از میان تونل جریان می‌یابد — یک الگوی عیب‌یابی رایج یک SA فاز ۱ در حالت بی‌کار درست اما شمارش صفر بسته در فاز ۲ است، که نشان می‌دهد ترافیک منطبق با ACL ترافیک-جالب پیکربندی‌شده صرفاً واقعاً هرگز فرستاده نشده، به‌جای یک شکست مذاکره رمزنگاری.

تشخیص یک شکست رایج: عدم برقراری هرگز Phase 1

علل رایج وقتی Phase 1 برقرار نمی‌شود:

- پارامترهای سیاست ISAKMP نامنطبق بین همتاها
  (رمزگذاری، هش، گروه DH، یا روش احراز هویت
  همه باید دقیقاً تطبیق داشته باشند)
- کلید pre-shared نامنطبق
- یک فایروال یا دستگاه NAT که پورت UDP 500
  (استفاده‌شده توسط IKE) را در جایی از میان
  مسیر بین دو همتا مسدود می‌کند

چرا VPN های IPsec یک فناوری سازمانی بنیادین باقی می‌مانند

حتی همان‌طور که SD-WAN، که پیش‌تر در این مجموعه بحث شد، به‌طور فزاینده بیشتر این پیچیدگی پیکربندی دستی را خودکار و انتزاعی می‌کند، چارچوب رمزنگاری زیربنایی IPsec همچنان مکانیزم امنیتی واقعی است که زیر بیشتر راه‌حل‌های اتصال سایت-به-سایت مدرن، شامل خود پیاده‌سازی‌های SD-WAN، عمل می‌کند. درک فرآیند مذاکره دومرحله‌ای IKE، تمایز بین AH و ESP، و نحوه خواندن وضعیت association امنیتی فاز ۱ و فاز ۲ دانش بنیادین ضروری‌ای برای عیب‌یابی هر فناوری VPN ساخته‌شده روی این استاندارد به‌طور گسترده مستقر است.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

عیب‌یابی سیستماتیک شبکه: یک روش‌شناسی که همه‌چیز را به هم پیوند می‌دهد

هر پروتکل و فناوری‌ای که در سراسر این مجموعه پوشش داده شد فقط زمانی مفید است که یک مسئله شامل آن واقعاً بتواند تحت فشار دنیای واقعی به‌طور کارآمد تشخیص و رفع شود. این مقاله یک روش‌شناسی عیب‌یابی سیستماتیک ساخته‌شده حول لایه‌های OSI ارائه می‌دهد، اعمالش روی یک مسئله اتصال واقع‌بینانه را مرور می‌کند، و نشان می‌دهد دستورات تأیید خاصی که در سراسر این کل مجموعه پوشش داده شدند چگونه در یک فرآیند تشخیصی ساختاریافته جا می‌گیرند.

ادامه

NETCONF، YANG، و پایتون: پیکربندی برنامه‌ای شبکه در مقیاس

REST API ها و فرمت‌های JSON/YAML که پیش‌تر در این مجموعه پوشش داده شدند یک رویکرد به اتوماسیون شبکه را نشان می‌دهند، اما NETCONF و YANG یک جایگزین ساختاریافته‌تر و مبتنی‌بر-استاندارد فراهم می‌کنند که به‌طور خاص برای پیکربندی دستگاه شبکه ساخته شده. این مقاله توضیح می‌دهد چه چیزی NETCONF را از یک REST API ساده متمایز می‌کند، اینکه مدل‌های YANG چگونه دقیقاً تعریف می‌کنند داده پیکربندی چگونه به‌نظر می‌رسد را پوشش می‌دهد، و استفاده از پایتون برای تعامل برنامه‌ای با دستگاه‌های شبکه را مرور می‌کند.

ادامه

اصول MPLS: توضیح سوئیچینگ برچسب

مسیریابی IP سنتی نیازمند این است که هر روتر در طول یک مسیر یک جستجوی کامل جدول مسیریابی روی هر بسته انجام دهد، اما MPLS رویکردی اساساً متفاوت را با گرفتن آن تصمیم فوروارد‌کردن یک‌بار و متصل‌کردن یک برچسب ساده که هر روتر بعدی می‌تواند به‌جای آن استفاده کند اتخاذ می‌کند. این مقاله مفهوم اصلی سوئیچینگ-برچسب را توضیح می‌دهد، اینکه پروتکل توزیع برچسب چگونه جداول فوروارد‌کردن برچسبی که این را ممکن می‌کنند می‌سازد را مرور می‌کند، و بهره‌های عملی‌ای که MPLS در شبکه‌های ارائه‌دهنده واقعی فراهم می‌کند را پوشش می‌دهد.

ادامه

Route Reflector و Confederation های BGP: مقیاس‌دهی iBGP فراتر از Full Mesh

نیازمندی full-mesh iBGP، که به‌طور مختصر پیش‌تر در این مجموعه ذکر شد، با رشد یک سیستم خودمختار به یک مسئله جدی مقیاس‌دهی تبدیل می‌شود، که نیازمند تعدادی جلسه است که به‌طور درجه‌دوم با تعداد روتر افزایش می‌یابد. این مقاله دقیقاً توضیح می‌دهد چرا full mesh مقیاس‌پذیر نیست، اینکه route reflector ها چگونه این را با شل‌کردن قوانین معمول انتشار-مسیر BGP حل می‌کنند مرور می‌کند، و confederation ها را به‌عنوان یک رویکرد جایگزین که یک AS واحد را به سیستم‌های خودمختار زیرمجموعه کوچک‌تر تقسیم می‌کند پوشش می‌دهد.

ادامه

بررسی عمیق انواع ناحیه OSPF: Stub، Totally Stubby، و NSSA

طراحی OSPF چندناحیه‌ای پایه، که پیش‌تر در این مجموعه پوشش داده شد، از قبل اندازه پایگاه‌داده را با نگه‌داشتن LSA های جزئی نوع ۱ و ۲ محلی به ناحیه خودشان کاهش می‌دهد، اما انواع ناحیه تخصصی OSPF فراتر می‌روند، و به‌طور خاص LSA های خارجی نوع ۵ را هدف قرار می‌دهند. این مقاله انواع LSA که باید برای ساخت هر نوع ناحیه تخصصی سرکوب شوند را توضیح می‌دهد، پیکربندی نواحی stub، totally stubby، و not-so-stubby را مرور می‌کند، و مبادلات خاصی که هر انتخاب طراحی شامل می‌شود را پوشش می‌دهد.

ادامه

دستکاری مسیر BGP: Route Map ها و Community ها برای مهندسی ترافیک

الگوریتم انتخاب بهترین-مسیر پایه BGP، که پیش‌تر در این مجموعه پوشش داده شد، از یک توالی ثابت از ویژگی‌ها پیروی می‌کند، اما شبکه‌های واقعی نیاز دارند به‌طور فعال روی اینکه کدام مسیر انتخاب می‌شود تأثیر بگذارند به‌جای پذیرش منفعلانه نتیجه پیش‌فرض. این مقاله توضیح می‌دهد route map ها چگونه اطلاعات مسیریابی BGP را فیلتر و تغییر می‌دهند، Local Preference و MED را به‌عنوان دو اهرم اصلی برای تأثیرگذاری روی انتخاب مسیر پوشش می‌دهد، و community های BGP را به‌عنوان یک مکانیزم تگ‌گذاری انعطاف‌پذیر برای هماهنگی سیاست در سراسر کل شبکه معرفی می‌کند.

ادامه