Dua pertanyaan menjadi kusut setiap kali L2TP, GRE, dan IPsec mendarat di catatan desain yang sama: sesi mana yang saya bawa, dan lapisan mana yang melindunginya? Salah menjawab yang pertama membuat semua di hilir tetap konsisten secara internal sambil memecahkan masalah yang salah — overlay terutekan dibangun di tempat pengguna seharusnya dial-in, atau konsentrator dial-in menggantikan gateway situs-ke-situs. Lembar kerja di bawah memaksa pembedaan itu sebelum siapa pun masuk ke perangkat. Isi berurutan dan setiap baris menjadi sesuatu yang bisa diuji sendiri.

Mulai dari sesi, bukan dari daftar protokol

Pengguna jarak jauh yang memegang sesi PPP dan overlay terutekan di antara dua gateway adalah dua hubungan jaringan yang berbeda, bahkan ketika keduanya akhirnya dibungkus IPsec. Yang pertama menamatkan tautan per pengguna dan memerlukan penetapan alamat, autentikasi orang atau perangkat, serta kebijakan yang menyebut jaringan internal mana yang boleh dijangkau pengguna itu. Yang kedua meneruskan paket di antara situs yang tidak didial siapa pun.

Tulis satu kalimat yang menyebut mana dari keduanya yang Anda bangun, lalu bacalah kembali seolah Anda orang yang harus mengoperasikannya. Jika kalimat itu membutuhkan kata 'dan', Anda membangun keduanya, dan lembar kerja memerlukan dua kolom alih-alih satu kolom kompromi yang melayani masing-masing setengah. Jika kalimat itu menyebut pengguna tetapi tidak ada kumpulan alamat, atau prefiks tetapi tidak ada kebijakan penerusan, kalimat itu masih belum lengkap. Kata-katanya terdengar birokratis, tetapi itu tempat termurah untuk menangkap desain yang kalau tidak akan ditemukan oleh tiket meja bantuan.

Beri setiap lapisan tepat satu tugas

L2TPv2 membawa sesi PPP di antara dua ujungnya. PPP menjalankan negosiasi tautan dan, ketika dinegosiasikan, autentikasi pengguna; L2TP tidak menambahkan kriptografi, jadi daemon L2TP telanjang tidak menerapkan bagian apa pun dari hubungan keamanan IPsec dan hanya berada di dalam tautan yang sudah Anda percayai.

GRE adalah enkapsulasi antara dua alamat. Ia membawa paket lapisan jaringan melintasi overlay logis dan, dengan sendirinya, tidak menawarkan kerahasiaan maupun identitas rekan yang terautentikasi. Itu bukan cacat: header dirancang sederhana agar tetap murah diproses pada perangkat keras penerusan. Konsekuensinya, GRE menjawab 'bagaimana saya memindahkan paket ini antara dua alamat' dan tidak lebih, yang justru pertanyaan yang harus Anda ajukan kepadanya.

Itu menyisakan IPsec sebagai lapisan yang memilih lalu lintas, mengautentikasi rekan, dan mengenkripsi apa yang diperintahkan untuk dilindungi. Lalu lintas mana yang dilindungi adalah keputusan konfigurasi yang harus cocok dengan enkapsulasi yang benar-benar dihasilkan ujung-ujungnya, karena kebijakan yang ditulis untuk alamat luar GRE berperilaku berbeda dari yang ditulis untuk prefiks dalam. Spesifikasi GRE menjaga muatan, header GRE, dan protokol pengiriman luar tetap terpisah secara kasat mata, dan kebijakan Anda memerlukan pemisahan yang sama.

LayerIts one jobWhat it never does
PPPLink negotiation, optional user authentication, address assignmentProtect traffic between gateways
L2TPv2Carry the PPP session between two endpointsEncrypt or authenticate peers
GREEncapsulate network-layer packets between two addressesHide or authenticate the payload
IPsecAuthenticate peers and encrypt selected trafficCarry a dial-in user session by itself

Tulis jalur paket sebelum konfigurasi

