khoai xin phép có vài ý kiến về bài viết của anh thangdiablo:

1. Mã hóa đối xứng là symmetric encryption, không phả symmetrical :~)
2. Bước IKE theo khoai nghĩ là một bước phải làm để trao đổi khóa. Và bước này sẽ diễn ra trước khi chọn một trong 2 protocols ESP hoặc AH, và một trong 2 mode transport hay tunnel. Cá nhân khoai anh thangdiablo không nên liệt chung IKE và ESP, AH để tránh gây cảm nhận là 3 protocols này ở cùng một "level".

Cám ơn anh thangdiablo, bài viết rất chi tiết.

khoai 

- Nếu sử dụng giao thức ESP :
Thì giao thức ESP sẽ làm công việc là mã hóa ( encryption ) , xác thực ( authentication ) , bảo đảm tính trọn vẹn của dữ liệu ( Securing of data ) . Sau khi đóng gói xong bằng ESP mọi thông tin về mã hóa và giải mã sẽ nằm trong ESP Header .
Các thuật toán mã hóa bao gồm DES , 3DES , AES
Các thuật toán để xác thực bao gồm MD5 hoặc SHA-1
ESP còn cung cấp tính năng anti-relay để bảo vệ các gói tin bị ghi đè lên nó.

- Nếu sử dụng giao thức AH
Thì giao thức AH chỉ làm công việc xác thực ( authentication ) và bảo đảm tính trọn vẹn dự liệu . Giao thức AH không có chức năng mã hóa dự liệu . Do đó AH ít được dùng trong IPSec vì nó không đãm bảo tính an ninh .
 

....
4 . Giao thức ESP
Phía dưới đây là cơ chế mã hóa gói dữ liệu bằng giao thức ESP

Esp là giao thức hỗ trợ cả xác thực và mã hóa .

Phía trên là gói dự liệu ban đầu và ESP sẽ dùng 1 cái key để mã hóa toàn bộ dữ liệu ban đầu . Và trường hợp trên là Ipsec đang chạy ở chế độ Tunel mode nên ngoài ESP header ra nó sẽ sinh ra 1 Ip Header mới không bị mã hóa để có thể truyền đi trong mạng Internet .

....
 

Lý do AH có khả năng cung cấp cơ chế xác thực và bảo đảm tính toàn vẹn (integrity) của dữ liệu là vì AH Header chứa một chữ ký số (Digital Signature - DS) được gọi là giá trị kiểm tra tính toàn vẹn (Integrity Check Value-ICV). Thực chất nó là một giá trị băm được dùng để kiểm tra xem liệu gói tin có bị thay đổi trên đường truyền hay không. Vì AH sử dụng IP header để tính toán DS nên chúng ta có thể chắc chắn rằng địa chỉ nguồn của gói tin là xác thực và gói tin này xuất phát từ đúng nơi gửi.  

Cách thức hoạt động của ESP có khác biệt đôi chút phụ thuộc vào chế độ làm việc của IPSec. Trong chế độ Transport, ESP chỉ đơn thuần thêm phần header của bản thân nó vào sau phần IP header và mã hoá toàn bộ phần còn lại của gói tin từ tầng 4 trở lên. Nếu trong quá trình thương lượng khởi tạo một IPSec connection có chỉ định sử dụng dịch vụ xác thực của ESP, khi đó ESP sẽ thêm một phần (trailer) chứa thông tin ICV để đảm bảo tính toàn vẹn và tính xác thực. Không giống với AH, ESP ICV không tính toán dựa trên các thông tin về IP header.

