Perluasan tapak VPN: ikut laluan balik melepasi gateway

Trafik dari cawangan berakhir pada gateway yang LAN-nya tidak mengandungi aplikasi yang diminta anda capai. Pelayan terletak di pusat data kedua, di seberang pautan dalaman yang tidak pernah dikonfigurasikan oleh VPN. Menambah awalan lain pada gateway berdekatan tidak melakukan apa-apa untuk kes itu, kerana gateway jauh ialah titik akhir penyulitan, bukan penghala terakhir. Laluan itu memerlukan laluan ke hadapan, kemasukan di sempadan keselamatan jauh dan keputusan balik dalam rangkaian destinasi itu sendiri.

Gateway jauh ialah titik akhir penyulitan

IPsec gateway-ke-gateway melindungi trafik antara dua peranti keselamatan, dan alamat dalaman merentasi segmen itu dalam keadaan disulitkan. Di luar gateway jauh, penghalaan biasa mengambil alih, termasuk apa-apa dasar yang wujud antara pusat data. Segmen yang dilindungi itu meliputi sebahagian perjalanan dan bukan selebihnya. Menganggap sebaliknya ialah cara sesuatu reka bentuk berakhir dengan terowong yang sihat dan aplikasi yang tidak dapat dicapai.

Lukis laluan dalam tiga bahagian: cawangan ke gateway berdekatan, berdekatan ke gateway jauh, gateway jauh ke aplikasi. Setiap bahagian mempunyai pemiliknya sendiri dan mod kegagalannya sendiri.

Baca kedua-dua arah dasar terowong

Dasar terowong biasanya ditulis dari sudut pandangan pihak tempatan, dan daripada tabiat itulah konfigurasi separa muncul. Kedua-dua rakan mesti menyenaraikan sumber cawangan dan destinasi seperti yang akan muncul di dalam terowong, termasuk apa-apa terjemahan yang dimaksudkan oleh reka bentuk. Mengemas kini hanya hujung berdekatan menghasilkan ketidakpadanan fasa dua yang kelihatan seperti kegagalan penghalaan. Bandingkan kedua-dua set dasar sebelum menyentuh mana-mana laluan.

Tulis sumber dan destinasi sebagai alamat dan bukan nama tapak. Kekaburan di sini muncul semula kemudian sebagai asimetri yang mengelirukan.

Tambahkan laluan ke hadapan dan sahkan kemasukan

Gateway jauh memerlukan laluan ke subrangkaian aplikasi, dan setiap penghala di antaranya mesti membenarkan sumber cawangan. Sahkan apa yang sebenarnya dimiliki gateway jauh dan bukan apa yang didakwa oleh rajah.

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 antara muka keluar dan hop seterusnya yang akan dipilih oleh gateway jauh untuk sumber itu, soalan yang tidak dapat dijawab oleh jadual penghalaan biasa. Jejak menunjukkan di mana paket berhenti, dan pemutusan selepas gateway jauh menunjukkan transit dalaman dan bukan terowong. Apabila laluan wujud dan trafik masih hilang, tangkap di gateway jauh dan baca alamat sumber yang tiba, kerana alamat tidak dijangka bermakna terjemahan berlaku di suatu tempat yang tidak dirancang. Semua alamat di sini ialah pemegang tempat, jadi gantikan subrangkaian cawangan, transit dan aplikasi yang sebenar.

Uji dari cawangan, kemudian uji semula laluan lama

Penerimaan memerlukan sumber sebenar dan bukan siasatan dari gateway jauh. Jalankan semakan dari hos cawangan dan kekalkan destinasi yang sebelum ini berfungsi dalam ujian yang sama.

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

Respons daripada aplikasi membuktikan laluan ke hadapan dan laluan balik bersama-sama, manakala ping ke destinasi lama membuktikan perubahan itu tidak merosakkan apa yang sudah berfungsi. Tangkap alamat sumber yang dilog oleh aplikasi, kerana peraturan aksesnya dan mana-mana laluan balik mesti sepadan dengan nilai itu. Di tempat cawangan menterjemah sebelum terowong, alamat dasar dan alamat yang dilihat oleh aplikasi berbeza mengikut reka bentuk, jadi catat kedua-duanya. Ulangi ujian selepas pembaharuan kunci atau perubahan penghalaan, kerana laluan ini cenderung disahkan sekali dan kemudian dilupakan.

Tetapkan pemilik kepada setiap satu daripada tiga segmen dan kepada laluan balik di dalam rangkaian destinasi. Laluan dengan empat pemilik gagal di celah-celah antara mereka.