نحوه عیب یابی IPsec VPN داخلی. قسمت 1

نحوه عیب یابی IPsec VPN داخلی. قسمت 1

وضعیت

مرخصی روزانه. من قهوه می نوشم. دانش آموز یک اتصال VPN بین دو نقطه راه اندازی کرد و ناپدید شد. بررسی می کنم: واقعاً یک تونل وجود دارد، اما ترافیک در تونل وجود ندارد. دانش آموز به تماس ها پاسخ نمی دهد.

من کتری را می گذارم و به عیب یابی S-Terra Gateway شیرجه می زنم. من تجربه و روش خود را به اشتراک می گذارم.

داده های خام

دو سایت جدا از هم جغرافیایی توسط یک تونل GRE به هم متصل می شوند. GRE باید رمزگذاری شود:

نحوه عیب یابی IPsec VPN داخلی. قسمت 1

من در حال بررسی عملکرد تونل GRE هستم. برای این کار از دستگاه R1 به رابط GRE دستگاه R2 پینگ می کنم. این ترافیک هدف برای رمزگذاری است. بدون پاسخ:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3057ms

من به گزارش‌های Gate1 و Gate2 نگاه می‌کنم. گزارش با خوشحالی گزارش می دهد که تونل IPsec با موفقیت راه اندازی شد، بدون مشکل:

root@Gate1:~# cat /var/log/cspvpngate.log
Aug  5 16:14:23 localhost  vpnsvc: 00100119 <4:1> IPSec connection 5 established, traffic selector 172.17.0.1->172.16.0.1, proto 47, peer 10.10.10.251, id "10.10.10.251", Filter 
IPsec:Protect:CMAP:1:LIST, IPsecAction IPsecAction:CMAP:1, IKERule IKERule:CMAP:1

در آمار تونل IPsec در Gate1 می بینم که واقعاً یک تونل وجود دارد، اما شمارنده Rсvd به صفر تنظیم می شود:

root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1070 1014

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 3 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 480 0

من S-Terra را اینطور مشکل می کنم: من به دنبال جایی هستم که بسته های هدف در مسیر R1 به R2 گم می شوند. در روند (اسپویل) من یک اشتباه پیدا خواهم کرد.

عیب یابی

مرحله 1. آنچه Gate1 از R1 دریافت می کند

من از sniffer بسته داخلی - tcpdump استفاده می کنم. من Sniffer را در رابط داخلی (Gi0/1 در نماد سیسکو یا eth1 در نماد سیستم عامل Debian) راه اندازی می کنم:

root@Gate1:~# tcpdump -i eth1

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:53:38.879525 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 1, length 64
14:53:39.896869 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 2, length 64
14:53:40.921121 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 3, length 64
14:53:41.944958 IP 172.16.0.1 > 172.17.0.1: GREv0, key=0x1, length 92: IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 2083, seq 4, length 64

من می بینم که Gate1 بسته های GRE را از R1 دریافت می کند. من در حال حرکت هستم.

مرحله 2. کاری که Gate1 با بسته های GRE انجام می دهد

با استفاده از ابزار klogview می توانم ببینم چه اتفاقی با بسته های GRE در درایور S-Terra VPN می افتد:

root@Gate1:~# klogview -f 0xffffffff

filtration result for out packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 4 "IPsecPolicy:CMAP", filter 8, event id IPsec:Protect:CMAP:1:LIST, status PASS
encapsulating with SA 31: 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0
passed out packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: encapsulated

من می بینم که ترافیک هدف GRE (پرتو 47) 172.16.0.1 -> 172.17.0.1 تحت قانون رمزگذاری LIST در نقشه رمزنگاری CMAP قرار گرفت و کپسوله شد. بعد، بسته مسیریابی شد (از بین رفت). هیچ ترافیک پاسخی در خروجی klogview وجود ندارد.

من در حال بررسی لیست های دسترسی در دستگاه Gate1 هستم. من یک لیست دسترسی را می بینم، که ترافیک هدف را برای رمزگذاری تعریف می کند، به این معنی که قوانین فایروال پیکربندی نشده اند:

Gate1#show access-lists
Extended IP access list LIST
    10 permit gre host 172.16.0.1 host 172.17.0.1

نتیجه گیری: مشکل از دستگاه Gate1 نیست.

اطلاعات بیشتر درباره klogview

درایور VPN تمام ترافیک شبکه را مدیریت می کند، نه فقط ترافیکی که باید رمزگذاری شود. اگر درایور VPN ترافیک شبکه را پردازش کرده و به صورت رمزگذاری نشده ارسال کند، این پیام‌ها در klogview قابل مشاهده است:

root@R1:~# ping 172.17.0.1 -c 4

root@Gate1:~# klogview -f 0xffffffff

filtration result for out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: chain 4 "IPsecPolicy:CMAP": no match
passed out packet 172.16.0.1->172.17.0.1, proto 1, len 84, if eth0: filtered

من می بینم که ترافیک ICMP (proto 1) 172.16.0.1->172.17.0.1 در قوانین رمزگذاری کارت رمزنگاری CMAP گنجانده نشده است (بدون مطابقت). بسته به صورت متن واضح مسیریابی شد (از بین رفت).

مرحله 3. آنچه Gate2 از Gate1 دریافت می کند

من Sniffer را در رابط WAN (eth0) Gate2 راه اندازی می کنم:

root@Gate2:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:05:45.104195 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x1), length 140
16:05:46.093918 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x2), length 140
16:05:47.117078 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x3), length 140
16:05:48.141785 IP 10.10.10.251 > 10.10.10.252: ESP(spi=0x30088112,seq=0x4), length 140

من می بینم که Gate2 بسته های ESP را از Gate1 دریافت می کند.

مرحله 4. کاری که Gate2 با بسته های ESP انجام می دهد

من ابزار klogview را در Gate2 راه اندازی می کنم:

root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: chain 17 "FilterChain:L3VPN", filter 21, status DROP
dropped in packet 10.10.10.251->10.10.10.252, proto 50, len 160, if eth0: firewall

من می بینم که بسته های ESP (proto 50) توسط قانون فایروال (L3VPN) حذف شده اند (DROP). من مطمئن هستم که Gi0/0 در واقع یک لیست دسترسی L3VPN به آن متصل است:

Gate2#show ip interface gi0/0
GigabitEthernet0/0 is up, line protocol is up
  Internet address is 10.10.10.252/24
  MTU is 1500 bytes
  Outgoing access list is not set
  Inbound  access list is L3VPN

من مشکل را کشف کردم.

مرحله 5. لیست دسترسی چه اشکالی دارد

من به لیست دسترسی L3VPN نگاه می کنم:

Gate2#show access-list L3VPN
Extended IP access list L3VPN
    10 permit udp host 10.10.10.251 any eq isakmp
    20 permit udp host 10.10.10.251 any eq non500-isakmp
    30 permit icmp host 10.10.10.251 any

من می بینم که بسته های ISAKMP مجاز هستند، بنابراین یک تونل IPsec ایجاد می شود. اما هیچ قانون فعال کننده ای برای ESP وجود ندارد. ظاهراً دانشجو icmp و esp را اشتباه گرفته است.

ویرایش لیست دسترسی:

Gate2(config)#
ip access-list extended L3VPN
no 30
30 permit esp host 10.10.10.251 any

مرحله 6. بررسی عملکرد

اول از همه، مطمئن می شوم که لیست دسترسی L3VPN درست است:

Gate2#show access-list L3VPN
Extended IP access list L3VPN
    10 permit udp host 10.10.10.251 any eq isakmp
    20 permit udp host 10.10.10.251 any eq non500-isakmp
    30 permit esp host 10.10.10.251 any

اکنون ترافیک هدف را از دستگاه R1 راه اندازی می کنم:

root@R1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=35.3 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=3.01 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=2.65 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=2.87 ms

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 2.650/10.970/35.338/14.069 ms

پیروزی. تونل GRE ایجاد شده است. شمارنده ترافیک ورودی در آمار IPsec صفر نیست:

root@Gate1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 3 (10.10.10.251,500)-(10.10.10.252,500) active 1474 1350

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 4 (172.16.0.1,*)-(172.17.0.1,*) 47 ESP tunn 1920 480

در دروازه Gate2، در خروجی klogview، پیام هایی ظاهر شد که ترافیک هدف 172.16.0.1->172.17.0.1 با موفقیت رمزگشایی شد (PASS) توسط قانون LIST در نقشه رمزنگاری CMAP:

root@Gate2:~# klogview -f 0xffffffff
filtration result for in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: chain 18 "IPsecPolicy:CMAP", filter 25, event id IPsec:Protect:CMAP:1:LIST, status PASS
passed in packet 172.16.0.1->172.17.0.1, proto 47, len 112, if eth0: decapsulated

نمایش نتایج: از

دانش آموزی روز تعطیلش را خراب کرد.
مراقب قوانین ME باشید.

مهندس ناشناس
t.me/anonymous_engineer


منبع: www.habr.com

اضافه کردن نظر