🐽 🧛🏿 😇 IPSec Mahakuasa ⛽️ 💔 🤛🏿

Selamat siang teman teman. Bukan rahasia lagi bahwa banyak dari kita memiliki setidaknya sekali, tetapi harus berurusan dengan kebutuhan untuk mengkonfigurasi VPN. Menjadi pembaca aktif Habr, saya perhatikan bahwa meskipun ada banyak artikel tentang IPSec, bagi banyak orang itu masih merupakan sesuatu yang rumit dan kelebihan beban. Pada artikel ini saya akan mencoba untuk menghilangkan mitos-mitos ini menggunakan konfigurasi saya sendiri yang berfungsi penuh sebagai contoh. Dalam empat contoh, kita akan benar-benar melalui konfigurasi solusi Linux (Strongswan) paling populer, dari terowongan sederhana dengan otentikasi sisi dengan kunci PSK ke koneksi host-ke-host dengan otentikasi kedua belah pihak berdasarkan sertifikat dari Let's Encrypt. Menarik? Selamat datang di kucing!

Latar Belakang

Awalnya, VPN direncanakan hanya untuk pengaturan saluran antara router mini dari orang tua dan server home "bedside", yang secara bersamaan bertindak sebagai router.

Setelah beberapa saat, Keenetic ditambahkan ke perusahaan ini dari dua perangkat.
Tetapi begitu mulai, ternyata sulit untuk berhenti, dan segera telepon dan laptop muncul pada diagram, yang ingin bersembunyi dari mata iklan MT_Free dan jaringan WiFi tidak terenkripsi lainnya.

Kemudian ILV yang dicintai akhirnya menguatkan Banhammer, yang sangat ia cintai di depan umum berayun ke segala arah, dan untuk menetralisir kepeduliannya terhadap manusia biasa, ia harus ~~mendukung sektor IT asing~~ untuk mendapatkan VPS di luar negeri.
Selain itu, seorang warga negara tertentu yang terlihat seperti Shapoklyak, berlarian di mana-mana dengan ~~tasnya oleh~~ Paket, dan mungkin percaya bahwa "Siapa yang membantu orang, membuang-buang waktu. Kamu tidak bisa menjadi terkenal karena perbuatan baik, ”aku ingin mengintip lalu lintas orang lain dan mengambilnya dengan pensil. Kami juga harus membela diri terhadap cinta dan VPN yang tidak diminta dalam hal ini persis seperti yang diperintahkan dokter.

Untuk meringkas ringkasan singkat. Itu perlu untuk menemukan solusi yang idealnya dapat menutup beberapa tugas sekaligus:

Interkoneksi antar router Linux
Membangun terowongan antara Linux dan Rumah Tangga Keenetik
Berikan akses ke sumber daya rumah dan Internet ke perangkat yang dapat dipakai (telepon, laptop) dari jaringan yang tidak terpercaya
Buat terowongan terenkripsi dengan aman ke VPS jarak jauh

Jangan lupa tentang prinsip KISS yang luar biasa - Keep It Simple, Stupid. Semakin sedikit komponen yang terlibat dan semakin mudah untuk mengkonfigurasi masing-masing - semakin dapat diandalkan.

Ikhtisar solusi yang ada

Secara singkat membahas apa yang sekarang: Kakek

PPTP

Lenin dari semua protokol. Mati, "Membusuk di cetakan dan madu linden."

L2TP

Apakah ada orang selain satu penyedia yang menggunakan ini? Proyek

Wireguard

sedang berkembang. Digergaji secara aktif. Sangat mudah untuk membuat terowongan antara dua rekan yang memiliki IP statis. Dalam kasus lain, kruk, sepeda dengan roda persegi dan pita listrik biru selalu siap membantu, tetapi ini bukan cara kami.

OpenVPN

Pro:

Dukungan untuk berbagai platform - Windows, Linux, OpenWRT dan turunannya, Android
Enkripsi yang kuat dan dukungan sertifikat.
Fleksibilitas penyesuaian.

Dan kontra:

Bekerja sepenuhnya di ruang pengguna.
Dukungan terbatas dari router rumah - krenenko-kosenko di Mikrotik (tanpa mengurangi kelebihan kelenjar lainnya) dan normal di OpenWRT.
Kesulitan dalam mengatur klien seluler: Anda perlu mengunduh, atau membuat pemasang Anda sendiri, menyalin konfigurasi di suatu tempat.
Jika ada beberapa terowongan, tarian akan menunggu dengan mengedit unit systemd di server.

OpenConnect (implementasi open source dari protokol Cisco Anyconnect)
Suatu solusi yang sangat menarik tentang yang, sayangnya, adalah sedikit informasi.

Pro:

