Hướng dẫn đồng bộ dữ liệu PostgreSQL qua đường hầm SSH Proxy an toàn giữa các Region (2026)

Mở public port 5432 ra internet công cộng luôn là nỗi ám ảnh với bất kỳ Database Administrator (DBA) hay Backend Developer nào. Khi hạ tầng của bạn phơi mình trên internet, hệ thống sẽ lập tức lọt vào tầm ngắm của các botnet rà soát cổng tự động, liên tục phải hứng chịu các đợt brute-force. Nguy hiểm hơn, nếu luồng dữ liệu WAL (Write-Ahead Log) không được mã hóa cẩn thận, toàn bộ thông tin nhạy cảm có thể bị đánh cắp trên đường truyền.

Khi dự án cần scale lên quy mô đa vùng (multi-region), bài toán đặt ra là làm sao replication dữ liệu mượt mà, độ trễ thấp mà không phải thiết lập các hệ thống mạng quá cồng kềnh. Phương pháp thiết lập đồng bộ dữ liệu PostgreSQL qua đường hầm SSH Proxy chính là một giải pháp thực chiến giải quyết hiệu quả vấn đề này. Hãy cùng bóc tách từng lớp cấu hình để khóa chặt bảo mật hạ tầng database của bạn.

Nỗi đau khi replicate Database qua Internet Public (Packet Sniffing & rò rỉ dữ liệu)

Khi hai máy chủ VPS (Primary và Standby) giao tiếp với nhau xuyên biên giới thông qua mạng lưới internet, dữ liệu của bạn bắt buộc phải đi qua hàng loạt node mạng trung gian từ các ISP, IXP. Việc chỉ mở port 5432 và truyền tải dữ liệu thuần túy mang đến những rủi ro chí mạng:

• Rò rỉ dữ liệu (Packet Sniffing / Eavesdropping): Quá trình Streaming Replication luân chuyển toàn bộ các thay đổi về cấu trúc bảng (DDL), thao tác dữ liệu (DML) và cả mật khẩu xác thực. Nếu kết nối không có lớp mã hóa bảo vệ, kẻ tấn công có thể sử dụng các công cụ bắt gói tin để đọc toàn bộ luồng dữ liệu này dưới dạng văn bản rõ (clear-text).
• Tấn công MITM (Man-in-the-Middle): Nếu không có cơ chế xác thực danh tính mạnh mẽ ở tầng transport, hacker có thể chèn mình vào giữa kết nối. Chúng có thể giả mạo node Standby để tải về bản sao toàn vẹn của dữ liệu (Base Backup), hoặc giả mạo Primary để đẩy các bản ghi WAL sai lệch, phá hỏng tính toàn vẹn của cơ sở dữ liệu.
• Tốn tài nguyên do Brute-force: Port 5432 hiển thị trên firewall đồng nghĩa với việc bạn đang mời gọi các công cụ rà soát tự động. Máy chủ sẽ liên tục nhận hàng ngàn request rác nhằm dò mật khẩu, gây lãng phí tài nguyên CPU và RAM.
  • Để bảo vệ các cổng dịch vụ mở ra ngoài, developer thường phải kết hợp các kỹ thuật chống Brute Force toàn diện bằng Fail2Ban, nhưng đóng hẳn cổng dịch vụ nội bộ vẫn là phương án an toàn hiệu quả.

Luồng dữ liệu WAL có thể dễ dàng bị đánh cắp bằng kỹ thuật Packet Sniffing nếu cổng 5432 phơi mình trên internet công cộng mà không được mã hóa.

Tại sao developer nên đồng bộ dữ liệu PostgreSQL qua đường hầm SSH Proxy?

So sánh SSH Tunnel vs VPN (WireGuard) vs Native SSL

