IPSec yang sulit dengan Linux

Mengembangkan infrastruktur TI, cepat atau lambat, tugas tersebut datang untuk berintegrasi dengan layanan apa pun dari organisasi besar. Ini mungkin, misalnya, bank atau operator telekomunikasi. Sebagai aturan, organisasi besar telah menetapkan kebijakan keamanan informasi, yang secara khusus memerlukan implementasi layanan dengan infrastruktur di luar mereka melalui saluran terenkripsi - IPSec. Pada saat yang sama, dalam organisasi startup kecil tidak ada pengalaman dalam mengatur skema seperti itu, dan dari peralatan hanya ada VDS dengan Linux. Terlebih lagi, yang mengejutkan saya, praktis tidak ada materi dalam Runet yang menggambarkan alat pemecahan masalah Linux. Mari kita coba untuk menghilangkan celah ini dan menggambarkan bagian praktis dari pengaturan.

Skema umum layanan disajikan di bawah ini. Sebagai aturan, dalam organisasi besar, semuanya sudah terstandarisasi, diaktifkan, segala macam kemungkinan enkripsi dan potongan jaringan lainnya dilakukan pada peralatan terpisah (tsiska-juniper dan lainnya seperti mereka), dan, yang lebih penting, oleh individu (mungkin setiap kotak biru pada diagram di bawah ini) dilayani oleh orang yang berbeda). Anda memiliki satu mesin virtual yang dengannya layanan akan diluncurkan dan IPSec akan diatur.



Harap dicatat bahwa IPSec sendiri diatur antara satu alamat IP (dalam contoh saya 10.0.255.1 <-> 10.0.1.1 ), dan layanan itu sendiri diatur antara yang lain ( 192.168.255.1<-> 192.168.1.1 ). Skema semacam itu juga disebut IPSec Network-Network .

Contoh sederhana adalah Anda bekerja di SuperService perusahaan yang muda namun sangat ambisius, dan Anda perlu mengatur interaksi dengan API tertutup MegaTelecom . Infrastruktur Anda adalah satu server VDS, infrastruktur mitra Anda adalah sekelompok peralatan jaringan dan server. Tugas ini dibagi menjadi dua tahap:

1. Untuk mengatur transportasi (bagaimana pekerjaan akan terjadi).
2. Konfigurasikan layanan (jalankan aplikasi langsung di server).

Jadi, manajer SuperService memutuskan untuk mengatur koneksi ke beberapa organisasi besar untuk menyelesaikan masalah bisnis. Dia menoleh ke MegaTelecom , di mana mereka mengiriminya spesifikasi teknis untuk koneksi. Salah satu kondisi ini adalah IPSec . Kondisi ini datang dalam bentuk piring excel , contoh yang saya sajikan di bawah ini. Dalam gambar, saya menyoroti parameter yang signifikan secara teknis dengan warna kuning. Formatnya mungkin berbeda, tetapi esensinya tetap sama.



Awalnya, itu tidak terisi di pihak Anda, itu harus diisi dan dikirim untuk persetujuan kepada mitra. Setelah setuju, Anda dapat duduk dan mencoba menyetel mesin Linux Anda.

Konsep IPSec

Selanjutnya, saya akan memberikan sedikit teori untuk orang-orang yang sama sekali tidak akrab dengan teknologi. Semua yang akan saya jelaskan lebih lanjut mengacu pada Ethernet murni dan IPv4. Saya tidak akan masuk ke enkripsi, algoritma pertukaran kunci, melainkan fokus pada bagian jaringan.

IPSec - seperangkat teknik dan protokol untuk mengatur koneksi yang aman.

Tidak seperti teknologi tunneling lainnya (GRE, PPP, L2TP, bahkan MPLS-TE), tidak ada interface tunnel eksplisit yang dibuat untuk IPSec melalui mana traffic dapat dialihkan. Sebagai gantinya, IPSec memberikan konsep yang disebut Security Assotiations (SA) . SA adalah terowongan dari satu perangkat jaringan ke perangkat lainnya. Tapi jangan lupa bahwa SA bukan antarmuka jaringan dalam arti kata normal, perutean klasik tidak berfungsi di sini. Alih-alih tabel routing, konsep Kebijakan Keamanan (SP) bekerja di sini. Kami secara eksplisit meresepkan sesuatu seperti daftar akses (ACL) untuk melewati lalu lintas melalui SA tertentu. Semua hal ini didefinisikan dalam kerangka kerja yang disebut ISAKMP .