Dukungan yang relatif luas untuk berbagai platform - Windows, Android, Mac berdasarkan aplikasi asli Cisco Anyconnect dari toko - adalah pilihan ideal untuk menyediakan akses ke jaringan internal perangkat yang dapat dipakai.
Enkripsi yang kuat, dukungan sertifikat, konektivitas 2FA
Protokol itu sendiri sepenuhnya berbasis TLS (tidak seperti OpenVPN, yang mudah dideteksi pada port 443). Selain TLS, DTLS juga didukung - selama sesi yang ditetapkan, klien dapat beralih untuk mentransmisikan data melalui UDP dan sebaliknya.
Koeksistensi luar biasa pada satu port baik untuk VPN maupun server web lengkap menggunakan sniproxy.
Pengaturan mudah dari server dan klien.

Di sini juga bukan tanpa kontra:

Bekerja sepenuhnya di ruang pengguna.
TCP di atas TCP adalah ide yang buruk.
Tidak ada dukungan dari peralatan tingkat pelanggan.
Kompleksitas menginstal terowongan antara dua Linux: secara teori memungkinkan, praktis - lebih baik menghabiskan waktu untuk sesuatu yang lebih berguna.
Jika ada beberapa terowongan, tarian dengan beberapa konfigurasi dan unit sistem editing sedang menunggu.

Sepertinya jalan buntu, tetapi setelah melihat lebih dekat dan menghabiskan sedikit waktu belajar, saya menyadari bahwa IPSec yang berbasis pada IKEv2 mampu menggantikan yang lainnya.

IKEv2 IPSEC

Pro:

Dengan munculnya IKEv2, protokol itu sendiri menjadi lebih mudah untuk dikonfigurasi, dibandingkan dengan versi sebelumnya, tetapi dengan biaya kehilangan kompatibilitas ke belakang.
Berkat standardisasi, pekerjaan disediakan di mana saja dan apa saja - daftarnya dapat dipertahankan tanpa batas waktu. Linux, Mikrotik (dalam versi terbaru dari RouterOS), OpenWRT, Android, iPhone. Windows juga memiliki dukungan asli yang dimulai dengan Windows 7.
Kecepatan tinggi: pemrosesan lalu lintas sepenuhnya di ruang kernel. Bagian ruang pengguna hanya diperlukan untuk mengatur parameter koneksi dan memantau kesehatan saluran.
Kemampuan untuk menggunakan beberapa metode otentikasi: menggunakan PSK dan sertifikat, dan dalam kombinasi apa pun.
Beberapa mode pengoperasian: terowongan dan transportasi. Bagaimana perbedaan mereka dapat dibaca termasuk di Habré.
Pengaturan ringan untuk simpul perantara: jika dalam versi pertama IKE ada masalah yang disebabkan oleh NAT, maka IKEv2 memiliki mekanisme bawaan untuk mengatasi NAT dan fragmentasi asli pesan IKE, yang memungkinkan Anda membuat koneksi pada saluran dengan kurva MTU. Ke depan, saya akan mengatakan bahwa dalam praktiknya saya tidak pernah menjumpai jaringan WiFi, di mana pun klien dapat membuat koneksi.

Kontra, bagaimanapun, juga memiliki:

Anda perlu meluangkan waktu mempelajari dan memahami cara kerjanya.
Fitur yang dapat membingungkan pemula: IPSec, tidak seperti solusi VPN konvensional, tidak membuat antarmuka jaringan. Hanya kebijakan pemrosesan lalu lintas yang ditetapkan, yang lainnya diselesaikan dengan cara firewall.

Sebelum melanjutkan dengan pengaturan, kami berasumsi bahwa pembaca sudah sedikit akrab dengan konsep dan istilah dasar. Untuk membantu pemula, Anda dapat merekomendasikan artikel dari Wikipedia dan Habr sendiri, yang sudah ada artikel yang cukup menarik dan bermanfaat tentang topik ini.

Memulai pengaturan

Setelah memutuskan keputusan, kami melanjutkan ke konfigurasi. Diagram jaringan dalam kasus saya memiliki bentuk berikut (dihapus di bawah spoiler)

Diagram jaringan

ipsecgw.example.com adalah server rumah yang merupakan pusat jaringan. IP eksternal 1.1.1.1. Jaringan internal 10.0.0.0/23 dan alamat lain 10.255.255.1/30 untuk mengatur sesi BGP pribadi dengan VPS;
mama adalah router Linux yang didasarkan pada nettop kecil dan sunyi yang dipasang oleh orang tua. ISP mengeluarkan alamat IP dinamis. Jaringan internal 10.0.3.0/24;
keenetic - Router tajam dengan IPSec diinstal. ISP mengeluarkan alamat IP dinamis. Jaringan internal 10.0.4.0/24;
road-warriors - perangkat portabel yang terhubung dari jaringan yang tidak terpercaya. Alamat dikeluarkan untuk klien secara dinamis ketika terhubung dari kumpulan internal (10.1.1.0/24);
rkn.example.com- VPS di luar yurisdiksi ILV yang disegani. IP eksternal - 5.5.5.5, alamat internal 10.255.255.2/30 untuk mengatur sesi BGP pribadi.

Langkah pertama. Dari sederhana ke rumit: terowongan menggunakan kunci yang dibagikan sebelumnya (PSK)

Di kedua Linux-box kami menginstal paket yang diperlukan:

