1. Mở đầu

Khi bạn muốn kết nối giữa on-premise server và AWS một cách bảo mật mà không cần cần nối qua Internet thì VPN là một giải pháp hiệu quả.

VPN (Virtual Private Network) là kỹ thuật để mở ra một kênh kết nối riêng, bảo mật giữa 2 server khác nhau. Các gói dữ liệu truyền gửi qua kênh kết nối này đều được mã hoá.

Có một số cách để cấu hình VPN, nổi bật trong đó có 2 cách là cấu hình OpenVPN hoặc cấu hình IPSec.

Bạn nên sử dụng OpenVPN thay vì IPSec vì nó hỗ trợ nhiều phương thức bảo mật hơn, được update thường xuyên và dễ cấu hình hơn.

(Xem bài viết về cách cấu hình OpenVPN tại https://blog.daovanhung.com/post/cau-hinh-openvpn-trong-trong-aws).

Bài viết này mình trình bày cách cấu hình IPSec sử dụng OpenSwan giữa 2 server private khác nhau, một server nằm trên VPC ở Tokyo và một server nằm trên VPC khác ở Virginia. Giả sử VPC Tokyo của mình là on-premise.

VPC Tokyo có CIDR là 172.31.0.0/16, VPC Virginia có CIDR là 172.32.0.0/16.

 

2. Mục tiêu

Mục tiêu đặt ra là:

  • private EC2 instance (East Instance) tại VPC Tokyo kết nối được tới private EC2 instance (West Instance) tại VPC Virginia mà không cần đi ra ngoài internet.
  • private EC2 instance (West Instance) tại VPC Virginia kết nối được tới private EC2 instance (East Instance) tại VPC Tokyo mà không cần đi ra ngoài internet.

Để làm được điều trên, bạn cần tạo một kênh kết nối bảo mật riêng (IPSec tunnel) giữa 2 VPC:

IPSec tunnel là gì?

 

3. Trình tự cấu hình

Các bước cấu hình sẽ theo trình tự như sau:

  • Tại VPC Tokyo: tạo một public EC2 instance để cấu hình IPSec tunnel (server này mình gọi là IPSec Server).
  •  VPC Virginia: Tạo Site-to-Site VPN Connection để IPSec server kết nối tới.
  •  VPC Tokyo: Cấu hình IPSec tunnel tại IPSec Server để kết nố tới Site-to-Site VPN Connection ở VPC Virginia.
  • Tạo một private EC2 instance tại Tokyo (quy ước là East Instance), một private EC2 instance tại Virginia (quy ước là West Instance).
  • Cấu hình AWS để từ East Instance ping tới West Instance thành công.
  • Cấu hình AWS để từ West Instance ping tới East Instance thành công.

Để tạo Site-to-Site VPN Connection tại Virginia cho Tokyo kết nối tới, bạn cần có một public IP tại Tokyo (là public IP của server cấu hình IPSec) nên ta sẽ tạo server tại Tokyo trước:

 

4. Tạo IPSec Server tại Tokyo

Bạn tạo một EC2 instance trong public subnet và có public IP như bình thường:

Tạo IPSec server trong AWS

 

IPSec server của mình có public IP là 13.114.9.78

 

5. Tạo Site-to-Site VPN Connection tại Virginia

Để tạo Site-to-Site VPN Connection, ta cần tạo 3 thứ là Customer Gateway (CG), Virtual Private Gateway (VPG) và Site-to-Site VPN Connection (VPN):

Site-to-Site VPN Connection AWS

Cả 3 thứ trên đều được tạo tại VPC Virginia (nằm bên trái của hình trên):

5.1. Tạo Customer Gateway (CG)

Vào VPC -> Virtual Private Network -> Customer Gateway và tạo một Customer Gateway.

Chú ý: IP Address là public IP của IPSec Server:

Tạo Customer Gateway trong AWS

 

5.2. Tạo Virtual Private Gateway (VPG).

Vào VPC -> Virtual Private Network -> Virtual Private Gateways và tạo một Virtual Private Gateway (VPG):

Tạo Virtual Private Gateway trong AWS

 

Sau khi tạo xong, VPG sẽ có trạng thái là detach, bạn attack nó vào VPC:

attach Virtual Private Gateway vào VPC

5.3. Tạo Site-to-Site VPN Connection (VPN)

Vào VPC -> Virtual Private Network -> Site-to-Site VPN Connections và tạo VPN:

Tạo Site-to-Site VPN AWS

 

Sau khi tạo xong, 2 tunnel trong VPN sẽ có trạng thái là DOWN vì ta chưa khởi tạo kết nối nào tới chúng, ở hình dưới mình đã tạo kết nối tới Tunnel 1 nên trạng thái đã thành UP:

DOWN tunnel VPN

 

Sau khi tạo VPN xong, bạn tải Configuration về:

Tải configuration VPN connection

Mở file vừa tải về để lấy thông tin Pre-Shared Key, mình sẽ kết nối tới Tunnel 1 nên sẽ lấy ở Tunnel 1:

Lấy Pre-Shared Key trong VPN

 

6. Cấu hình IPSec tunnel và security

6.1. Cấu hình IPSec tunnel

Ta sẽ cấu hình IPSec tunnel tại IPSec Server ở Tokyo. Để cấu hình IPSec, ta cần cài đặt OpenSwan:

  • Đăng nhập root vào server:
$ sudo su -
  • Cài đặt OpenSwan:
$ yum install openswan
  • Cầu hình IPSec tại /etc/ipsec.conf:
$ vi /etc/ipsec.conf

Thêm vào phía cuối đoạn config sau:

conn hungdv
     # preshared key
     authby=secret
     # load connection and initiate it on startup
     auto=start
     forceencaps=yes
     # use %defaultroute to find our local IP, since it is dynamic
     left=%defaultroute
     leftsubnet=172.31.0.0/16
     # set our desired source IP to the Elastic IP. Openswan will create interface address and route
     right=3.229.235.186
     rightsubnet=172.32.0.0/16

Chú ý:

  • leftsubnet là CIDR của VPC Tokyo.
  • right là IP của Tunnel 1 của VPN Connection đã tạo ở trên.
  • rightsubnet là CIDR của VPC Virginia.
  • Cấu hình IPSec tại /etc/ipsec.secrets:
$ vi /etc/ipsec.secrets

Thêm dòng sau vào cuối file trên:

3.229.235.186 0.0.0.0 %any: PSK "mDDweVSVgzfR_0eut9HzQ8ZftMpAjVmE"

Chú ý: 

  • IP đầu tiên là IP của Tunnel 1 trong VPN.
  • Dãy ký tự ở cuối là Pre-shared Key của Tunnel 1 trong VPN.

 

6.2. Cấu hình security group (SG) và network ACL

  • SG Outbound của IPSec servercả 2 cổng UDP 500 và UDP 4500 cần được mở request tới Tunnel 1, vì SG là statefull nên không cần cấu hình SG Inbound:

SG Outbound của IPSec Server

  • ACL Outbound của IPSec Server, UDP 500 và UDP 4500 cần được mở để request tới Tunnel 1 :

ACL Outbound IPSec Server

  • ACL Inbound của IPSec Server, UDP 500 và UDP 4500 cần được mở để nhận kết quả trả về từ Tunnel 1:

ACL Inbound của IPSec Server

 

6.3. Kiểm tra IPSec tunnel

  • Sau khi cầu hình IPSec và Security xong thì khởi động lại IPSec:
$ systemctl ipsec restart
  • Kiểm tra xem IPSec tunnel đã được tạo kết nối chưa:
$ ipsec status

/*
000 Total IPsec connections: loaded 1, active 1
000  
000 State Information: DDoS cookies not required, Accepting new IKE connections
000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)
000 IPsec SAs: total(1), authenticated(1), anonymous(0)
000  
000 #1: "hungdv":4500 STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 2601s; newest ISAKMP; lastdpd=-1s(seq in:0 out:0); idle; import:admin initiate
000 #2: "hungdv":4500 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 28042s; newest IPSEC; eroute owner; isakmp#1; idle; import:admin initiate
000 #2: "hungdv" [email protected] [email protected] [email protected] [email protected] ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B 
000  
000 Bare Shunt list:
000  
*/

Nếu kết quả là "Total IPsec connections: loaded 1, active 1" như trên thì đã thành công.

Nếu thất bại, bạn có thể check log như sau:

$ tail -f /var/log/secure

 

  • Khi cấu hình  thành công, bạn đợi khoảng 10 phút để status của Tunnel 1 trong VPN trở thành UP.

UP tunnel VPN

 

7. Kết nối từ Tokyo tới Virginia

Dưới đây mình sẽ trình bày cách sử dụng IPSec tunnel để kết nối từ private instance ở Tokyo (East Instance) tới private instance ở Virginia (West Instance) thông qua private IP mà không cần sử dụng public IP.

Mình sẽ ping từ East Instance và nhận pong từ West Instance, sẽ cài đặt security ở mức tối thiểu nhất để chấp nhận ping - pong:

Kết nối từ on-premise tới cloud

Ở hình trên thì đường màu đen là ping, đường màu xanh là pong.

(Hình trên hơi mờ, xuống từng phần sẽ có hình rõ hơn).

 

7.1. Cấu hình dữ liệu đi bên Tokyo

Đường màu đen dưới đây:

Cấu hình dữ liệu đi bên Tokyo

Để đưa request từ East Instance tới West Instance, bạn cần đưa traffic đi qua IPSec server, lúc này IPSec server sẽ đóng vai trò như một NAT instance

  • Đầu tiên bạn cần tắt Source / Destination Check của IPSec Server:

tắt Source / Destination Check của IPSec server

  • Sau đó vào IPSec server và bật IP forwarding:
$ sudo vi /etc/sysctl.conf

Thêm dòng sau vào cuối file trên:

net.ipv4.ip_forward = 1

Và khởi động lại network:

$ sudo service network restart

 

Dưới đây là giải thích cho từng số đánh ở đường màu đen trong hình trên:

  • 1. SG Outbound của East Instance: cho phép ping đi tới West Instance (Destination là IP của West Instance)

SG Outbound của East Instance

  • 2. ACL Outbound của East Instance: cho phép ping tới West Instance (Destination là IP của West Instance)

ACL Outbound

  • 3. Route table của East Instance: Nếu có request tới VPC ở Virginia thì sẽ điều hướng tới IPSec Server

Route table của East Instance

Chú ý: 

  • Destination là CIDR của VPC Virginia
  • Target IPSec Server.

 

  • 4. ACL Inbound của IPSec Server, cho phép forward request từ East Instance:

ACL Inbound của IPSec Server

 

  • 5. SG Inbound của IPSec Server, cho phép forward request từ East Instance :

SG Inbound của IPsec Server

  • 6. Route Table của IPSec Server, cho phép route traffic tới VPN Tunnel 1 thông qua Internet Gateway:

RT của IPSec server

Chú ý: Ở bước này, khi request đi từ IPSec server ra tới Route table sẽ không phải đi qua SG và Network ACL vì cơ chế hoạt động của IPSec sử dụng phương thức UDP cho phép thông qua 2 bộ phận đó.

 

7.2. Cấu hình dữ liệu tới bên Virginia

Cấu hình dữ liệu tới bên Virginia

  • 7. Virtual Private Gateway sẽ nhận request thông qua IPSec Tunnel và dựa vào Static Route: IP Prefixes chính là CIDR của VPC Tokyo.

virtual private gateway Static Route

  • 8. request sẽ được điều hướng tới Route table của West Instance.
  • 9. Route table của West Instance:

Route table của West Instance

 

  • 10. ACL Inbound của West Instance: cho phép East Instance gửi ping vào

ACL Inbound của West Instance

  • 11. SG Inbound của West Instance:cho phép East Instance gửi ping vào

SG Inbound VPN

 

7.3. Cấu hình dữ liệu trả về bên Virginia

Cấu hình dữ liệu trả về bên Virginia

 

  • 12. SG Outbound của West Instance: Vì SG là statefull nên không cần cấu hình thêm

SG Outbound của West Instance

  • 13. ACL Outbound của West Instance: cho phép pong trả về East Instance

ACL Outbound của West Instance

  • 14. Route table của West Instance: traffic muốn đi tới VPC Tokyo phải đi qua Virtual Private Gateway của VPN:

Route table VPN

 

7.4. Cấu hình dữ liệu trả về bên Tokyo

Cấu hình dữ trả về bên Tokyo

  • 15. request trả về đi tới VPC Tokyo thông qua IPSec tunnel. Route table của IPSec Server sẽ điều hướng pong tới instance:

RT của IPSec Server

  • 16. pong đi vào IPSec Server sẽ không cần thông qua ACL và SG vì cơ chế của giao thức IPSec cho phép điều đó.
  • 17. IPSec Server sẽ forward lại pong tới East Instance nên cần đưa request ra ngoài nó. Vì SG là statefull nên không cần cấu hình gì thêm:

SG Outbound của IPSec

  • 18. ACL Outbound của IPSec Server: cho phép pong trả về East Instance

ACL Outbound của IPSec server

  • 19. Route table của East Instance, cho phép pong đi tới East Instance:

Route table của East Instance

  • 20. ACL Inbound của East Instance: cho phép pong từ West Instance đi vào:

ACL Inbound của East Instance

  • 21. SG Inbound của East Instance: cho phép pong từ West Instance đi vào, vì SGstatefull nên không cần cấu hình thêm

SG Inbound của East Instance

 

Thế là xong, bạn đăng nhập vào East Instance và ping thử tới West Instance :

[ec2-user@ip-172-31-73-9 ~]$ ping 172.32.22.165
PING 172.32.22.165 (172.32.22.165) 56(84) bytes of data.
64 bytes from 172.32.22.165: icmp_seq=1 ttl=253 time=166 ms
64 bytes from 172.32.22.165: icmp_seq=2 ttl=253 time=166 ms
64 bytes from 172.32.22.165: icmp_seq=3 ttl=253 time=166 ms
64 bytes from 172.32.22.165: icmp_seq=4 ttl=253 time=166 ms

Như bạn thấy, mình chỉ dùng private IP của West Instance để ping.

 

8. Kết nối từ Virginia tới Tokyo

Kết nối từ Cloud tới on-premise

(Xem hình ảnh rõ hơn ở từng phần phía dưới).

Dưới đây là ví dụ về ping - pong từ Virginia tới Tokyo:

8.1. Cấu hình dữ liệu gửi đi bên Virginia

Cấu hình dữ liệu gửi đi ở cloud

  • 1. SG Outbound của West Instance: cho phép ping tới East Instance:

SG Outbound của West Instance

  • 2. ACL Outbound của West Instance: cho phép ping tới East Instance

ACL Outbound của West Instance

  • 3. Route table của West Instance: khi có request tới VPC Tokyo thì điều hướng tới Virtual Private Gateway 

Route table của West Instance

  • 4. Request được gửi tới VPC Tokyo thông qua IPSec tunnel.

 

8.2. Cấu hình dữ liệu nhận bên phía Tokyo

Cấu hình dữ liệu nhận bên on-premise

  • 5. Route table của IPSec Server: nhận request từ IPSec tunnel và điều hướng tới IPSec Server 

Route table của IPSec Server

  • 6. Từ Route table đi tới IPSec Server không cần thông qua ACL và SG vì cơ chế hoạt động của protocol IPSec.
  • 7. IPSec Server nhận ping từ IPSec tunnel và đưa tới East Instance nên SG Outbound của IPSec Server phải cho phép ping tới đó:

SG Outbound của IPSec Server

  • 8. ACL Outbound của IPSec Server: cho phép đưa ping tới East Instance

ACL Outbound của IPSec Server

  • 9. Route table của East Instance: điều hướng request tới East Instance

Route table của East Instance

  • 10. ACL Inbound của East Instance: cho phép nhận ping từ West Instance

ACL Inbound của East Instance

  • 11. SG Inbound của East Instance: cho phép nhận ping từ West Instance

SG Inbound của East Instance

 

8.3. Cấu hình dữ liệu trả về bên phía Tokyo

Cấu hình dữ liệu trả về bên on-premise

  • 12. SG Outbound của East Instance: cho phép pong tới West Instance, vì SG là statefull nên không cần cấu hình gì thêm

SG Outbound của East Instance

  • 13. ACL Outbound của East Instance, cho phép pong tới West Instance

ACL Outbound của East Instance

  • 14. Route table của East Instance: mọi traffic tới VPC Virginia từ private subnet phải đi qua IPSec Server nên ở đây sẽ điều hướng để pong đi tới IPSec Server

Route table của East Instance

  • 15. ACL Inbound của IPSec Server: cho phép nhận pong từ East Instance

ACL Inbound của IPSec server

  • 16. SG Inbound của IPSec Server, cho phép nhận pong từ East Instance, vì SG là statefull nên không cần cấu hình gì thêm ở đây:

SG Inbound của IPSec Server

  • 17. Từ IPSec Server đưa pong qua IPSec tunnel sẽ không thông qua ACL và SG mà đi thẳng tới Route table của IPSec Server do cơ chế hoạt đông của protocol IPSec: 
  • 18-19. Route table của IPSec Server: từ đây pong đi ra ngoài internet và tới VPC Virginia thông qua kênh IPSec đã mã hoá

Route table của IPSec server

 

8.4. Cấu hình dữ liệu trả về bên phía Virginia

Cấu hình dữ liệu nhận về ở cloud

  • 20. Static Route của Virtual Private Gateway: cho phép nhận dữ liệu từ Tokyo

static route của virtual private gateway

  • 21. Route table của West Instance: điều hướng pong đi tới instance

route table của west instance

  • 22. ACL Inbound của West Instance: cho phép nhận pong từ East Instance

ACL Inbound của West Instance

  • 22. SG Inbound của West Instance: cho phép nhận pong từ East Instance, vì SG là statefull nên không cần cấu hình gì thêm

SG Inbound của West Instance

 

Thế là xong, bạn vào West Instance và ping thử tới private IP của East Instance để thấy kết quả:

[ec2-user@ip-172-32-152-225 ~]$ ping 172.31.73.9
PING 172.31.73.9 (172.31.73.9) 56(84) bytes of data.
64 bytes from 172.31.73.9: icmp_seq=1 ttl=254 time=166 ms
64 bytes from 172.31.73.9: icmp_seq=2 ttl=254 time=166 ms
64 bytes from 172.31.73.9: icmp_seq=3 ttl=254 time=166 ms
64 bytes from 172.31.73.9: icmp_seq=4 ttl=254 time=168 ms
64 bytes from 172.31.73.9: icmp_seq=5 ttl=254 time=166 ms
64 bytes from 172.31.73.9: icmp_seq=6 ttl=254 time=166 ms