ISAKMP - deskripsi prosedur IPSec, dalam literatur mereka menyebutnya kerangka kerja. Ini menggambarkan istilah SA, SP, SAD (Database Assosiasi Keamanan), SPD (Database Kebijakan Keamanan), kebutuhan untuk menginstal terowongan tambahan ... ISAKMP dirancang agar tidak bergantung pada teknologi tunneling, algoritma otentikasi, dan enkripsi. Dia hanya memperkenalkan definisi yang diperlukan.

IKE (v1 / 2) - langsung protokol otentikasi. Dia sudah mengimplementasikan algoritma pertukaran kunci dan aplikasinya.

Berkat konsep Cisco, ISAKMP dan IKE sekarang dianggap sama.

Sebelum mengenkripsi lalu lintas, para pihak harus menyetujui parameter (dan kunci) enkripsi ini. Untuk melakukan ini, sebuah terowongan bantu naik di antara kedua sisi (ini juga disebut terowongan ISAKMP), yang beroperasi sepanjang waktu. Terowongan dua arah ini adalah koneksi UDP (secara default pada port 500). Untuk mengatur terowongan bantu ini, para pihak harus saling mengautentikasi (kata sandi harus cocok). Ini dilakukan oleh protokol IKEv1 / 2 (Internet Key Exchange) . Dan sudah ada di terowongan ISAKMP yang terorganisir, para pihak sepakat untuk mengenkripsi lalu lintas pengguna secara langsung.

Organisasi IPSec sendiri dibagi menjadi dua fase:

1. Membuat Terowongan Bantu ISAKMP
2. Membuat terowongan data pengguna

Seperti yang saya tulis, dalam konsep IPSec (atau lebih tepatnya, dalam konsep ISAKMP ) terowongan disebut SA .

Fase pertama (organisasi ISAKMP SA) dapat dilakukan dalam dua mode:

1. pihak - pihak utama secara bergantian bertukar parameter negosiasi. Itu dianggap lebih aman, digunakan untuk saluran permanen (kasing kami).
2. agresif - dalam satu pesan, inisiator mengirim semua parameter koordinasi yang diperlukan, digunakan saat menghubungkan pengguna jarak jauh untuk sesi sementara (untuk membuatnya lebih cepat).

Anda harus memahami bahwa terowongan SA utama adalah searah . Untuk pengiriman data dua arah melalui saluran IPSec, harus ada dua terowongan: sumber (src) → penerima (dst) dan sebaliknya.

Dalam semua metode enkripsi, header tambahan ditambahkan ke paket IP asli, terjadi enkapsulasi. Ada dua metode untuk enkapsulasi ini - AH (Authentication Header) dan ESP (Encapsulation Security Payload) . AH hanya mengautentikasi paket (ditandatangani secara digital oleh pengirim), ESP dan mengautentikasi (tanda-tanda), dan mengenkripsi. Hari ini, AH hampir tidak pernah digunakan, semuanya dikemas dalam ESP.

Anda dapat mengenkripsi dan mengautentikasi paket IP sumber tanpa memperhitungkan header IP (mode transportasi) atau dengannya (mode terowongan). Transportasi digunakan ketika direncanakan untuk mengatur terowongannya menggunakan teknologi lain (bukan IPSec / ESP). Misalnya, GRE, l2tp, ppp. Untuk tujuan menghubungkan beberapa layanan ke infrastruktur internal organisasi besar, secara praktis tidak digunakan. Saya menggunakan skenario ini untuk menggabungkan beberapa kantor menjadi satu VPN melalui IPSec. Kami lebih tertarik pada mode terowongan . Seperti yang dapat Anda lihat dari gambar, satu header IP tambahan ditambahkan di sini.

Omong-omong, ada contoh nyata menggunakan enkapsulasi AH. Misalkan kita memiliki dua jaringan yang terhubung ke router yang berbeda. Host harus mengirimkan informasi dengan MTU 1500 byte tanpa fragmentasi, tetapi kami memiliki bagian perantara yang hanya mendukung 1380 byte. Seluruh trek dipercaya. Kita dapat mengambil keuntungan dari fakta bahwa IPSec tidak membuat antarmuka terowongan, dalam arti klasik di mana lalu lintas tidak dialihkan. Kami akan membuat SA tipe terowongan SA (kami tidak perlu mengenkripsi), lalu lintas akan menuju ke sana. Hanya paket IP eksternal (sesuai dengan header IP eksternal) yang akan difragmentasi dalam lalu lintas, yang internal akan disusun kembali tanpa perubahan.

