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.

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:

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:

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):

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:

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):

Sau khi tạo xong, VPG sẽ có trạng thái là detach, bạn attack nó 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:

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:

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

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:

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 -

Ruby

• Cài đặt OpenSwan:

$ yum install openswan

C

• Cầu hình IPSec tại /etc/ipsec.conf:

$ vi /etc/ipsec.conf

C

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

JSON

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 server, cả 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:

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

• 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:

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

C

• 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" esp.cb8af2fa@3.229.235.186 esp.c2a6c23c@172.31.5.215 tun.0@3.229.235.186 tun.0@172.31.5.215 ref=0 refhim=0 Traffic: ESPin=0B ESPout=0B! ESPmax=4194303B
000
000 Bare Shunt list:
000
*/

JavaScript

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

JavaScript

• 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.

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:

Ở 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:

Để đư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:

• Sau đó vào IPSec server và bật IP forwarding:

$ sudo vi /etc/sysctl.conf

JavaScript

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

net.ipv4.ip_forward = 1

JavaScript

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

$ sudo service network restart

JavaScript

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)

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

• 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

Chú ý: 

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

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

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

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

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

• 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.

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

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

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

7.3. 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

• 13. ACL Outbound của West Instance: cho phép pong trả về East 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:

7.4. Cấu hình dữ liệu 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:

• 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:

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

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

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

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

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

JavaScript

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

(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

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

• 2. ACL Outbound của West Instance: cho phép ping tới East 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 

• 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

• 5. Route table của IPSec Server: nhận request từ IPSec tunnel và điều hướng tới 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 đó:

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

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

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

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

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

• 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

• 13. ACL Outbound của East Instance, cho phép pong tới West 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

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

• 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:

• 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á

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

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

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

• 22. ACL Inbound của West Instance: cho phép nhận pong từ East 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

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

Nguồn: Internet

>> Đọc thêm:

KHOÁ HỌC TRUY VẤN VÀ THAO TÁC DỮ LIỆU SQL TỪ CƠ BẢN ĐẾN NÂNG CAO

KHÓA HỌC DATA WAREHOUSE : TỔNG HỢP, CHUẨN HÓA VÀ XÂY DỰNG KHO DỮ LIỆU TRONG DOANH NGHIỆP

KHÓA HỌC DATA MODEL – THIẾT KẾ MÔ HÌNH DỮ LIỆU TRONG DOANH NGHIỆP

LỘ TRÌNH TRỞ THÀNH DATA ENGINEER CHO NGƯỜI MỚI BẮT ĐẦU