ESP thường được xem như là sự kết hợp của IPSec với NAT. ESP thường được sử dụng trong chế độ tunnel. Tuy nhiên trong chế độ transport, ESP và NAT không tương thích với nhau vì các thông tin của phần header của gói tin đã bị NAT thay đổi. Khi NAT thực hiện thay đổi phần thông tin về IP, nó cũng sẽ tính lại giá trị checksum trong TCP header. Và bởi vì TCP checksum được tính toán không chỉ dựa vào TCP header, mà nó còn dựa vào các thông tin từ IP header, như địa chỉ nguồn/đích của gói tin nên NAT đã phá vỡ tính toàn vẹn của gói tin. Trong chế độ Transport ESP, toàn bộ TCP header đã được mã hoá, NAT box sẽ không thể tính toán lại TCP checksum. (Vấn đề tương tự đối với UDP packets khi UDP checksum được tính đến). Kết quả là trước khi giải mã, gói tin sẽ bị hủy vì không bảo đảm tính toàn vẹn. Vấn đề này có thể được giải quyết nếu như không đụng đến TCP checksum trong mọi trường hợp.  

Trong chế độ Tunnel ESP, NAT hoàn toàn được tương thích vì toàn bộ gói tin nguồn bao gồm các thông tin về IP và thông tin ở tầng 4 được đóng gói và do đó không bị xử lý bởi NAT. Vì thông tin về IP, TCP header, TCP checksum không bị thay đổi trong chế độ Tunnel ESP nên gói tin sẽ được giải mã và thoả mãn tính toàn vẹn. Tuy nhiên, mặc dù ESP traffic trong chế độ Tunnel có thể tương thích với NAT, bạn sẽ gặp phải các vấn đề liên quan đến NAT khi thương lượng các tham số cho IPSec connection. Chẳng hạn, one-to-many NAT (thường được hiểu là PAT) sẽ sửa đổi tham số cổng nguồn của một outbound IKE packet, dẫn đến giá trị cổng UDP 500 dành cho IKE bị thay đổi, từ đó dẫn đến việc thất bại khi phân phối khoá cho các tham số của IPSec session. 

Một vấn đề còn đang tranh cãi nữa là khả năng xác thực của ESP. Như ta đã biết, ESP có khả năng cung cấp cơ chế xác thực, nhưng giá trị băm mà nó sử dụng được sinh ra dựa trên toàn bộ gói tin ngoại trừ phần IP header và phần authentication trailer. Điều này giúp cho ESP authentication tương thích với NAT, nhưng việc thiếu xác thực của IP header sẽ không đảm bảo được nguồn gốc của gói tin. May thay, trong hầu hết các cài đặt, việc kiểm tra tính xác thực cho phần payload của ESP cũng đủ để nói lên nguồn gốc của gói tin này!  

ESP thường được xem như là sự kết hợp của IPSec với NAT.  

Bài bổ sung của prof rất tốt, alice chỉ nghĩ có thể bài viết sẽ dễ hiểu hơn nếu thay đổi vài điểm về thuật ngữ. )
 

prof wrote:

Lý do AH có khả năng cung cấp cơ chế xác thực và bảo đảm tính toàn vẹn (integrity) của dữ liệu là vì AH Header chứa một chữ ký số (Digital Signature - DS) được gọi là giá trị kiểm tra tính toàn vẹn (Integrity Check Value-ICV). Thực chất nó là một giá trị băm được dùng để kiểm tra xem liệu gói tin có bị thay đổi trên đường truyền hay không. Vì AH sử dụng IP header để tính toán DS nên chúng ta có thể chắc chắn rằng địa chỉ nguồn của gói tin là xác thực và gói tin này xuất phát từ đúng nơi gửi.  

Dùng từ ICV là đủ, tránh dùng từ DS. ICV nói chung không phải là DS và thực tế không phải là DS.
 

prof wrote:

Cách thức hoạt động của ESP có khác biệt đôi chút phụ thuộc vào chế độ làm việc của IPSec. Trong chế độ Transport, ESP chỉ đơn thuần thêm phần header của bản thân nó vào sau phần IP header và mã hoá toàn bộ phần còn lại của gói tin từ tầng 4 trở lên. Nếu trong quá trình thương lượng khởi tạo một IPSec connection có chỉ định sử dụng dịch vụ xác thực của ESP, khi đó ESP sẽ thêm một phần (trailer) chứa thông tin ICV để đảm bảo tính toàn vẹn và tính xác thực. Không giống với AH, ESP ICV không tính toán dựa trên các thông tin về IP header.