sudo yum install strongswan

Pada kedua host, buka port 500 / udp, 4500 / udp dan biarkan lewatnya protokol ESP.
Edit file /etc/strongswan/ipsec.secrects (di sisi host ipsecgw.example.com) dan tambahkan baris berikut:

mama@router.home.local: PSK "Very strong PSK"

Di sisi kedua, sama:

root@root.mama.local: PSK "Very strong PSK"

Dalam hal ini, ID adalah alamat email fiktif. Informasi lebih lanjut dapat ditemukan di wiki resmi .

Rahasia disimpan, terus berjalan.

Pada host ipsecgw.example.com, edit file /etc/strongswan/ipsec.conf:

config setup //   charon
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0" //  
conn %default //    
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2 //      - IKEv2
    dpdaction = hold
    dpddelay = 5s // 5   DPD (Dead Peer Detection)   
    mobike = yes // Mobile IKE -     IP    
conn mama //  
    left = %defaultroute //Left -  .  %defaultroute       IKE- ,    default route
    right = %any //     IP-
    authby = psk //   -   
    leftid = mama@router.home.local // ID,   ipsec.secrets
    rightid = root@router.mama.local //ID  
    leftsubnet = 10.0.0.0/23,10.1.1.0/24 
    rightsubnet = 10.0.3.0/24
    type = tunnel 
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519! 
    auto = add //  charon

Demikian pula, kami mengedit pada remote peer /etc/strongswan/ipsec.conf:

config setup
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
conn %default
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2
    dpdaction = restart
    dpddelay = 5s
    mobike = yes
conn mama
    left = %defaultroute
    right = ipsecgw.example.com
    authby = psk
    leftid = root@router.mama.local
    rightid = mama@router.home.local
    leftsubnet = 10.0.3.0/24
    rightsubnet = 10.0.0.0/23,10.1.1.0/24
    type = tunnel
    ike = aes128gcm16-sha384-x25519!
    esp = aes128gcm16-sha384-x25519!
    auto = route

Jika Anda membandingkan konfigurasi, Anda dapat melihat bahwa mereka hampir dicerminkan, hanya definisi dari teman sebaya yang ditukar silang.

Arahan auto = rute menyebabkan charon mengatur jebakan untuk lalu lintas yang jatuh ke arahan left / rightsubnet (penyeleksi lalu lintas). Koordinasi parameter terowongan dan pertukaran kunci akan dimulai segera setelah munculnya lalu lintas yang jatuh di bawah kondisi yang diberikan.

Di server ipsecgw.example.com dalam pengaturan firewall, kami melarang menyamar untuk jaringan 10.0.3.0/24. Izinkan penerusan paket antara 10.0.0.0/23 dan 10.0.3.0/24 dan sebaliknya. Pada host jarak jauh, kami melakukan pengaturan serupa dengan menonaktifkan penyamaran untuk jaringan 10.0.0.0/23 dan mengatur penerusan.

Kami me-restart strongswan di kedua server dan mencoba melakukan ping ke simpul pusat:

sudo systemctl restart strongswan
ping 10.0.0.1

Pastikan semuanya berfungsi:

sudo strongswan status
Security Associations (1 up, 0 connecting):
        mama[53]: ESTABLISHED 84 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{141}:  INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c4eb45fe_i ca5ec6ca_o
        mama{141}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24

Ini juga akan berguna untuk memastikan bahwa parameter make_before_break diatur ke yes di file /etc/strongswan/strongswan.d/charon.conf di semua rekan. Dalam hal ini, daemon charon yang melayani protokol IKEv2 tidak akan menghapus asosiasi keamanan saat ini selama prosedur perubahan utama, tetapi akan membuat yang baru terlebih dahulu.

Langkah Dua Munculnya Keenetic

Kejutan yang menyenangkan adalah IPSec VPN bawaan di firmware Keenetic resmi. Untuk mengaktifkannya, cukup buka Pengaturan Komponen KeeneticOS dan tambahkan paket IPSec VPN .

Kami menyiapkan pengaturan pada simpul pusat, untuk ini:

Edit /etc/strongswan/ipsec.secrect dan tambahkan PSK untuk rekan baru:

keenetic@router.home.local: PSK "Keenetic+PSK"

Edit /etc/strongswan/ipsec.conf dan tambahkan koneksi lain sampai akhir:

conn keenetic
    left = %defaultroute
    right = %any
    authby = psk
    leftid = keenetic@router.home.local
    rightid = root@router.keenetic.local
    leftsubnet = 10.0.0.0/23
    rightsubnet = 10.0.4.0/24
    type = tunnel
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
    auto = add

Di sisi Keenetic, konfigurasi dilakukan di WebUI di sepanjang jalur: Internet -> Connections ->
Other Connections . Sederhana saja

(3 gambar)

Jika Anda berencana untuk mengarahkan volume lalu lintas yang signifikan melalui terowongan, maka Anda dapat mencoba mengaktifkan akselerasi perangkat keras, yang didukung oleh banyak model. Diaktifkan oleh perintah perangkat keras mesin crypto di CLI. Untuk menonaktifkan dan memproses enkripsi dan proses hashing menggunakan instruksi CPU untuk keperluan umum - perangkat lunak mesin crypto