Perhatikan bahwa header ESP naik sebelum transportasi TCP / UDP . Ingat bidang IP memiliki bidang Protokol? Berdasarkan bidang ini, peralatan jaringan (dan penghuni akhir) dengan benar memproses paket IP. Jadi untuk ESP jumlahnya adalah 50. Daftar lengkap protokol untuk bidang ini dapat dilihat di wiki , itu bisa sangat berguna.

Tidak adanya header lapisan transport (TCP / UDP / ICMP sudah dienkripsi!) Memberlakukan batasan pada teknologi seperti NAT. Ingat, NAT dengan terjemahan port (overload, PAT, MASQARADE, ini memiliki banyak nama) berfungsi berdasarkan port protokol transport. Dan di terowongan IPSec terenkripsi mereka tidak! Untuk mengatasi masalah ini, ada teknologi seperti IPSec NAT-Traversal (NAT-T) . Selama fase pertama, para pihak sepakat tentang penggunaan NAT-T. Jika kedua belah pihak mendukung NAT-T (dan bahkan pada port UDP yang sama), maka header UDP ditambahkan ke terowongan yang dihasilkan untuk lalu lintas, dengan paket mana yang akan melalui router dengan terjemahan alamat jaringan.

Terowongan itu sendiri tidak akan naik, Anda perlu mengarahkan lalu lintas di sana. Seperti yang saya tulis di atas, aturan perutean tidak berfungsi di sini, Anda perlu menulis Kebijakan Keamanan (SP) .

Kebijakan terdiri dari alamat sumber, alamat tujuan, arah (masuk, keluar, fwd) dan parameter terowongan pengguna (di sini ESP akan dijelaskan hanya apakah itu AH, versi terowongan, atau transportasi). Ini lebih seperti mengatur aturan untuk NAT. NAT juga tidak memiliki entri tabel routing yang cukup. Dan di sana juga, peraturan ditunjukkan di mana, di mana dan bagaimana , dan bukan di mana dan melalui apa . Dan juga dengan gerakan tangan yang salah, Anda dapat memblokir semua komunikasi di server jauh.

Semua manipulasi IPSec menambahkan header. Setidaknya mereka akan memakan 40 byte lagi dari paket aslinya. Jadi, misalnya, dengan MTU standar untuk PPPoE 1380 byte koneksi, MTU yang sebenarnya adalah <1340.

IPSec di Linux

Mari berlatih menggunakan contoh distribusi DEB. Saya hanya akan mempertimbangkan kasus dengan otorisasi berdasarkan pre-shared-key (PSK) , kami akan mengonfigurasi skema dari awal artikel.

IPSec sendiri didukung oleh kernel, tetapi dukungan ini sangat terbatas. Sebenarnya, modul-modul yang kuat hanya berkaitan dengan enkripsi dan kunci (pemrosesan paket) yang telah diterima (ditransfer ke kernel). Dan untuk lulus di sana parameter dan aturan yang Anda butuhkan untuk memproses lalu lintas, Anda memerlukan perangkat lunak terpisah. Sebagai perangkat lunak seperti itu, ada beberapa solusi:

1. KAME bermigrasi dari BSD
2. xSWAN (strongswan, freeswan, libreswan, dll)
3. shorewall

Bagiku, versi KAME yang paling sederhana (dapat diprediksi), dan kami akan terus memutarnya.

 # deb-       root@localhost: ~# apt-get install racoon ipsec-tools 

Secara tradisional, KAME terdiri dari dua komponen

1. Daemon racoon untuk mengontrol terowongan ISAKMP .
2. Utilitas Setkey untuk mengelola terowongan SA dengan data.

Mari kita mulai dengan yang pertama. Racoon bertanggung jawab atas pengaturan otorisasi terowongan di bawah IKE. Ini adalah daemon, dikonfigurasikan dengan satu file konfigurasi ( /etc/racoon.conf ), diluncurkan oleh skrip init biasa ( /etc/init.d/racoon <start|stop|restart> ).



Seperti biasa, detail dalam man 5 racoon.conf

Selanjutnya, kita akan mengambil utilitas setkey . Itu juga dimulai sebagai daemon ( /etc/init.d/setkey <start|stop|restart> ), tetapi sebenarnya ia menjalankan script /etc/ipsec-tools.conf . Seperti yang saya katakan, itu sudah membuat terowongan untuk lalu lintas pengguna. Yaitu mengatur SA dan SP untuk mereka. Ini adalah sesuatu seperti kripto-peta di ASA. Opsi termudah bagi kita adalah menambahkan SP saja. Kemudian SA akan dibangun secara otomatis berdasarkan parameter fase kedua yang ditentukan dalam pengaturan racoon .