Đứng trước bài toán bảo mật đường truyền, các kỹ sư thường phân vân giữa việc dùng SSH Tunnel, thiết lập VPN (như WireGuard) hay cấu hình Native SSL trực tiếp. Việc hiểu rõ bản chất sẽ giúp bạn phân biệt VPS, Proxy và VPN để chọn đúng công cụ cho đúng bối cảnh:

• Native SSL/TLS: Yêu cầu bạn phải quản lý một hạ tầng khóa công khai (PKI), tự ký chứng chỉ (certificate) và liên tục theo dõi để gia hạn. Điểm yếu lớn của giải pháp này là bạn vẫn phải expose port 5432 ra public internet.
• VPN (WireGuard): WireGuard là một công nghệ hiện đại hoạt động ở tầng nhân hệ điều hành (Kernel Space). Nhờ sử dụng thuật toán ChaCha20, WireGuard mang lại hiệu năng (throughput) truyền tải ấn tượng, hiệu quả cao trong các hệ thống đòi hỏi lưu lượng lớn. Tuy nhiên, thiết lập VPN yêu cầu quyền quản trị mạng sâu, cấu hình routing table phức tạp. Nó mở ra một lớp kết nối L3, khiến hai máy chủ nhìn thấy toàn bộ dịch vụ nội bộ của nhau, vô tình mở rộng bề mặt tấn công.
• SSH Tunneling: Hoạt động hoàn toàn ở lớp ứng dụng (Userspace). Giải pháp này tối giản vì OpenSSH đã được tích hợp sẵn trên mọi bản phân phối Linux. SSH Tunnel áp dụng chuẩn nguyên tắc đặc quyền tối thiểu (Least Privilege) bằng cách chỉ chuyển tiếp một luồng TCP đơn lẻ, cô lập hoàn toàn các dịch vụ khác. Bạn cũng không cần bận tâm đến việc quản lý PKI như Native SSL.

Cơ chế Local Port Forwarding và cách xử lý TCP-over-TCP meltdown

Cơ chế Local Port Forwarding (-L) biến SSH Client thành một proxy cục bộ. Máy Standby sẽ mở một port nội bộ (ví dụ: 15432). Khi PostgreSQL Standby kết nối vào port này, nhiều người lo ngại sẽ xảy ra hiện tượng TCP-over-TCP meltdown (sụp đổ TCP do hai lớp giao thức kiểm soát tắc nghẽn chồng chéo nhau).

Tuy nhiên, OpenSSH xử lý vấn đề này rất thông minh. SSH Client không nhồi gói tin TCP nguyên bản của PostgreSQL vào trong TCP của SSH. Thay vào đó, nó hoạt động như một proxy mức ứng dụng: trích xuất phần dữ liệu thô (raw payload) từ kết nối của PostgreSQL, đóng gói phần dữ liệu đó vào các kênh mã hóa của SSH và đẩy qua port 22 tới Primary. Tại Primary, SSH Server giải mã và thiết lập một kết nối TCP hoàn toàn độc lập để bơm dữ liệu vào địa chỉ 127.0.0.1:5432. Nhờ vậy, hiện tượng xung đột cửa sổ trượt (sliding window) của TCP được khắc phục hiệu quả.

Kiến trúc Local Port Forwarding giúp đóng gói an toàn luồng dữ liệu PostgreSQL vào một kênh mã hóa, ẩn cơ sở dữ liệu hoàn toàn khỏi internet.

Yêu cầu chuẩn bị hạ tầng (prerequisites)

Để thực hiện thiết lập, bạn cần chuẩn bị môi trường mạng như sau:

1. VPS Primary (Master): Đặt tại Region A (Ví dụ: Singapore). Cài đặt sẵn PostgreSQL (khuyến nghị sử dụng bản 16 hoặc 17 trở lên).
2. VPS Standby (Replica): Đặt tại Region B (Ví dụ: Frankfurt). Cài đặt cùng một phiên bản PostgreSQL với máy Primary để đảm bảo tính tương thích.
3. Hệ điều hành: Ubuntu 22.04 / 24.04 / 26.04 hoặc các bản phân phối Linux tương đương.
4. Quyền truy cập: Quyền sudo trên cả hai máy chủ.

