Sedikit perencanaan konfigurasi 'belt and braces'.
Latar Belakang:
Kami memiliki tautan VPN situs-ke-situs yang berhasil ke pusat data jarak jauh kami.
Jaringan 'terproteksi' jarak jauh juga merupakan jangkauan jaringan IP yang dibuka melalui firewall karena Internet menghadapi titik akhir.
Jadi : Kami menggunakan VPN sehingga kami dapat mengakses titik akhir non-publik.
Pernyataan Masalah :
Jika tautan VPN sedang down, ASA menurunkan lalu lintas, meskipun titik akhir Internet masih harus tersedia melalui firewall jarak jauh.
Pertanyaan :
Bagaimana saya bisa mengkonfigurasi VPN untuk 'melewatkan' lalu lintas sebagai lalu lintas keluar biasa, ketika VPN sedang down.
Berikut adalah segmen-segmen terkait dari konfigurasi.
crypto map vpn-crypto-map 20 match address remdc-vpn-acl
crypto map vpn-crypto-map 20 set peer a.b.c.d
crypto map vpn-crypto-map 20 set transform-set remdc-ipsec-proposal-set
crypto map vpn-crypto-map interface outside
ACL untuk mencocokkan lalu lintas sangat primitif: ini menentukan dua jaringan, pribadi dan jarak jauh, dinyatakan sebagai objek jaringan.
access-list remdc-vpn-acl extended permit ip object <private> object <remote> log
Dan diagram primitif.
INTERNET
x
x
REM DC 203.000.113.000/24 xx HQ 192.168.001.000/24
x
+---------------+ x +-----------+
| REMOTE DC | xx | |
| ASA e xxx | ASA 5505 |
+----------+ | xx | +-----------------+
^ | e<-------------------------------------+ |
| | | xxxx | |
| | e xxxx | ~ |
| | | xx | | |
| | | xx +----vpn----+
| | | x |
\-------vpn-------------vpn--------------------------------------/
| | xxx
+---------------+ xx
xxx
xx
xxxx
e = public Internet x
server endpoint
Terima kasih
rampok
Perbarui 01
ACL yang lebih tepat telah dibahas dalam komentar di bawah ini (dengan terima kasih)
Saya dapat membayangkan dua ACLS. (A) yang memungkinkan SEMUA ke jaring jarak jauh, dan kemudian menolak titik akhir yang sudah tersedia melalui Internet. dan (B) yang membuka hanya manajemen / instrumentasi sesuai kebutuhan.
Masalah dengan (B) adalah bahwa mengekspresikan titik akhir seperti WMI & Windows RPC tidak praktis tanpa mengubah konfigurasi server standar)
Jadi, mungkin (A) adalah pendekatan terbaik yang menjadi kebalikan dari konfigurasi firewall jarak jauh .
Perbarui 02
Mike telah meminta untuk melihat lebih banyak dari konfigurasi ios ASA.
Berikut ini adalah untuk HQ ASA yang ada di situs HQ. DC jarak jauh berada di bawah kendali penyedia pusat data, jadi saya tidak dapat mengomentari dengan pasti bagaimana hal itu dapat dikonfigurasi.
Yah, tidak banyak yang bisa ditampilkan: Ada satu rute default ke gateway Internet, dan tidak ada rute spesifik lainnya.
route outside 0.0.0.0 0.0.0.0 HQInetGateway 1
Antarmuka sangat mendasar. Hanya konfigurasi dan vlan IPv4 dasar untuk membagi grup menjadi 1 antarmuka luar dan 1 antarmuka dalam.
interface Vlan1
nameif inside
security-level 100
ip address 10.30.2.5 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 194.28.139.162 255.255.255.0
!
Ceria, Rob
Jawaban:
Saya sekarang berpendapat bahwa ini tidak praktis; setidaknya dalam skenario khusus kami.
Skema ini semakin diperumit oleh kenyataan bahwa lalu lintas "ke terowongan" dipilih oleh ACL antara HQ dan RemoteDC, (sehingga kita dapat menjadikannya serumit yang kita inginkan), tetapi pada "jalur" sebaliknya (dengan kata lain) Konsentrator VPN di ujung jarak jauh memilih seluruh jaringan HQ sebagai jaringan yang dilindungi.
Hasilnya adalah ini tidak seimbang dan tampak bahwa x maju dan mundur tidak cocok. Mirip dengan memiliki rute maju dan mundur yang menyebabkan lalu lintas gagal karena NAT sedang bermain di beberapa titik.
Pada dasarnya - ini dihapus sebagai "risiko teknis yang terlalu tinggi" dan membutuhkan lebih banyak evaluasi dan mungkin lebih banyak kontrol atas ujung jarak jauh sebelum menjadi solusi.
Terima kasih untuk semua yang melihat ini.
sumber
Jika Anda memiliki atau dapat menginstal router di bagian dalam setiap ASA, Anda dapat membuat terowongan GRE terenkripsi dan menggunakan perutean atau statis mengambang untuk gagal ke Internet.
sumber