Tetapi dimungkinkan untuk tidak menggunakan parameter fase kedua dari racoon sama sekali , tetapi untuk mengatur SA melalui utilitas ini. Detail dan sintaksis dapat ditemukan di man 8 setkey . Tetapi saya akan memberikan contoh konfigurasi yang paling sederhana.


Saat ini, utilitas setkey diduplikasi oleh modul iproute2 .
Sebagai bagian dari itu, ada dua tim manajemen catatan SA dan SP.

1. kondisi ip xfrm
2. kebijakan ip xfrm

Selain mengelola utilitas ini, Anda dapat melihat status SA dan SP terorganisir yang diterapkan untuk lalu lintas. Lebih detail dalam man 8 ip-xfrm .

Lihatlah tablet aslinya. Ada beberapa alamat IP untuk IPSec dan layanan. Alamat IP internal sedang difilter di dalam infrastruktur Megatelecom . Tetapi kami hanya memiliki satu mesin virtual. Alamat IP internal entah bagaimana akan muncul di dalamnya, dan paket-paket ke dalam terowongan harus pergi darinya. Ada beberapa opsi untuk mencapai skenario ini:

1. Rute statis tanpa mendeteksi penghentian, tetapi dengan indikasi eksplisit antarmuka keluar dan alamat IP.
2. Menentukan rute berdasarkan kebijakan berbasis routing (PBR di Linux alias aturan ip ).
3. Terjemahan Alamat ( NAT / MASQARADE ).

Dari sudut pandang saya, opsi pertama cocok di sini.

Kami dapat menambahkan alamat IP (sekunder) tambahan ke antarmuka kami, sementara itu lebih baik untuk membuat alias untuk antarmuka ini
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
dan konfigurasikan rute ke server Megatelecom dari alamat IP ini.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
Tetapi jika Anda melakukannya, tidak ada yang akan mulai. Faktanya adalah bahwa ketika menambahkan rute dalam formulir ini, stasiun Linux akan mencoba menentukan alamat MAC penerima, itu akan melakukannya melalui ARP ... Komputer akan mengirim permintaan ARP Who has IP 192.168.255.1 . Karena 192.168.255.1 tidak pada jaringan yang sama dengan 192.168.1.1 (mask / 32!), Tidak akan ada respons terhadap ARP. Tetapi ketika Anda mencoba untuk terhubung, No route to host akan dikembalikan dari alamat IP lokal. Untuk mengalahkan ini, kita perlu menetapkan catatan ARP statis:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Semacam hack hidup. Omong-omong, manipulasi semacam itu mungkin tidak mengarah pada operasi yang benar dari tumpukan IP Linux. Dalam salah satu kasus, perintah ip route tidak menghasilkan hasil yang diinginkan, perlu untuk mem-boot ulang tumpukan jaringan.

Pemeriksaan Kesehatan

Jangan lupa, terowongan hanya akan naik ketika lalu lintas masuk ke dalamnya! Diperlukan untuk memulai ping dari antarmuka tertentu (alamat IP) sebelum tujuan.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1
Dengan sedikit keterlambatan, harus ada balasan dari sisi sebaliknya (kecuali tentu saja ICMP ditutup di mana saja di situs).

Kita bisa melihat apakah terowongan ISAKMP telah naik.


Kita juga bisa melihat terowongan dengan data pengguna.


Dapat berguna dalam tcpdump untuk melihat logika untuk membangun koneksi. Di sini Anda juga dapat melihat fase pembuatan koneksi dan lalu lintas yang sudah dienkripsi dalam ESP. Tentu saja, ada teknik untuk menguraikannya, tetapi biasanya kesimpulan ini sudah cukup.

Saat menghubungkan dari jarak jauh melalui SSH, agar tidak menghasilkan banyak jendela, lebih mudah untuk menjalankan tcpdump di latar belakang:

root@localhost: ~# tcpdump -i eth1 -w ipsec.pcap esp &


Kami mulai ping, telnet, netcat ...

root@localhost: ~# killall tcpdump
root@localhost: ~# tcpdump -vr ipsec.pcap


Juga di log Anda dapat melihat status koneksi yang berhasil. Ini menunjukkan keberhasilan pendirian kedua fase IPSec.


Itu saja. Tetap menambahkan semua manipulasi yang diperlukan ke startup, dan Anda dapat memulai integrasi aplikasi.

PS: Permintaan untuk melaporkan semua kesalahan atau ketidakakuratan dalam artikel melalui pesan pribadi. Ketika saya men-tweak artikelnya, komentarnya akan terlihat konyol.