Mengapa layanan Linux publik Anda justru membalas melalui VPN

Tidak ada apa pun di socket yang mengingat antarmuka mana yang membawa permintaan, jadi rute default VPN tunnel penuh dapat menangkap balasan yang seharusnya lewat WAN. Layanan itu tidak mengabaikan antarmuka masuk; Linux merutekan balasan yang dibuat secara lokal menurut tujuan dan kebijakan sumber. Aturan berbasis sumber dapat mengirim hanya balasan layanan melalui tabel WAN lengkap, membiarkan lalu lintas keluar biasa tetap di tunnel. Port tetap terbuka sementara balasan keluar lewat jalur yang salah, itulah sebabnya gejalanya tampak sepihak.

Kesalahpahaman: balasan mengikuti antarmuka tempat ia datang

Terdengar logis bahwa paket yang tiba di eth0 harus keluar di eth0. Filter paket tanpa status dapat ditulis begitu, dan tcpdump di sisi masuk menunjukkan permintaan persis di tempat yang diharapkan. Perutean tidak bekerja begitu untuk lalu lintas yang dibuat oleh host sendiri.

Setelah layanan menerima koneksi, balasannya adalah paket baru yang dibuat secara lokal. Kernel memeriksa aturan perutean untuk tujuan dan sumber balasan, dan rute default VPN adalah jawaban yang sepenuhnya sah. Tidak ada apa pun di socket yang mengingat antarmuka mana yang membawa permintaan.

Karena itu gejalanya tampak sepihak: permintaan datang, balasan hilang. Karena itu pula menambahkan aturan firewall untuk port masuk tidak mengubah apa pun. Paket tidak diblokir di jalur masuk; ia dirutekan ke tempat lain di jalur keluar. Lacak balasan dengan pencarian berkualifikasi sumber dan jalan memutarnya menjadi terlihat.

Apa yang sebenarnya dirutekan kernel: alamat sumber

Pegangan yang Anda perlukan adalah alamat lokal yang dipakai layanan untuk balasan. Pada host dengan alamat eth0 ilustratif 192.0.2.10/24 dan gateway 192.0.2.1, alamat itu ada di antarmuka. Pada VM cloud, alamat publik dapat diterjemahkan di hulu dan tidak ada di tamu, jadi gunakan alamat yang benar-benar dipegang host.

Periksa keadaan saat ini sebelum memesan nomor tabel atau prioritas aturan. Aturan kebijakan yang ada dapat menaungi aturan baru, dan tabel lama dengan nomor yang sama mungkin sudah membawa rute tak terkait:

ip -4 addr show dev eth0
ip -4 rule show
ip -4 route show table all

Lalu pilih tabel berdasarkan sumber. Aturan itu cocok untuk balasan yang sudah membawa 192.0.2.10, tepatnya lalu lintas yang berakhir secara lokal yang ingin Anda kecualikan. Lalu lintas yang diteruskan dan paket dari alamat lokal lain tidak cocok.

Bangun tabel balik yang lengkap, bukan setengah rute default

Tabel yang hanya berisi rute default tidak cukup. Kernel masih harus menyelesaikan gateway, dan penyelesaian itu memerlukan prefiks terhubung di tabel yang sama. Tabel yang kehilangan prefiks itu gagal pada penyelesaian gateway meskipun rute defaultnya tampak benar. Tambahkan keduanya, lalu arahkan aturan sumber ke tabel itu:

ip -4 route add table 100 192.0.2.0/24 dev eth0 src 192.0.2.10
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 from 192.0.2.10/32 lookup 100

Gunakan prefiks dan gateway yang sebenarnya, bukan menyalin contoh. Antarmuka cloud yang dikonfigurasi sebagai /32 dengan gateway on-link memerlukan rute terhubung yang berbeda, dan tabel yang dibangun dari prefiks salah gagal pada lompatan pertama. Atribut src menyatakan sumber pilihan untuk rute itu; ia tidak menggantikan aturan sumber.

Urutan juga penting. Aturan luas dengan nomor prioritas lebih rendah dievaluasi lebih dulu, jadi aturan sumber harus dicapai sebelum aturan apa pun yang akan mengirim lalu lintas ini kembali ke tabel utama. Periksa prioritas dengan ip rule show setelah menambahkannya, bukan hanya saat boot.

Verifikasi dengan pencarian berkualifikasi sumber

Minta kernel merutekan tujuan uji dari alamat layanan. Jawabannya harus menyebut eth0 dan gateway WAN, bukan tunnel:

ip -4 route get 198.51.100.25 from 192.0.2.10

Lalu buat koneksi resmi baru dan amati kedua arah. Pencarian yang memilih tabel yang benar sementara koneksi langsung masih gagal menunjuk ke penyaringan jalur balik atau aturan firewall, bukan ke tabel. Periksa kendali itu sebelum menonaktifkan apa pun secara global.

Letakkan rute akhir dan aturan di bawah manajer jaringan yang memiliki antarmuka. Perubahan alamat, pembaruan DHCP, dan sambungan ulang VPN semuanya menulis ulang keadaan kernel, dan aturan yang ditambahkan dengan tangan hilang atau menunjuk ke gateway usang setelah peristiwa berikutnya.

Di mana pengecualian ini berhenti

Aturan itu mengecualikan lalu lintas yang berakhir secara lokal dari satu alamat sumber. Ia tidak mencakup port yang diterbitkan Docker, DNAT, atau layanan yang diteruskan melalui host, karena paket itu dirutekan sebagai lalu lintas diteruskan dan tidak pernah membawa sumber lokal host dengan cara yang sama. Desain semacam itu biasanya memerlukan tanda yang dipasang saat masuk dan aturan yang cocok dengan tanda itu.

Ia juga tidak membuat alamat publik host muncul di antarmuka. Ketika NAT di hulu memiliki alamat itu, balasan tetap harus keluar melalui jalur yang diharapkan NAT itu, itulah sebabnya tabel WAN harus mencerminkan gateway dan prefiks asli, bukan rentang publik yang ditebak.

Pelihara pengecualian itu terdokumentasi dengan nomor tabel, prioritas aturan, dan alamat sumber yang tepat. Perubahan berikutnya pada VPN atau antarmuka dapat mematahkannya tanpa suara, dan catatan yang menyebut ketiga nilai itu lebih cepat diperiksa daripada menemukan ulang gejalanya dari laporan pelanggan.

Jika layanan masih membalas di jalur yang salah setelah pencarian berkualifikasi sumber lolos, bandingkan alamat sumber socket yang hidup dengan yang ada di aturan. Layanan yang terikat ke alamat wildcard dapat memilih sumber berbeda dari alamat yang Anda uji, dan ketidakcocokan itulah celah yang tersisa.