Setelah menyimpan pengaturan, kami mengembalikan strongswan dan membiarkan Keenetic berpikir selama setengah menit. Kemudian di terminal kita melihat koneksi yang berhasil:

Semuanya berfungsi:

sudo strongswan status
Security Associations (2 up, 0 connecting):
    keenetic[57]: ESTABLISHED 39 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{146}:  INSTALLED, TUNNEL, reqid 29, ESP SPIs: ca8f556e_i ca11848a_o
    keenetic{146}:   10.0.0.0/23 === 10.0.4.0/24
        mama[53]: ESTABLISHED 2 hours ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{145}:  INSTALLED, TUNNEL, reqid 27, ESP in UDP SPIs: c5dc78db_i c7baafd2_o
        mama{145}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24

Langkah ketiga Melindungi perangkat seluler

Setelah membaca banyak manual dan banyak artikel, diputuskan untuk berhenti di sekelompok sertifikat gratis dari Let's Encrypt untuk mengotentikasi server dan otorisasi klasik dengan login dan kata sandi untuk klien. Dengan demikian, kami menyingkirkan kebutuhan untuk mempertahankan infrastruktur PKI kami sendiri, memantau kedaluwarsa kunci dan melakukan gerakan yang tidak perlu dengan perangkat seluler dengan memasang sertifikat yang ditandatangani sendiri dalam daftar tepercaya.

Instal paket yang hilang:

sudo yum install epel-release
sudo yum install certbot

Kami mendapatkan sertifikat mandiri (jangan lupa untuk membuka 80 / tcp di pengaturan iptables terlebih dahulu):

sudo certbot certonly --standalone -d ipsecgw.example.com

Setelah certbot menyelesaikan tugasnya, kita harus mengajar Strongswan untuk melihat sertifikat kami:

di direktori /etc/strongswan/ipsec.d/cacerts membuat 2 tautan simbolis: satu ke root store sertifikat tepercaya di / etc / pki / tls / certs; dan yang kedua dengan nama ca.pem yang menunjuk ke /etc/letsencrypt/live/ipsecgw.example.com/chain.pem
Dua symlink juga dibuat di direktori /etc/strongswan/ipsec.d/certs: yang pertama, dengan nama Certificate.pem, merujuk ke file /etc/letsencrypt/live/ipsecgw.example.com/cert.pem. Dan yang kedua, bernama fullchain.pem, yang terhubung ke /etc/letsencrypt/live/ipsecgw.example.com/fullchain.pem
Dalam direktori /etc/strongswan/ipsec.d/private, tempatkan symlink key.pem menunjuk ke kunci pribadi yang dihasilkan oleh certbot dan berbaring di sepanjang jalan /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem

Tambahkan otentikasi melalui RSA ke ipsec.secrets dan sekelompok login / kata sandi untuk pengguna baru:

ipsecgw.example.com     : RSA key.pem
username phone          : EAP "Q1rkz*qt"
username notebook       : EAP "Zr!s1LBz"

Kami me-restart Strongswan dan ketika memanggil sudo strongswan listcerts kita akan melihat informasi sertifikat:

List of X.509 End Entity Certificates

  subject:  "CN=ipsecgw.example.com"
  issuer:   "C=US, O=Let's Encrypt, CN=Let's Encrypt Authority X3"
  validity:  not before May 23 19:36:52 2020, ok
             not after  Aug 21 19:36:52 2020, ok (expires in 87 days)
  serial:    04:c7:70:9c:a8:ce:57:cc:bf:6f:cb:fb:d3:a9:cf:06:b0:a8
  altNames:  ipsecgw.example.com
  flags:     serverAuth clientAuth
  OCSP URIs: http://ocsp.int-x3.letsencrypt.org
  certificatePolicies:
             2.23.140.1.2.1
             1.3.6.1.4.1.44947.1.1.1
             CPS: http://cps.letsencrypt.org

Kemudian kami menggambarkan koneksi baru di ipsec.conf :

conn remote-access
    dpddelay = 30s //   DPD ,     
    left = %defaultroute
    leftid = "CN=ipsecgw.example.com"
    leftcert = fullchain.pem //         
    leftsendcert = always
    leftsubnet = 0.0.0.0/0 //      
    right = %any
    rightid = %any
    rightauth = eap-mschapv2 // ,  EAP-MSCHAP2
    rightsendcert = never
    eap_identity = %identity 
    rightsourceip = 10.1.1.0/24 //Strongswan       
    rightdns = 10.0.0.1,10.0.0.3 //   DNS
    type = tunnel
    ike = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha384-x25519!
    esp = aes256-aes192-aes128-sha256-sha384-modp2048-modp3072-modp4096-modp8192,aes128gcm16-sha256-sha384-x25519!
    auto = add //      
    dpdaction = restart // ,      DPD

