Cara memodelkan alur VPN dengan ASA packet-tracer

Packet-tracer pada ASA menjawab pertanyaan sempit: apakah paket ini, yang masuk di sini dengan tuple ini, akan diizinkan, dan ke mana ia akan pergi. Ia tidak menjawab apakah ujung jauh menerima apa pun. Kesalahan umum adalah memberi tuple IKE luar padahal yang ingin diuji adalah aplikasi yang berjalan di dalam terowongan. Perbaiki dulu tuple, baca fasenya, lalu kumpulkan bukti nyata untuk semua yang tidak dapat dilihat simulator.

Penelusuran di bawah mengasumsikan ACL, aturan NAT, dan konteks tunnel-group ada di depan Anda. Tanpanya, keluaran menjelaskan kebijakan yang tidak dapat Anda periksa.

Langkah 1: tulis alur dalam dengan kata-kata sederhana

Jelaskan aplikasinya sebelum mengetik apa pun. Host di dalam yang membuka SSH ke server di belakang gateway jauh adalah satu alur TCP dalam dengan port sumber tertentu. Itulah alur yang dinilai ACL dan filter VPN, jadi itulah alur yang Anda ketik.

Tulis sebagai satu kalimat, lalu terjemahkan bidang demi bidang:

packet-tracer input inside tcp 10.30.0.25 53000 10.40.0.50 22 detailed

Langkah 2: pilih ingress dan arahnya

Ingress adalah antarmuka tempat paket tiba, bukan antarmuka yang dilewatinya keluar. Untuk host LAN yang memulai, itu antarmuka inside. Untuk paket balasan sesi yang sama, itu antarmuka outside, dan tuple-nya berbalik. Mengetik tujuan sebagai sumber adalah cara kedua paling umum untuk mendapatkan ALLOW yang meyakinkan tetapi tidak relevan.

Port juga punya arah. Port layanan berada di bidang tujuan untuk permintaan yang dimulai, dan port efemeral klien berada di bidang sumber. Model dengan tujuan TCP 500 menjelaskan aplikasi TCP yang mendengarkan pada 500; ia tidak menjadi uji IKE hanya karena angka itu muncul di perintah.

Langkah 3: baca fasenya secara berurutan

Setiap fase dalam keluaran adalah keputusan dengan pemilik: pencarian rute, ACL, NAT, lalu pemilihan VPN atau terowongan. Bacalah sesuai urutan yang tercetak dan berhenti pada fase pertama yang tidak sesuai dengan rancangan.

NAT sering menjebak orang. Jika sumber yang diterjemahkan jatuh di luar crypto ACL yang memilih lalu lintas untuk terowongan, alur dapat diizinkan dan tidak pernah dienkapsulasi. Jejak mencetak alamat yang diterjemahkan, jadi bandingkan dengan lalu lintas menarik terowongan, bukan dengan alamat asli.

Langkah 4: periksa lewatan mana yang Anda pilih

Bentuk detailed menerima opsi yang melewati pemeriksaan, dan Cisco mendokumentasikan opsi bypass-checks yang mencakup ACL, filter VPN, uRPF, dan pemeriksaan pemalsuan IPsec. ALLOW yang diperoleh dengan lewatan itu mengatakan rute dan NAT akan bekerja, bukan bahwa kebijakan akan menerima paket nyata. Catat opsinya di samping hasil.

Jika Anda memerlukan jawaban kebijakan, jalankan tanpa lewatan. Jika Anda mengisolasi pertanyaan perutean, jalankan dengannya dan beri label hasilnya sebagai jawaban perutean.

Langkah 5: tutup celah dengan pertukaran nyata

Izin tersimulasi berhenti di ASA. Apakah gateway jauh mendekripsi paket, apakah server menerima koneksi, dan apakah balasan kembali adalah pengamatan terpisah. Gunakan penghitung titik akhir atau tangkapan sempit pada jalur yang disetujui.

Beberapa opsi trace dan replay mengirimkan paket atau menyimpan status. Ikuti perilaku terdokumentasi untuk rilis dan prosedur diagnostik Anda yang disetujui alih-alih memperlakukan setiap varian sebagai pencarian hanya-baca.

Apa yang masih tidak dapat dikatakan jejak

Simpan empat hal dalam satu catatan: tuple, aturan NAT yang cocok, terowongan atau kebijakan yang seharusnya membawa alur, dan pengamatan khusus arah. Tanpanya, insinyur berikutnya tidak dapat memisahkan keputusan kebijakan lokal dari bidang kendali yang sudah mapan dan dari layanan yang berfungsi. Kegagalan pertama yang diikuti keberhasilan juga bukan bukti bahwa terowongan harus naik di antaranya; catat fasenya dan perubahan status.

Mulai dari tuple dalam, berhenti pada fase pertama yang bertentangan dengan rancangan, dan baru setelah itu jangkau bukti titik akhir. Jejak adalah orakel kebijakan, bukan tanda terima pengiriman.