ESP thường được xem như là sự kết hợp của IPSec với NAT. ESP thường được sử dụng trong chế độ tunnel. Tuy nhiên trong chế độ transport, ESP và NAT không tương thích với nhau vì các thông tin của phần header của gói tin đã bị NAT thay đổi. Khi NAT thực hiện thay đổi phần thông tin về IP, nó cũng sẽ tính lại giá trị checksum trong TCP header. Và bởi vì TCP checksum được tính toán không chỉ dựa vào TCP header, mà nó còn dựa vào các thông tin từ IP header, như địa chỉ nguồn/đích của gói tin nên NAT đã phá vỡ tính toàn vẹn của gói tin. Trong chế độ Transport ESP, toàn bộ TCP header đã được mã hoá, NAT box sẽ không thể tính toán lại TCP checksum. (Vấn đề tương tự đối với UDP packets khi UDP checksum được tính đến). Kết quả là trước khi giải mã, gói tin sẽ bị hủy vì không bảo đảm tính toàn vẹn. Vấn đề này có thể được giải quyết nếu như không đụng đến TCP checksum trong mọi trường hợp.  

Chỗ IPSec màu vàng có vẻ khó hiểu. Đối tượng đang được giải thích là IPSEC. ESP là một phần của IPSEC. Sẽ không hợp lý lắm khi đem IPSEC để giải thích ESP.

Khi đưa TCP/UDP vào cuộc, cũng nên nói rõ hoàn cảnh sử dụng là ESP bao bọc TCP/UDP. Để phân biệt với hoàn cảnh UDP bao bọc ESP (NAT-T) mà loạt bài sẽ nói đến về sau. 

Đoạn này có thể xem như có 2 phần:

Phần NAT màu vàng thứ nhất nói về tính tương thích của NAT với ESP. Ở đây nên làm rõ thêm từ NAT bởi một từ khác (thí dụ, basic NAT theo tự điển wikipedia), ngụ ý rằng ở đây chỉ có dịch địa chỉ mà thôi. Cũng nên nói rõ thêm NAT trong trường hợp chung (bao hàm PAT) với ESP trong chế độ tunnel là không tương thích bởi vì khác với TCP/UDP, ESP không có khái niệm "cổng". Như thế người đọc sẽ không phải thắc mắc đại loại như nếu ESP tunnel và NAT đã tương thích với nhau, tại sao phải dùng UDP bao bọc ESP để có NAT-T?
 

Phần NAT màu vàng thứ hai nói về tính tương thích của NAT với IKE, cũng nên nói rõ hơn một chút (nhưng chính alice cũng chưa biết nói thế nào cho rõ ), tránh cho người đọc những thắc mắc kiểu như tại sao khác với nhiều giao thức trên nền TCP/UDP, IKE phải cố định cổng nguồn?. 

Theo alice, cụm từ payload của ESP có lẽ sửa thành IP payload hoặc cụ thể hơn 1 chút thì ESP header mới đúng. Như chính prof đã nói, authentication trailer xác thực không những ESP payload mà còn cả ESP header, trong đó có SPI (security parameter index), từ đó dựa theo SAD (security association database) tra được địa chỉ IP của người gửi. Nói cách khác, với một chi phí tính toán thích đáng, cài đặt không cần phải xác thực IP header vẫn xác thực được địa chỉ IP nguồn của gói tin.
 

