Perluasan situs VPN: ikuti rute balik melewati gateway

Lalu lintas dari cabang berakhir di gateway yang LAN-nya tidak memuat aplikasi yang diminta Anda capai. Server berada di pusat data kedua, di seberang tautan internal yang tidak pernah dikonfigurasi VPN. Menambahkan prefiks lain ke gateway terdekat tidak melakukan apa pun untuk kasus itu, karena gateway jauh adalah titik akhir enkripsi, bukan router terakhir. Jalur itu membutuhkan rute lanjutan, penerimaan di batas keamanan jauh, dan keputusan balik di jaringan tujuan itu sendiri.

Gateway jauh adalah titik akhir enkripsi

IPsec gateway-ke-gateway melindungi lalu lintas antara dua perangkat keamanan, dan alamat internal melintasi segmen itu dalam keadaan terenkripsi. Di luar gateway jauh, perutean biasa mengambil alih, termasuk kebijakan apa pun yang ada antar pusat data. Segmen yang dilindungi karena itu mencakup sebagian perjalanan dan bukan sisanya. Menganggap sebaliknya adalah cara sebuah desain berakhir dengan terowongan yang sehat dan aplikasi yang tak terjangkau.

Gambarkan jalur dalam tiga bagian: cabang ke gateway dekat, dekat ke gateway jauh, gateway jauh ke aplikasi. Setiap bagian punya pemiliknya sendiri dan mode kegagalannya sendiri.

Baca kedua arah kebijakan terowongan

Kebijakan terowongan biasanya ditulis dari sudut pandang sisi lokal, dan dari kebiasaan itulah konfigurasi sebagian muncul. Kedua peer harus mencantumkan sumber cabang dan tujuan sebagaimana akan tampak di dalam terowongan, termasuk terjemahan apa pun yang dimaksudkan desain. Memperbarui hanya ujung dekat menghasilkan ketidakcocokan fase dua yang tampak seperti kegagalan perutean. Bandingkan kedua kumpulan kebijakan sebelum menyentuh rute mana pun.

Tulis sumber dan tujuan sebagai alamat, bukan nama situs. Ambiguitas di sini muncul lagi nanti sebagai asimetri yang membingungkan.

Tambahkan rute lanjutan dan pastikan penerimaan

Gateway jauh membutuhkan rute menuju subnet aplikasi, dan setiap router di antaranya harus menerima sumber cabang. Verifikasi apa yang sebenarnya dimiliki gateway jauh, bukan apa yang diklaim diagram.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Perintah pertama melaporkan antarmuka keluar dan hop berikutnya yang akan dipilih gateway jauh untuk sumber itu, pertanyaan yang tidak dapat dijawab tabel perutean biasa. Jejak menunjukkan tempat paket berhenti, dan pemutusan setelah gateway jauh menunjuk ke transit internal, bukan ke terowongan. Ketika rute ada dan lalu lintas tetap hilang, tangkap di gateway jauh dan baca alamat sumber yang datang, karena alamat tak terduga berarti terjemahan terjadi di suatu tempat yang tidak direncanakan. Semua alamat di sini adalah placeholder, jadi ganti dengan subnet cabang, transit, dan aplikasi yang sebenarnya.

Uji dari cabang, lalu uji ulang jalur lama

Penerimaan membutuhkan sumber nyata, bukan pemeriksaan dari gateway jauh. Jalankan pemeriksaan dari host cabang dan pertahankan tujuan yang sebelumnya berfungsi dalam pengujian yang sama.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Respons dari aplikasi membuktikan jalur maju dan jalur balik sekaligus, sedangkan ping ke tujuan lama membuktikan perubahan tidak merusak apa yang sudah berfungsi. Tangkap alamat sumber yang dicatat aplikasi, karena aturan aksesnya dan rute balik apa pun harus cocok dengan nilai itu. Di tempat cabang menerjemahkan sebelum terowongan, alamat kebijakan dan alamat yang dilihat aplikasi berbeda menurut desain, jadi catat keduanya. Ulangi pengujian setelah pembaruan kunci atau perubahan perutean, karena jalur ini cenderung divalidasi sekali lalu dilupakan.

Tetapkan pemilik untuk masing-masing dari tiga segmen dan untuk rute balik di dalam jaringan tujuan. Jalur dengan empat pemilik gagal di celah di antara mereka.