Jangan lupa mengedit file / etc / sysconfig / certbot yang mengindikasikan bahwa kami juga akan memperbarui sertifikat sebagai mandiri, dengan menambahkan CERTBOT_ARGS = "- standalone" ke dalamnya.

Juga, jangan lupa untuk mengaktifkan timer certbot-renew.timer dan atur hook untuk memulai kembali Strongswan jika mengeluarkan sertifikat baru. Untuk melakukan ini, letakkan skrip bash sederhana di / etc / letsencrypt / renewal-hooks / deploy /, atau edit file / etc / sysconfig / certbot lagi.

Kami memulai ulang Strongswan, aktifkan penyamaran untuk jaringan 10.1.1.0/24 di iptables dan lanjutkan untuk mengonfigurasi perangkat seluler.

Android

Instal aplikasi Strongswan dari Google Play .

Kami meluncurkan dan membuat yang baru

Profil

Kami menyimpan profil, terhubung dan, setelah sedetik, kami tidak perlu khawatir tentang seseorang yang dapat memata-matai kami.

Kami memeriksa:

sudo strongswan statusall
Security Associations (3 up, 0 connecting):
remote-access[109]: ESTABLISHED 2 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{269}:  INSTALLED, TUNNEL, reqid 55, ESP in UDP SPIs: c706edd1_i e5c12f1d_o
remote-access{269}:   0.0.0.0/0 ::/0 === 10.1.1.1/32
        mama[101]: ESTABLISHED 34 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{265}:  INSTALLED, TUNNEL, reqid 53, ESP in UDP SPIs: c8c83342_i c51309db_o
        mama{265}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
    keenetic[99]: ESTABLISHED 36 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{263}:  INSTALLED, TUNNEL, reqid 52, ESP SPIs: c3308f33_i c929d6f1_o
    keenetic{263}:   10.0.0.0/23 === 10.0.4.0/24

Windows

Windows versi saat ini terkejut. Semua konfigurasi VPN baru berlangsung dengan memanggil dua cmdlet PowerShell:

Add-VpnConnection -Name "IKEv2" -ServerAddress ipsecgw.example.com -TunnelType "IKEv2"
Set-VpnConnectionIPsecConfiguration -ConnectionName "IKEv2" -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PfsGroup PFS2048 -DHGroup Group14 -PassThru -Force

Dan satu hal lagi, jika Strongswan dikonfigurasikan untuk mengeluarkan alamat IPv6 kepada klien (ya, ia juga bisa melakukannya):

Add-VpnConnectionRoute -ConnectionName "IKEv2" -DestinationPrefix "2000::/3"

Bagian Empat, Final. Kami memotong jendela ke Eropa

Setelah melihat selokan penyedia "Situs ini diblokir oleh keputusan tumit kiri wakil jaksa kelima desa Trudovye Mozoli dari daerah Bogozabyt", sebuah VPS kecil dan tidak mencolok muncul (dengan nama domain yang terdengar bagus rkn.example.com) seribu kilometer dari monyet yang suka melambai dengan banhammer dan ukuran jaringan blok. / 16 sekaligus. Dan memutar VPS kecil ini adalah kreasi luar biasa dari rekan-rekan dari NIC.CZ bernama BIRD. Burung versi pertama terus-menerus mati dalam kepanikan akibat aktivitas monyet dengan pentungan, yang melarang hampir 4% Internet di puncak aktivitas kerja mereka, meninggalkan perhatian mendalam selama konfigurasi ulang, oleh karena itu diperbarui ke versi 2.0.7. Jika pembaca tertarik, saya akan menerbitkan artikel tentang transisi dari BIRD ke BIRD2, di mana format konfigurasi telah berubah secara dramatis,tetapi versi baru telah menjadi jauh lebih cepat dan tidak ada masalah dengan konfigurasi ulang dengan sejumlah besar rute. Dan karena kita menggunakan protokol routing dinamis, maka harus ada antarmuka jaringan yang melaluinya Anda perlu merutekan lalu lintas. Secara default, IPSec tidak membuat antarmuka, tetapi karena fleksibilitasnya, kita dapat menggunakan terowongan GRE klasik, yang akan kita lindungi di masa depan. Sebagai bonus, host ipsecgw.example.com dan rkn.example.com akan saling mengautentikasi menggunakan sertifikat yang memperbaharui diri sendiri. Tidak ada PSK, hanya sertifikat, hanya hardcore, tidak ada banyak keamanan.Secara default, IPSec tidak membuat antarmuka, tetapi karena fleksibilitasnya, kita dapat menggunakan terowongan GRE klasik, yang akan kita lindungi di masa depan. Sebagai bonus, host ipsecgw.example.com dan rkn.example.com akan saling mengautentikasi menggunakan sertifikat yang memperbaharui diri sendiri. Tidak ada PSK, hanya sertifikat, hanya hardcore, tidak ada banyak keamanan.Secara default, IPSec tidak membuat antarmuka, tetapi karena fleksibilitasnya, kita dapat menggunakan terowongan GRE klasik, yang akan kita lindungi di masa depan. Sebagai bonus, host ipsecgw.example.com dan rkn.example.com akan saling mengautentikasi menggunakan sertifikat yang memperbaharui diri sendiri. Tidak ada PSK, hanya sertifikat, hanya hardcore, tidak ada banyak keamanan.