Trước tiên, hoàn toàn đồng ý với alice ở điểm ICV không phải là DS. ) Tuy nhiên, khi viết đoạn này, ý đồ của mình không nhằm so sánh DS và ICV. Mình tuy là kẻ *ngâm cứu* không chuyên về applied crypto. & its related stuffs nhưng cũng may mắn hiểu được sự khác biệt về phạm vi ứng dụng, và về bản chất của DS. Trong phạm vi bài này, mình sử dụng DS với mục đích giúp người đọc hiểu được những lợi điểm do ICV đem lại, kiểu như dùng một thuật ngữ đã quen thuộc để giải thích cho một thuật ngữ mới hơn. Có lẽ chúng ta đều biết DS có khả năng cung cấp tính xác thực (Authentication), tính toàn vẹn (Integrity), và tính chống phủ nhận (Non-repudiation). ICV trong AH Header cũng hội đủ các điều kiện để cung cấp 2 trong 3 khả năng này. Vì vậy, ở một khía cạnh hẹp & trực quan nào đó, ICV mang đặc điểm của DS.

Mình cũng đã từng gặp ở một số tài liệu khác, khi đề cập đến một intemediate device/application/middleware/..., người viết thường mượn thuật ngữ proxy server nhằm mục đích nói lên tính trung gian của đối tượng đang xét, mặc dù nếu khắt khe hơn, thì proxy server không thể là đối tượng mà họ đang bàn. Đó chỉ là một ví dụ khá *thô* về cách dùng thuật ngữ mà thôi. )

Anyway, có lẽ mình đã lạm dụng thuật ngữ DS này nên dẫn đến hiểu lầm. Prof sẽ chỉnh sửa lại đoạn này bằng việc bỏ đi thuật ngữ DS.  

alice wrote:

Phần NAT màu vàng thứ hai nói về tính tương thích của NAT với IKE, cũng nên nói rõ hơn một chút (nhưng chính alice cũng chưa biết nói thế nào cho rõ ), tránh cho người đọc những thắc mắc kiểu như tại sao khác với nhiều giao thức trên nền TCP/UDP, IKE phải cố định cổng nguồn?. 

Chà, xem ra "người đọc" muốn mở rộng thêm vấn đề về tính tương thích giữa NAT và việc cố định cổng nguồn của IKE đây. Trường hợp này, có lẽ phải mời người tham khảo thêm RFC 3715 để biết chi tiết. ) Phải thừa nhận một điều là còn khá nhiều vấn đề giữa NAT và IPSec mà prof chưa thể nói hết. Bởi vậy, ngay từ đầu, mình chỉ dám đi sâu một chút, vì biết sẽ không đủ sức. Nếu alice hay bạn nào đó có thời gian, các bạn có thể bổ sung thêm những vấn đề mà mình chưa đề cập đến.  

[[ROUTER R1]]
s1/0 = R2 s1/0 # Cổng Serial s1/0 của Router R1 nối với s1/0 của R2

[[router R2]]
model = 7200
s1/1 = R3 s1/1 # Cổng Serial S1/1 của Router R2 nối với S1/1 của R3

[[router R3]]
model = 7200

 

R1#sh run
Building configuration...

Current configuration : 3499 bytes

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption

hostname R1

boot-start-marker
boot-end-marker

enable secret 5 $1$NOsH$dzAiUg0rigA/wHkPJZB/b0

no aaa new-model
ip cef
multilink bundle-name authenticated


crypto pki trustpoint TP-self-signed-4294967295
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-4294967295
revocation-check none
rsakeypair TP-self-signed-4294967295

