Belajar HAProxy - Layer 4 Proxy & TCP Routing

#Pendahuluan

Tidak semua layanan berbahasa HTTP. Database, Redis, memcached, dan banyak protokol legacy butuh proxy yang tidak ikut campur dengan isi byte. Untuk itu HAProxy punya mode TCP yang sangat mumpuni.

Episode 12 membedah mode TCP: apa bedanya dengan HTTP, cara memproxying layanan raw, dan bagaimana inspeksi SNI memungkinkan routing berbasis nama domain tanpa membuka data terenkripsi. Kemampuan ini membuat HAProxy melayani hampir semua protokol.

#TCP Mode vs HTTP Mode

#Batas Kemampuan Tiap Mode

Perbandingan singkat yang harus diingat:

• Mode TCP: HAProxy hanya meneruskan byte. Overhead rendah, cocok untuk protokol apa pun.
• Mode HTTP: HAProxy memahami request dan response, bisa routing berdasarkan isi, memodifikasi header, dan menjaga session.

Keputusan utamanya sederhana: kalau kalian tidak perlu melihat isi protokol, pakai TCP. Lebih cepat dan lebih aman karena tidak menginterpretasi data.

#Konsekuensi Pemilihan Mode

Dalam mode TCP, fitur yang bergantung pada HTTP tidak tersedia:

• Tidak ada http-request, use_backend berbasis path, atau rewrite header.
• Routing hanya bisa memakai metadata jaringan: source IP, destination port, atau SNI.
• Session affinity bisa memakai stick table dengan src, bukan cookie.

frontend redis_front
    bind *:6379
    mode tcp
    default_backend redis_back
 
backend redis_back
    balance leastconn
    server redis1 10.0.0.21:6379 check
    server redis2 10.0.0.22:6379 check

Direktif mode tcp di kedua section menandakan penerusan byte mentah. Health check TCP default hanya membuka koneksi dan menutupnya kembali.

#Proxying Layanan Raw

#Database PostgreSQL

Database adalah contoh paling umum. Klien aplikasi terhubung ke HAProxy, lalu koneksi diteruskan ke primary dan replica:

frontend pg_front
    bind *:5432
    mode tcp
    default_backend pg_back
 
backend pg_back
    balance source
    option tcp-check
    tcp-check connect
    tcp-check send "select 1;\n"
    tcp-check expect string "1"
    server pg1 10.0.0.31:5432 check
    server pg2 10.0.0.32:5432 check

option tcp-check mengaktifkan health check berlapis TCP: HAProxy mengirim select 1; dan mengharapkan jawaban mengandung 1. Ini health check yang jauh lebih bermakna daripada sekadar koneksi terbuka.

#Redis dan Koneksi Panjang

Untuk Redis, gunakan leastconn agar koneksi yang dipegang lama tidak menumpuk di satu server:

backend redis_back
    balance leastconn
    option tcp-check
    tcp-check connect
    tcp-check send PING\r\n
    tcp-check expect string +PONG
    server redis1 10.0.0.41:6379 check
    server redis2 10.0.0.42:6379 check

tcp-check send PING\r\n dan tcp-check expect string +PONG memverifikasi bahwa Redis benar-benar merespons sebelum dianggap sehat.

#gRPC dalam Mode TCP

Jika kalian tidak butuh routing berdasarkan service method, gRPC bisa diproxy murni di layer 4 dengan multiplexing HTTP/2 yang diteruskan apa adanya:

frontend grpc_front
    bind *:8443
    mode tcp
    default_backend grpc_back
 
backend grpc_back
    balance leastconn
    server grpc1 10.0.0.51:8443 check
    server grpc2 10.0.0.52:8443 check

Mode TCP menjaga koneksi HTTP/2 tetap utuh dari klien ke server. Tidak ada buffer atau interpretasi yang bisa mengganggu stream.

#SNI Inspection dan TLS Passthrough

#Memahami TLS Passthrough

TLS passthrough berarti HAProxy tidak memutus enkripsi: handshake TLS terjadi langsung antara klien dan backend. HAProxy hanya melihat bagian yang tidak terenkripsi, yaitu nama server di handshake (SNI).

Keuntungannya: kunci privat tidak pernah berada di HAProxy, dan trafik tetap dienkripsi end-to-end.

#Routing Berbasis SNI

SNI di-inspeksi di mode TCP untuk memilih backend:

frontend tls_front
    bind *:443
    mode tcp
 
    acl sni_db req.ssl_sni -i db.example.com
    acl sni_app req.ssl_sni -i app.example.com
 
    use_backend db_back if sni_db
    use_backend app_back if sni_app
    default_backend app_back
 
backend db_back
    server db1 10.0.0.61:443 check
 
backend app_back
    server app1 10.0.0.62:443 check

acl sni_db req.ssl_sni -i db.example.com mencocokkan nama server yang diminta klien. Pastikan frontend mengaktifkan parsing SNI dengan accept-proxy atau sekedar langsung di mode TCP, lalu use_backend db_back if sni_db mengarahkan trafik.

#Memverifikasi dengan openssl

openssl s_client -connect localhost:443 -servername db.example.com \
  </dev/null 2>/dev/null | openssl x509 -noout -subject

openssl s_client -connect localhost:443 -servername db.example.com membuka handshake TLS dengan SNI tertentu. Jika routing benar, sertifikat yang keluar harus milik backend database.

#Pertimbangan Desain

#Kapan Passthrough dan Kapan Termination

Panduan praktisnya:

• Passthrough: keamanan maksimal, backend menangani TLS, tidak ada inspeksi isi. Cocok untuk regulatory requirement dan kinerja tertinggi.
• Termination: HAProxy memegang sertifikat, bisa rewrite, routing berbasis HTTP, dan mengelola sertifikat terpusat. Cocok untuk sebagian besar web app.

Banyak arsitektur mencampur keduanya: termination di edge untuk web, passthrough untuk layanan internal.

nc -zv localhost 6379

nc -zv localhost 6379 menguji apakah port TCP terbuka. Jika koneksi berhasil, mode TCP bekerja; lalu uji protokolnya langsung lewat klien masing-masing.

#Penutup

Episode 12 membuka dunia layer 4: mode TCP untuk protokol raw, health check berbasis protokol dengan tcp-check, serta SNI dan TLS passthrough untuk routing yang aman dan efisien.

Inti yang harus dibawa pulang:

• mode tcp meneruskan byte; mode http memahami isi protokol.
• Database dan Redis memakai option tcp-check untuk health check yang bermakna.
• balance leastconn untuk koneksi berumur panjang seperti Redis dan gRPC.
• TLS passthrough menjaga trafik terenkripsi end-to-end.
• req.ssl_sni memungkinkan routing berbasis nama domain tanpa membuka isi.

Di episode 13 selanjutnya kita akan membahas high availability & clustering — setup active/passive dengan VRRP dan Keepalived, integrasi service discovery seperti Consul dan DNS, serta pengujian failover dan recovery.