Ambil satu paket dan daftarkan setiap header yang ditambahkan, dalam urutan penambahannya, sambil menyebut perangkat yang menambahkannya. Untuk pengguna dial-in biasanya PPP di dalam L2TP di dalam IPsec; untuk overlay situs, paket IP dalam di dalam GRE di dalam IPsec. Jika dua perangkat menambahkan header yang sama, Anda punya loop atau terowongan ganda, dan tidak ada penyuntingan kebijakan yang memperbaikinya.

Daftar yang sama menentukan MTU, karena ukuran dalam yang dapat dipakai adalah MTU jalur terukur dikurangi header yang baru saja Anda daftar dan tidak ada yang lain. Jangan menyalin angka dari posting forum: jumlahkan overhead IP luar, UDP, dan ESP, lalu GRE atau L2TP, lalu PPP bila berlaku, dan kurangkan dari MTU jalur yang benar-benar Anda ukur. Gejala yang hanya muncul pada transfer besar, atau sesi yang terbentuk lalu mati pada respons besar pertama, biasanya kembali ke penjumlahan yang dilakukan dengan kira-kira.

Periksa setiap lapisan terpisah, dari luar ke dalam

Jalankan pemeriksaan secara berurutan dan berhenti pada yang pertama gagal. Setiap baris menjawab pertanyaan berbeda, jadi kegagalan menunjuk satu kolom lembar kerja alih-alih memberi tahu bahwa terowongan rusak.

ip xfrm state                  # is the IPsec SA up?
ip -s link show gre1           # does the overlay interface carry packets?
ip route get 10.20.0.5         # does the inner prefix route where you think?
ss -lun | grep -E "1701|4500"  # are the L2TP and NAT-T listeners bound?

Pada perangkat Cisco padanannya bergantung pada peran, dan sintaks persisnya bergantung pada platform dan rilis: show crypto session untuk rekan IPsec, penghitung antarmuka untuk antarmuka GRE atau terowongan, dan verifikasi VPDN atau PPP untuk peran dial-in. Sekumpulan perintah yang menamatkan PPP tidak membuktikan apa pun tentang dukungan GRE, dan antarmuka GRE yang berfungsi tidak membuktikan apa pun tentang layanan PPP, jadi verifikasi peran yang benar-benar Anda konfigurasi, bukan yang ada di diagram.

Catat setiap keluaran di samping baris lembar kerja tempatnya berada. Catatan yang diambil saat gangguan masih aktif lebih bernilai daripada topologi yang digambar ulang belakangan dari ingatan.

Urutkan pembongkaran, lalu verifikasi ulang

Pembongkaran berjalan terbalik karena suatu alasan: keluarkan lalu lintas yang dilindungi dari kebijakan IPsec sebelum Anda menghapus enkapsulasi yang menjadi dasar kebijakan itu ditulis, atau kebijakan akan terus menunjuk antarmuka yang sudah tidak ada dan pemuatan konfigurasi berikutnya gagal di tempat yang tampak tidak terkait. Di Linux itu berarti menghapus entri state dan policy sebelum antarmuka terowongan; di router, menghapus entri crypto map atau profile sebelum terowongan.

Setelah pembangunan ulang, ulangi empat pengamatan penerimaan satu per satu: keterjangkauan luar, asosiasi IPsec yang terbentuk, sesi PPP yang terbentuk bila desain memuatnya, dan penerusan dalam ke alamat tujuan nyata. Satu lampu hijau bukan bukti bagi tiga lainnya, dan celah itulah kegagalan yang paling lama bertahan di produksi — terowongan yang menyala, terenkripsi, dan tidak meneruskan apa pun karena rute dalam tidak pernah ditambahkan.

Simpan lembar kerja yang sudah diisi di samping konfigurasi perangkat. Kolom mana pun yang tidak dapat Anda isi adalah lapisan tanpa tugas yang ditetapkan, dan lapisan tanpa tugas biasanya lapisan yang seharusnya tidak ada di tumpukan.

Artikel terkait