crypto pki certificate chain TP-self-signed-4294967295
certificate self-signed 01
3082023A 308201A3 A0030201 02020101 300D0609 2A864886 F70D0101 04050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 34323934 39363732 3935301E 170D3037 30343034 32323332
30325A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D34 32393439
36373239 3530819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281
8100B306 EE726C90 E705F165 B464DDA4 314014FA 38DA1020 120AB79E CB3B9AD8
B76B2262 2FAE5208 21C20A01 4304984C 34C0ED37 DD02AF87 99FC8B86 DBCD42FF
B08CF30C B3C19056 50DC2B37 5E7769F2 AB8F8CE4 464DF6BE BB725A97 29A9E629
A323D36D E01FC307 4C61F961 C0AC5C83 3134CFE4 3FD2347A 289F21DC E0F7ED40
D9B30203 010001A3 62306030 0F060355 1D130101 FF040530 030101FF 300D0603
551D1104 06300482 02523130 1F060355 1D230418 30168014 DE1009DC 2F7D3708
04170326 E5336218 6052B3D3 301D0603 551D0E04 160414DE 1009DC2F 7D370804
170326E5 33621860 52B3D330 0D06092A 864886F7 0D010104 05000381 81009463
996F4CA7 6DC06475 AF297485 5A715D4B AE4DB018 13F79AD0 33227310 8DACCC44
1EB897F9 82F41311 7E178D1B 903197F6 5082C822 9BE373DA 5743BE8E 6E68A90E
081C6CF4 BD3ED8D3 C7E4DAF8 10325062 8B1A8A43 80886D42 EFD18E26 3B854D05
969B748B 4F084A4A 1031AA22 7684BBE0 846DA565 AC257813 0AD2B5F9 42A0
quit

interface Loopback0
ip address 192.168.1.1 255.255.255.0

interface Loopback1
ip address 192.168.2.1 255.255.255.0

interface Loopback2
ip address 192.168.3.1 255.255.255.0

interface FastEthernet0/0
ip address 10.10.1.146 255.255.255.0
duplex full

interface Serial1/0
ip address 10.0.0.1 255.255.255.0
ip ospf authentication message-digest \\ Trong khi routing bằng OSPF tôi có authentication giữa các neighbor bằng key là “ thang “
ip ospf message-digest-key 1 md5 thang
no fair-queue
serial restart-delay 0
clock rate 64000


router eigrp 1
network 192.168.1.0
network 192.168.2.0
network 192.168.3.0
auto-summary

router ospf 1 \\ Giữa 3 Router của 3 miền tôi dung cơ chế OSPF để routing. Và tất cả để được nối vào Area0
log-adjacency-changes
summary-address 192.168.0.0 255.255.0.0
redistribute eigrp 1 subnets
network 10.0.0.0 0.0.0.255 area 0

ip http server
ip http secure-server

logging alarm informational

control-plane

gatekeeper
shutdown

banner motd ^C
Retrict Area . This is ASBR . Routing OSPF1 + EIGRP1
^C

line con 0
exec-timeout 0 0
password cisco
login
stopbits 1
 

R2
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption

hostname R2

boot-start-marker
boot-end-marker

enable secret 5 $1$zFeK$NJjHyf.rQkLWZf88tT21R.

no aaa new-model
ip cef


multilink bundle-name authenticated

crypto isakmp policy 1 \\ Chúng ta đang bắt đầu tạo policy cho quá trình IKE mà tôi đã giải thích trong 2 chương trước đó
encr aes \\ Chúng ta sẽ mã hóa bằng AES
authentication pre-share \\ Xác thực bằng pre-share key
group 2
crypto isakmp key 6 cisco address 11.0.0.2 \\ Và key để trao đổi giữa 2 đầu Đà Nẵng và HCM là “ cisco “ . IP 11.0.0.2 chính là IP của Serial 1/1 HCM hay còn gọi là peer của Router Đà Nẵng.
Việc xác định peer này là vô cùng quan trọng vì người quản trị phải biết được mục đích chúng ta đang định giao tiếp với ai và quá trình VPN sẽ xảy ra khi dữ liệu đi từ đâu tới đâu.



crypto ipsec transform-set R2 esp-aes esp-sha-hmac \\ Đến thời điểm này chúng ta đã xong phần thiết lập các chính sách trong quá trình IKE. Trong command này chúng ta đang tiến hành khởi tạo policy cho quá trình đóng gói dữ liệu. Đây là những chính sách mà chúng ta quy định cho việc gói dữ liệu sẽ được bao bọc bởi cơ chế mã hóa gì.