Kami percaya bahwa VPS disiapkan, Strongswan dan Certbot sudah diinstal.

Pada host ipsecgw.example.com (IP-nya 1.1.1.1), kami menggambarkan antarmuka gif0 baru:

sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="1.1.1.1"
PEER_OUTER_IPADDR="5.5.5.5"
MY_INNER_IPADDR="10.255.255.1/30"
PEER_INNER_IPADDR="10.255.255.2/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"

Dicerminkan pada host vps.example.com (IP-nya 5.5.5.5):

sudo vi /etc/sysconfig/network-scripts/ifcfg-gif0
DEVICE="gif0"
MY_OUTER_IPADDR="5.5.5.5"
PEER_OUTER_IPADDR="1.1.1.1"
MY_INNER_IPADDR="10.255.255.2/30"
PEER_INNER_IPADDR="10.255.255.1/30"
TYPE="GRE"
TTL="64"
MTU="1442"
ONBOOT="yes"

Kami meningkatkan antarmuka, tetapi karena iptables tidak memiliki aturan yang memungkinkan protokol GRE, lalu lintas tidak akan pergi (yang kami butuhkan, karena tidak ada perlindungan di dalam GRE terhadap penggemar dari segala jenis "paket" legislatif).

Memasak VPS

Pertama, kami mendapatkan sertifikat lain untuk nama domain rkn.example.com. Buat symlink di /etc/strongswan/ipsec.d seperti yang dijelaskan di bagian sebelumnya.

Edit ipsec.secrets dengan menambahkan satu baris ke dalamnya:

rkn.example.com     : RSA key.pem

Edit ipsec.conf:

config setup
    charondebug = "dmn 0, mgr 0, ike 0, chd 0, job 0, cfg 0, knl 0, net 0, asn 0, enc 0, lib 0, esp 0, tls 0, tnc 0, imc 0, imv 0, pts 0"
    strictcrlpolicy = yes
conn %default
    reauth = yes
    rekey = yes
    keyingtries = %forever
    keyexchange = ikev2
    dpdaction = restart
    dpddelay = 5s
    mobike = yes
conn rkn
    left = %defaultroute
    right = ipsecgw.example.com
    authby = pubkey
    leftcert = fullchain.pem
    leftsendcert = always
    leftauth = pubkey
    rightauth = pubkey
    leftid = "CN=rkn.example.com"
    rightid = "CN=ipsecgw.example.com"
    rightrsasigkey = /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
    leftsubnet = %dynamic
    rightsubnet = %dynamic
    type = transport
    ike = aes256gcm16-sha384-x25519!
    esp = aes256gcm16-sha384-x25519!
    auto = route

Di sisi tuan rumah, ipsecgw.example.com juga ditambahkan ke ipsec.conf di bagian pengaturan parameter strictcrlpolicy = yes, yang mencakup pemeriksaan CRL yang ketat. Dan uraikan koneksi lain:

conn rkn
    left = %defaultroute
    right = rkn.example.com
    leftcert = fullchain.pem
    leftsendcert = always
    leftauth = pubkey
    rightauth = pubkey
    rightrsasigkey = /etc/strongswan/ipsec.d/certs/rkn.exapmle.com.pem
    leftid = "CN=ipsecgw.example.com"
    rightid = "CN=rkn.example.com"
    leftsubnet = %dynamic
    rightsubnet = %dynamic
    type = transport
    ike = aes256gcm16-sha384-x25519!
    esp = aes256gcm16-sha384-x25519!
    auto = route
    dpdaction = restart

Konfigurasi hampir dicerminkan. Pembaca yang penuh perhatian sudah bisa memperhatikan beberapa poin:

kiri / rightsubnet =% dinamis - memerintahkan Strongswan untuk menerapkan kebijakan ke semua jenis lalu lintas antar teman
rightrsasigkey. IKE SA IKE AUTH ERROR , Strongswan RSA- . openssl. (ipsecgw RKN) sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > ~/ipsecgw.example.com.pem sudo /usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > ~/rkn.example.com.pem, scp ,

Jangan lupa untuk mengkonfigurasi firewall dan sertifikat perpanjangan otomatis. Setelah memulai ulang Strongswan di kedua server, mulai ping sisi jauh dari terowongan GRE dan lihat koneksi yang berhasil. Di VPS (rkn):

sudo strongswan status
Routed Connections:
         rkn{1}:  ROUTED, TRANSPORT, reqid 1
         rkn{1}:   5.5.5.5/32 === 1.1.1.1/32
Security Associations (1 up, 0 connecting):
         rkn[33]: ESTABLISHED 79 minutes ago, 5.5.5.5[CN=rkn.example.com]...1.1.1.1[CN=ipsecgw.example.com]
         rkn{83}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cb4bc3bb_i c4c35a5a_o
         rkn{83}:   5.5.5.5/32 === 1.1.1.1/32