Step-by-step: Cấu hình đồng bộ dữ liệu PostgreSQL qua đường hầm SSH Proxy

Bước 1: Giới hạn PostgreSQL Primary chỉ listen trên localhost

Nguyên tắc bảo mật lõi của kiến trúc này là ép cơ sở dữ liệu từ chối mọi kết nối ngoại mạng. Mở tệp cấu hình postgresql.conf trên máy Primary:

# /etc/postgresql/16/main/postgresql.conf
# Chỉ cho phép lắng nghe trên giao diện loopback cục bộ
listen_addresses = 'localhost'
wal_level = replica
max_wal_senders = 10

Tiếp theo, cấu hình tệp pg_hba.conf để chấp nhận kết nối streaming replication đến từ chính localhost. Nên sử dụng cơ chế mã hóa mật khẩu scram-sha-256 để tăng cường tính an toàn, chống lại các cuộc tấn công phát lại (replay attacks).

# /etc/postgresql/16/main/pg_hba.conf
# TYPE    DATABASE        USER               ADDRESS        METHOD
host      replication     replication_user   127.0.0.1/32   scram-sha-256

Truy cập vào PostgreSQL và tạo một role chuyên biệt cho quá trình đồng bộ:

CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'Mat_Khau_Sieu_Bao_Mat_2026!';

Lưu cấu hình và khởi động lại dịch vụ: sudo systemctl restart postgresql.

Bước 2: Hardening SSH Server & giới hạn key authentication

Sử dụng tài khoản quản trị viên hoặc user SSH thông thường để tạo tunnel là một điểm yếu bảo mật. Ta cần cấp phép một tài khoản dịch vụ chuyên biệt (service account) trên máy Primary và thực hiện hardening bảo mật VPS để giới hạn quyền hạn của tài khoản này.

Tạo user hệ thống không có thư mục home và vô hiệu hóa quyền mở shell:

sudo useradd -r -m -s /usr/sbin/nologin pgtunnel

Trên máy Standby, khởi tạo SSH Key (khuyên dùng chuẩn mã hóa Ed25519) và lấy Public Key:

sudo -u postgres ssh-keygen -t ed25519 -f /var/lib/postgresql/.ssh/id_ed25519_tunnel -N ""

Copy Public Key này sang máy Primary, đưa vào tệp /home/pgtunnel/.ssh/authorized_keys. Để khóa chặt tài khoản, bạn bổ sung các tiền tố giới hạn (hardening parameters) ngay trước chuỗi khóa:

restrict,port-forwarding,permitopen="127.0.0.1:5432",command="/bin/false" ssh-ed25519 AAAAC3...

Giải thích thông số:

• restrict: Chặn TTY ảo, chặn Agent/X11 forwarding.
• port-forwarding: Chỉ cho phép tính năng chuyển tiếp cổng.
• permitopen="127.0.0.1:5432": Khóa cứng đích đến. Kẻ tấn công có chiếm được key cũng không thể forward traffic sang các port nhạy cảm khác trong mạng LAN nội bộ.
• command="/bin/false": Ngắt lập tức mọi yêu cầu cố tình gõ lệnh shell.

Bước 3: Thiết lập Local Port Forwarding

Nếu hai VPS kết nối trực tiếp với nhau, bạn sử dụng lệnh mở tunnel như sau trên máy Standby (chạy dưới quyền user postgres):

ssh -f -N -L 127.0.0.1:15432:127.0.0.1:5432 pgtunnel@<Primary_Public_IP> \
  -i /var/lib/postgresql/.ssh/id_ed25519_tunnel \
  -o ExitOnForwardFailure=yes \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3

Trong trường hợp máy Primary nằm trong Private Subnet và phải đi qua một Bastion Host (Jump Server), bạn có thể áp dụng cờ ProxyJump (-J):