crypto map VPN_TO_R3 10 ipsec-isakmp \\ Command này là thao tác chúng ta chính thức thông báo cho Router ĐN apply các chính sách đã khởi tạo quá trình IKE
set peer 11.0.0.2 \\ Và đối tượng để thiết lập quá trình VPN/IPSEC này là IP 11.0.0.2 của Router HCM
set transform-set R2 \\ Chính thức apply policy của cơ chế IPSEC
match address 101 \\ Apply luồng traffic được mã hóa. Và luồng traffic được mã hóa này chúng ta sẽ tạo ra nó bằng 1 Access list

interface Loopback0
ip address 172.0.0.1 255.255.255.0

interface Loopback1
ip address 172.0.2.1 255.255.255.0

interface Loopback2
ip address 172.0.3.1 255.255.255.0

interface FastEthernet0/0
no ip address
shutdown
duplex half

interface Serial1/0
ip address 10.0.0.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 thang
serial restart-delay 0

interface Serial1/1
ip address 11.0.0.1 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 2 md5 thang
serial restart-delay 0
clock rate 64000
crypto map VPN_TO_R3 \\Apply crypto map vào Interface kết nối VPN

router eigrp 1
network 172.0.0.0 0.0.0.255
network 172.0.2.0 0.0.0.255
network 172.0.3.0 0.0.0.255
auto-summary

router ospf 1
log-adjacency-changes
summary-address 192.168.0.0 255.255.0.0 not-advertise
summary-address 172.0.0.0 255.255.0.0
redistribute eigrp 1 subnets
network 10.0.0.0 0.0.0.255 area 0
network 11.0.0.0 0.0.0.255 area 0

no ip http server
no ip http secure-server



logging alarm informational
access-list 101 permit ip 10.0.0.0 0.0.255.255 210.245.0.0 0.0.255.255 \\ Khi thực hiện command này chúng ta đang tạo ra bộ luật bao gồm những range IP sẽ được VPN và mã hóa bởi IP SEC.
Và Access list 101 này chúng ta đã apply vào Router bằng lệnh match address 101 phía trên. Thao tác tạo ra Access list này các bạn nên làm trước khi Apply các chính sách VPN IPSEC và Router.
Ý nghĩa của command này là tôi muốn Router hiểu rằng tất cả những traffic nào có địa chỉ IP là 10.0.x.x subnet mask 255.255.0.0 khi muốn đi tới range 210.245.x.x subnetmask là 255.255.0.0 đều phải chui qua VPN và được IPSEC bao bọc.


control-plane


gatekeeper
shutdown

banner motd ^C
Retrict Area . This's ASBRs Router . EIGRP1 + OSPF1
^C

line con 0
password cisco
login
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login


end

R2#
 

Building configuration...

Current configuration : 1829 bytes

version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption

hostname R3

boot-start-marker
boot-end-marker


no aaa new-model
ip cef


multilink bundle-name authenticated

crypto isakmp policy 1
encr aes
authentication pre-share
group 2
crypto isakmp key 6 cisco address 11.0.0.1


crypto ipsec transform-set R3 esp-aes esp-sha-hmac

crypto map VPN_TO_R2 10 ipsec-isakmp
set peer 11.0.0.1
set transform-set R3
match address 101





interface Loopback0
ip address 210.245.31.130 255.255.255.255

interface FastEthernet0/0
no ip address
shutdown
duplex half

interface Serial1/0
no ip address
shutdown
no fair-queue
serial restart-delay 0

interface Serial1/1
ip address 11.0.0.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 2 md5 thang
serial restart-delay 0
crypto map VPN_TO_R2


router ospf 1
log-adjacency-changes
network 11.0.0.0 0.0.0.255 area 0
network 210.245.0.0 0.0.255.255 area 0