Dan di ipsecgw sisi tuan rumah

di bawah spoiler

Routed Connections:
         rkn{1}:  ROUTED, TRANSPORT, reqid 1
         rkn{1}:   1.1.1.1/32 === 5.5.5.5/32
Security Associations (4 up, 0 connecting):
remote-access[10]: ESTABLISHED 5 seconds ago, 1.1.1.1[CN=ipsecgw.example.com]...4.4.4.4[phone]
remote-access{12}:  INSTALLED, TUNNEL, reqid 7, ESP in UDP SPIs: c7a31be1_i a231904e_o
remote-access{12}:   0.0.0.0/0 === 10.1.1.1/32
    keenetic[8]: ESTABLISHED 22 minutes ago, 1.1.1.1[keenetic@router.home.local]...3.3.3.3[root@router.keenetic.local]
    keenetic{11}:  INSTALLED, TUNNEL, reqid 6, ESP SPIs: cfc1b329_i c01e1b6e_o
    keenetic{11}:   10.0.0.0/23 === 10.0.4.0/24
        mama[4]: ESTABLISHED 83 minutes ago, 1.1.1.1[mama@router.home.local]...2.2.2.2[root@router.mama.local]
        mama{8}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c4a5451a_i ca67c223_o
        mama{8}:   10.0.0.0/23 10.1.1.0/24 === 10.0.3.0/24
         rkn[3]: ESTABLISHED 83 minutes ago, 1.1.1.1[CN=ipsecgw.example.com]...5.5.5.5[CN=rkn.example.com]
         rkn{7}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: c4c35a5a_i cb4bc3bb_o
         rkn{7}:   1.1.1.1/32 === 5.5.5.5/32

Terowongan diinstal, ping pergi, di tcpdump terlihat bahwa hanya ESP yang berjalan di antara host. Tampaknya mungkin untuk bersukacita. Tetapi Anda tidak dapat bersantai tanpa memeriksa semuanya sampai akhir. Kami sedang mencoba menerbitkan kembali sertifikat untuk VPS dan ...

Chef, semuanya rusak

Kita mulai memahami dan menemukan satu fitur yang tidak menyenangkan dari Let's Encrypt, yang indah dalam hal lainnya - dengan penerbitan ulang sertifikat, kunci pribadi yang terkait dengannya juga berubah. Kunci pribadi telah berubah - dan publik telah berubah. Pada pandangan pertama, situasinya tidak ada harapan bagi kita: bahkan jika kita dapat dengan mudah mengekstraksi kunci publik selama penerbitan ulang sertifikat menggunakan hook di certbot dan meneruskannya ke sisi jarak jauh melalui SSH, tidak jelas bagaimana membuat Strongswan remote membacanya kembali. Tetapi bantuan datang dari tempat mereka tidak menunggu - systemd dapat memantau perubahan pada sistem file dan menjalankan layanan yang terkait dengan acara tersebut. Ini yang akan kita gunakan.

Kami akan membuat pengguna layanan pengamat kunci di setiap host dengan hak yang paling terbatas, menghasilkan kunci SSH untuk masing-masing, dan menukarnya di antara host.

Pada host ipsecgw.example.com, buat direktori / opt / ipsec-pubkey tempat kami menempatkan 2 skrip.

sudo vi /opt/ipsec-pubkey/pubkey-copy.sh

#!/bin/sh
if [ ! -f /home/keywatcher/ipsecgw.example.com.pem ]; then
  /usr/bin/openssl rsa -in /etc/letsencrypt/live/ipsecgw.example.com/privkey.pem -pubout > /home/keywatcher/ipsecgw.example.com.pem;
  /usr/bin/chown keywatcher:keywatcher /home/keywatcher/ipsecgw.example.com.pem;
  /usr/bin/chmod 0600 /home/keywatcher/ipsecgw.example.com.pem;
  sudo -u keywatcher /usr/bin/scp /home/keywatcher/ipsecgw.example.com.pem rkn.example.com:/home/keywatcher/ipsecgw.example.com.pem;
  status=$?;
  if [ $status -eq 0 ]; then
    rm -f /home/keywatcher/ipsecgw.example.com.pem;
    logger "Public key ipsecgw.example.com.pem has been successfully uploaded to remote host";
  else
    logger "Public key ipsecgw.example.com.pem has not been uploaded to remote host due to error";
  fi
  else
    logger "Public key ipsecgw.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0

sudo vi /opt/ipsec-pubkey/key-updater.sh

#!/bin/sh
/usr/bin/cp /home/keywatcher/rkn.example.com.pem /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/rkn.example.com.pem
logger "Public key of server rkn.example.com has been updated, restarting strongswan daemon to re-read it"
/usr/bin/systemctl restart strongswan
exit 0

Pada VPS (host rkn.example.com), kami juga membuat direktori dengan nama yang sama, di mana kami juga membuat skrip yang sama, hanya mengubah nama kunci. Kode, agar tidak mengacaukan artikel, di bawah