ssh -f -N -J bastion_user@<Bastion_Public_IP> \
  -L 127.0.0.1:15432:127.0.0.1:5432 \
  pgtunnel@<Primary_Internal_IP> \
  -i /var/lib/postgresql/.ssh/id_ed25519_tunnel

Bước 4: Chạy Base Backup và thiết lập Streaming Replication qua Tunnel

Lúc này, cổng 15432 cục bộ trên máy Standby đã thông trực tiếp với port 5432 trên Primary. Hãy tiến hành kéo dữ liệu Base Backup.

Dọn dẹp thư mục data cũ trên Standby (Chỉ thực hiện khi chắc chắn không có dữ liệu quan trọng):

sudo rm -rf /var/lib/postgresql/16/main/*

Kéo Base Backup qua cổng Tunnel nội bộ:

sudo -u postgres pg_basebackup \
  -h 127.0.0.1 -p 15432 \
  -U replication_user \
  -D /var/lib/postgresql/16/main \
  -Fp -Xs -P -R

Lưu ý: Bắt buộc sử dụng IP 127.0.0.1 thay vì chữ localhost. Nếu dùng localhost, thư viện PostgreSQL (libpq) sẽ tự động ưu tiên kết nối qua Unix Domain Socket thay vì mạng TCP/IP, dẫn đến lỗi mất kết nối. Cờ -R sẽ tự động tạo tệp cấu hình trỏ primary_conninfo vào host=127.0.0.1 port=15432.

Bước 5: Duy trì đường hầm tự động bằng Native Systemd

Trước đây, giới kỹ thuật thường sử dụng công cụ autossh để giữ cho đường hầm luôn mở. Tuy nhiên, công cụ này hiện được xem là legacy (cũ) và làm tăng độ cồng kềnh cho hệ thống. Các bản phân phối Linux hiện đại quản lý tiến trình rất hiệu quả bằng Native Systemd, kết hợp cùng các tính năng keep-alive tích hợp sẵn của SSH.

Tạo tệp cấu hình dịch vụ /etc/systemd/system/ssh-tunnel-pg.service trên máy Standby:

[Unit]
Description=Native Systemd SSH Tunnel for PostgreSQL Replication
After=network-online.target ssh.service
Wants=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
User=postgres
# Bỏ cờ -f để Systemd quản lý trực tiếp tiến trình chạy foreground
ExecStart=/usr/bin/ssh -N \
    -o "ServerAliveInterval=30" \
    -o "ServerAliveCountMax=3" \
    -o "ExitOnForwardFailure=yes" \
    -o "StrictHostKeyChecking=yes" \
    -i /var/lib/postgresql/.ssh/id_ed25519_tunnel \
    -L 127.0.0.1:15432:127.0.0.1:5432 \
    pgtunnel@<Primary_Public_IP>

# Tự động phục hồi tiến trình nếu mạng bị đứt
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Khi mạng WAN bị gián đoạn, cờ ServerAliveInterval sẽ phát hiện sự cố sau 3 lần mất tín hiệu (90 giây) và ngắt tiến trình SSH. Ngay lập tức, Restart=always của Systemd sẽ kích hoạt chu kỳ kết nối lại.

Kích hoạt dịch vụ:

sudo systemctl daemon-reload
sudo systemctl enable --now ssh-tunnel-pg

Sự phối hợp nhịp nhàng giữa tín hiệu SSH Keep-alive và Native Systemd giúp đường hầm tự động khôi phục khi gặp sự cố rớt mạng.

Tối ưu hiệu năng và vận hành (operations)

Bài toán latency: Asynchronous vs Synchronous Replication xuyên quốc gia

Khi triển khai Multi-Region, khoảng cách địa lý sinh ra độ trễ mạng vật lý. Theo định luật vật lý về tốc độ ánh sáng truyền trong cáp quang, mạng thường trễ khoảng 1ms cho mỗi 100 dặm. Tín hiệu khứ hồi (RTT) giữa hai Region xa nhau có thể lên tới 150ms đến 250ms.

• Nếu áp dụng Synchronous Replication (Đồng bộ), mỗi thao tác ghi dữ liệu (WRITE) của ứng dụng phải chờ gói tin ACK từ Standby gửi về. Khoảng thời gian chờ khứ hồi này sẽ tạo ra tình trạng thắt cổ chai, làm sụt giảm nghiêm trọng throughput của Primary.
• Lựa chọn tối ưu trong môi trường WAN là Asynchronous Replication (Bất đồng bộ). Primary trả kết quả thành công cho Client ngay lập tức sau khi ghi WAL cục bộ. Luồng đồng bộ vẫn âm thầm chạy qua SSH Tunnel ở background, đảm bảo hiệu năng ghi của cơ sở dữ liệu không bị nghẽn.

Cảnh báo nguy cơ tràn ổ cứng (disk full) khi dùng Replication Slots

Replication Slots là tính năng giúp giữ lại các tệp WAL trên Primary, tránh lỗi Standby không thể khôi phục kết nối khi rớt mạng. Tuy nhiên, nếu đường hầm SSH đứt quá lâu, các tệp WAL này sẽ chất đống và làm đầy ổ cứng của máy Primary, dẫn đến nguy cơ sập toàn bộ hệ thống.

Để bảo vệ cụm database, hãy cấu hình các giới hạn an toàn trong postgresql.conf (Primary):

• max_slot_wal_keep_size (Áp dụng từ PG 13): Đặt ngưỡng dung lượng tối đa cho slot (Ví dụ: 50GB). Nếu lượng WAL kẹt vượt mức này, Primary sẽ chủ động drop (đánh rơi) slot để giải phóng không gian lưu trữ, tự cứu bản thân.
• idle_replication_slot_timeout (Tính năng mới trên PG 18): Cho phép cấu hình khoảng thời gian timeout (Ví dụ: 1d). Nếu Standby không phát sinh kết nối tiêu thụ WAL sau 1 ngày, slot sẽ bị giải phóng ngay ở checkpoint tiếp theo.

Duy trì giám sát trạng thái lưu trữ thông qua truy vấn SQL:

SELECT slot_name, active, 
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS wal_lag_size 
FROM pg_replication_slots;

Production security checklist trước khi go-live

Trước khi đưa hệ thống vươn ra môi trường production, đội ngũ vận hành cần thực hiện rà soát nghiêm ngặt bảng kiểm tra (checklist) sau:

• [ ] Tham số listen_addresses trên Primary được khóa đúng vào 'localhost' hoặc '127.0.0.1'.
• [ ] Firewall (UFW/Iptables/Security Groups) đã chặn toàn bộ traffic vào port 5432 từ internet, chỉ mở port 22 cho SSH.
• [ ] Tài khoản SSH dùng cho tunnel được gán shell /usr/sbin/nologin.
• [ ] Tệp authorized_keys đã bổ sung các tiền tố restrict và permitopen giới hạn đích đến.
• [ ] Vô hiệu hóa tính năng xác thực mật khẩu SSH (PasswordAuthentication no trong sshd_config).
• [ ] Đường hầm Tunnel được quản trị tự động bằng Native Systemd.
• [ ] Hệ thống cảnh báo (Ví dụ: Prometheus, Grafana) đã thiết lập Alert rules để theo dõi sự cố gia tăng wal_lag bất thường.

Câu hỏi thường gặp (FAQ)

1. Tại sao lại chọn đồng bộ dữ liệu PostgreSQL qua đường hầm SSH Proxy thay vì thiết lập VPN?

SSH Tunnel hoạt động ở tầng ứng dụng (Userspace), tận dụng OpenSSH có sẵn. Bạn không cần quyền can thiệp mạng sâu ở lớp L3 hay phải cài đặt thêm phần mềm phức tạp như VPN, đồng thời cô lập rủi ro vì chỉ chuyển tiếp đúng port 5432.

2. PostgreSQL đã có Native SSL/TLS, dùng thêm SSH Proxy có thừa thãi không?

Không thừa. Native SSL yêu cầu bạn mở port 5432 ra public internet và phải liên tục quản lý hạ tầng chứng chỉ (PKI). SSH Proxy giúp giấu kín hoàn toàn database khỏi internet và xác thực dễ dàng bằng SSH Key.

3. Chạy qua SSH Tunnel có gây lỗi TCP-over-TCP meltdown không?

Không. OpenSSH hoạt động như một proxy mức ứng dụng. Nó trích xuất dữ liệu thô (raw payload) từ luồng PostgreSQL và đóng gói lại vào kênh SSH, hoàn toàn không lồng ghép các header TCP nguyên bản, giúp triệt tiêu hiện tượng xung đột cửa sổ trượt (sliding window).

4. Dùng đường hầm SSH có làm tăng độ trễ (latency) khi replicate xuyên quốc gia không?

Overhead mã hóa của SSH là rất nhỏ. Độ trễ chủ yếu đến từ khoảng cách vật lý (RTT). Để ứng dụng không bị nghẽn, hãy luôn cấu hình Asynchronous Replication thay vì Synchronous Replication khi chạy multi-region.

5. Làm sao để giữ đường hầm SSH không bị mất kết nối mạng kéo dài?

Tuyệt đối không chạy lệnh SSH thủ công trên terminal. Hãy gói lệnh SSH vào Native Systemd, kết hợp cùng các cờ ServerAliveInterval và ServerAliveCountMax để dịch vụ tự động phục hồi (self-healing) mỗi khi rớt mạng WAN.

6. Cần cấu hình thế nào để chống tràn ổ cứng Primary khi Standby rớt mạng lâu?

Hãy thiết lập giới hạn dung lượng bằng tham số max_slot_wal_keep_size và thời gian chờ bằng idle_replication_slot_timeout trong postgresql.conf. Khi chạm ngưỡng, Primary sẽ chủ động drop slot để giải phóng ổ cứng.

Kết luận

Triển khai đồng bộ dữ liệu PostgreSQL qua đường hầm SSH Proxy là một kỹ thuật vận hành hiệu quả, kết hợp sự tinh gọn của giao thức SSH với khả năng bảo mật cấp cao. Giải pháp này giúp bạn che giấu hoàn toàn các dịch vụ cơ sở dữ liệu cốt lõi khỏi rủi ro rà soát tự động trên mạng công cộng, đồng thời duy trì khả năng luân chuyển dữ liệu linh hoạt, ổn định.

Tất nhiên, nếu hệ thống phát triển với quy mô hàng chục node, kết nối mesh đa chiều giữa hàng loạt microservices, việc thiết lập hạ tầng VPN chuyên sâu như WireGuard để khai thác tốc độ từ Kernel Space sẽ là bước đi phù hợp tiếp theo. Song, đối với các mô hình Primary – Standby liên vùng hiện nay, sức mạnh từ Local Port Forwarding kết hợp cùng Systemd vẫn là một mảnh ghép kiến trúc đáng tin cậy trong cẩm nang của các nhà phát triển.

Tài liệu tham khảo

• PostgreSQL: Documentation: 18: Chapter 26. High Availability, Load Balancing, and Replication
• PostgreSQL: Documentation: 18: 18.11. Secure TCP/IP Connections with SSH Tunnels
• sshd_config(5) – OpenBSD manual pages
• ssh(1) – OpenBSD manual pages
• CIS_PostgreSQL_15_Benchmark_v1.0.0.pdf
• Comparing VPN Protocols: WireGuard vs OpenVPN vs IPsec | CB.VU