no ip http server
no ip http secure-server



logging alarm informational
access-list 101 permit ip 210.245.0.0 0.0.255.255 10.0.0.0 0.0.0.255

control-plane

gatekeeper
shutdown

banner motd ^C
Retric Area .^C

line con 0
exec-timeout 0 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login


End
 

Bài viết và các thảo luận rất hay, mong bro thangdiablo tiếp tục post nhiều bài tương tự nữa nhé. 

R#sh crypto map
Crypto Map "VPN-SG-HN" 10 ipsec-isakmp
Peer = 10.252.15.6
Extended IP access list 101
access-list 101 permit ip 10.128.16.0 0.0.15.255 172.16.128.0 0.0.3.255
access-list 101 permit ip 172.16.0.0 0.0.127.255 172.16.128.0 0.0.3.255
Current peer: 10.252.15.6
Security association lifetime: 4608000 kilobytes/3600 seconds
PFS (Y/N): N
Transform sets={
SG-HN,
}
Interfaces using crypto map VPN-SG-HN:
GigabitEthernet0/1
 

R_MGW_SG.ACB.HN#sh crypto ipsec sa

interface: GigabitEthernet0/1
Crypto map tag: VPN-SG-HN, local addr 172.31.1.218

protected vrf: (none)
local ident (addr/mask/prot/port): (172.16.0.0/255.255.128.0/0/0)
remote ident (addr/mask/prot/port): (172.16.128.0/255.255.252.0/0/0)
current_peer 10.252.15.6 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 12699, #pkts encrypt: 12699, #pkts digest: 12699
#pkts decaps: 8707, #pkts decrypt: 8707, #pkts verify: 8707
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 172.31.1.218, remote crypto endpt.: 10.252.15.6
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0xF4B4F10(256593680)

inbound esp sas:
spi: 0x766F7231(1987015217)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3005, flow_id: Onboard VPN:5, crypto map: VPN-SG-HN
sa timing: remaining key lifetime (k/sec): (4442319/3469)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xF4B4F10(256593680)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3006, flow_id: Onboard VPN:6, crypto map: VPN-SG-HN
sa timing: remaining key lifetime (k/sec): (4441189/3469)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

protected vrf: (none)
local ident (addr/mask/prot/port): (10.128.16.0/255.255.240.0/0/0)
remote ident (addr/mask/prot/port): (172.16.128.0/255.255.252.0/0/0)
current_peer 10.252.15.6 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 6, #pkts decrypt: 6, #pkts verify: 6
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: 172.31.1.218, remote crypto endpt.: 10.252.15.6
path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1
current outbound spi: 0x7675CCC0(1987431616)

inbound esp sas:
spi: 0x2C2DE7CF(741205967)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3003, flow_id: Onboard VPN:3, crypto map: VPN-SG-HN
sa timing: remaining key lifetime (k/sec): (4581032/62)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
spi: 0x9875DB42(2557860674)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3002, flow_id: Onboard VPN:2, crypto map: VPN-SG-HN
sa timing: remaining key lifetime (k/sec): (4427799/3596)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x1084C9E4(277137892)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3004, flow_id: Onboard VPN:4, crypto map: VPN-SG-HN
sa timing: remaining key lifetime (k/sec): (4581033/62)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE
spi: 0x7675CCC0(1987431616)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3001, flow_id: Onboard VPN:1, crypto map: VPN-SG-HN
sa timing: remaining key lifetime (k/sec): (4427799/3596)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

 

sh crypto isakmp sa
dst src state conn-id slot status
172.31.1.218 10.252.15.6 QM_IDLE 3 0 ACTIVE
 

Cảm ơn bác thangdiablo đã viết bài rất chi tiết.

Em thấy trong nhiều cấu hình VPN, định nghĩa cho DH group khá là quan trọng mà trong bài này không thấy bác nhắc đến ?