spoiler

sudo vi /opt/ipsec-pubkey/pubkey-copy.sh

#!/bin/sh
if [ ! -f /home/keywatcher/rkn.example.com.pem ]; then
  /usr/bin/openssl rsa -in /etc/letsencrypt/live/rkn.example.com/privkey.pem -pubout > /home/keywatcher/rkn.example.com.pem;
  /usr/bin/chown keywatcher:keywatcher /home/keywatcher/rkn.example.com.pem;
  /usr/bin/chmod 0600 /home/keywatcher/rkn.example.com.pem;
  sudo -u keywatcher /usr/bin/scp /home/keywatcher/rkn.example.com.pem ipsecgw.example.com:/home/keywatcher/rkn.example.com.pem;
  status=$?;
  if [ $status -eq 0 ]; then
    rm -f /home/keywatcher/rkn.example.com.pem;
    logger "Public key rkn.example.com.pem has been successfully uploaded to remote host";
  else
    logger "Public key rkn.example.com.pem has not been uploaded to remote host";
  fi
  else
    logger "Public key rkn.example.com.pem already exist on /home/keywatcher directory, something went wrong";
fi
exit 0

sudo vi /opt/ipsec-pubkey/key-updater.sh


#!/bin/bash
/usr/bin/cp /home/keywatcher/ipsecgw.example.com.pem /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem;
/usr/bin/chown root:root /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
/usr/bin/chmod 0600 /etc/strongswan/ipsec.d/certs/ipsecgw.example.com.pem
logger "Public key of server ipsecgw.example.com has been updated, restarting connection"
/usr/bin/systemctl restart strongswan
exit 0

Script pubkey-copy.sh diperlukan untuk mengekstrak bagian publik kunci dan menyalinnya ke host jarak jauh ketika mengeluarkan sertifikat baru. Untuk melakukan ini, di direktori / etc / letsencrypt / renewal-hooks / deploy di kedua server, buat microscript lain:


#!/bin/sh
/opt/ipsec-pubkey/pubkey-copy.sh > /dev/null 2>&1
/usr/bin/systemctl restart strongswan
exit 0

Setengah dari masalah diselesaikan, sertifikat dikeluarkan kembali, kunci publik diekstraksi dan disalin antara server, dan waktunya telah tiba untuk systemd dengan unit path-nya.

Pada server ipsecgw.example.com di direktori / etc / systemd / system, buat file keyupdater.path

[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/rkn.example.com.pem
[Install]
WantedBy=multi-user.target

Demikian pula pada host VPS:

[Unit]
Wants=strongswan.service
[Path]
PathChanged=/home/keywatcher/ipsecgw.example.com.pem
[Install]
WantedBy=multi-user.target

Dan akhirnya, pada setiap server kami membuat layanan yang terkait dengan unit ini, yang akan diluncurkan ketika kondisi (PathChanged) terpenuhi - mengubah file dan menutupnya setelah merekam. Kami membuat file /etc/systemd/system/keyupdater.service dan menulis:

[Unit]
Description= Starts the IPSec key updating script
Documentation= man:systemd.service
[Service]
Type=oneshot
ExecStart=/opt/ipsec-pubkey/key-updater.sh
[Install]
WantedBy=multi-user.target

Jangan lupa untuk membaca kembali konfigurasi systemd dengan sudo systemctl daemon-reload dan tetapkan autostart ke unit path melalui sudo systemctl aktifkan keyupdater.path && sudo systemctl start keyupdater.

Segera setelah host jarak jauh menulis file yang berisi kunci publik ke direktori home pengguna keywatcher dan deskriptor file ditutup, systemd akan secara otomatis memulai layanan yang sesuai, yang akan menyalin kunci ke lokasi yang diinginkan dan memulai kembali Strongswan. Terowongan akan dipasang menggunakan kunci publik yang benar dari sisi kedua.

Anda dapat menghembuskan napas dan menikmati hasilnya.

Alih-alih sebuah kesimpulan

Seperti kita hanya melihat ~~neraka~~ IPSec adalah tidak menakutkan seperti yang dicat. Semua yang telah dijelaskan adalah konfigurasi operasional penuh yang saat ini digunakan. Bahkan tanpa banyak pengetahuan, Anda dapat mengkonfigurasi VPN dan melindungi data Anda dengan andal.

Tentu saja, saat-saat pengaturan iptables tetap berada di luar ruang lingkup artikel, tetapi artikel itu sendiri ternyata sudah sangat banyak, dan banyak yang telah ditulis tentang iptables.

Ada poin-poin dalam artikel yang dapat ditingkatkan, baik itu penolakan untuk memulai ulang daemon Strongswan, membaca kembali konfigurasi dan sertifikatnya, tetapi saya tidak dapat mencapainya.

Namun, daemon yang dimulai ulang tidak menakutkan: satu atau dua ping di antara rekan-rekan terputus, klien seluler memulihkan koneksi sendiri.

Saya harap kolega dalam komentar akan meminta solusi yang benar.

IPSec Mahakuasa