Bulut bilişim sağladığı müthiş imkanlarla artık göz ardı edilemez bir ihtiyaç haline geldi. Bulut platformu sağlayıcılar sizlere VPN çözümleri de sunuyorlar. Ancak ben kendi VPN’imi kurmak istiyorum diyorsanız bu imkan da kendi kuracağınız bir VPN gateway host ile her zaman mevcut.
Bu makalede kullanacağımız bulut platformu Amazon EC2 olacak. VPN gateway olarak Ubuntu 14.04 LTS, istemci olarak da Windows 7 ve Kali Linux platformlarını kullanacağız.
VPN’in faydalarını uzun uzun anlatacak değilim, sadece şunu vurgulamak istiyorum; burada belirteceğimiz çözüm elbette Amazon’daki internetten erişilemeyecek sunucularınızın üzerinde çalışan güvenli veya güvensiz (http, telnet, v.b. gibi) servislere internet üzerinden VPN tüneli ile kriptolu olarak erişmenizi sağlayacak, ancak siz de bir istemci olarak bu tünel sayesinde tünelin ucunda bulunan noktadan (ör: Almanya, ABD, Japonya, v.d.) internete çıkış yapabilirsiniz. Burada insanlara Türkiye’de zaman zaman uygulanan internet erişim yasaklarını nasıl aşacaklarını öğretmeyi hedeflemiyoruz, ancak böyle bir niyeti olan kişilerin bilgisayarlarına kuracakları (sözde) ücretsiz VPN istemci yazılımları ile bilgisayarlarını ve trafiklerini kime teslim ettiklerini bilmeden bu işi yapmaları yerine kendilerine ait bir VPN çözümü ile yapmaları ülkemizde ele geçirilecek bilgisayar sayısını biraz da olsa azaltabilir. Tabi çıkış yaptığınız ülke ve bulut platformunun sahibi olan firmanın bulunduğu ülke otoritelerinin sizi dinlemesinden korunamazsınız.
Burada kuracağımız VPN senaryoları host-to-host senaryolar olacak. Yani uçtan uca bir tünel kuracağız. Kendi ucunuzda bir gateway’de kullanabilirsiniz. Pratikte Amazon’daki VPN sunucumuz da bir gateway gibi çalışacak ve Amazon’da bulunacak ve internetten erişilemeyecek sunucularımıza ve tabi istersek internete de bu gateway üzerinden erişeceğiz.
Şimdi kullanacağımız VPN çözümüne geçebiliriz. Ben kendi geçtiğim yolu anlatayım isterseniz. Önce pek çok kişinin de yapabileceği gibi OpenVPN’i denetim. Kurulumu kolay, istemci ve sunucu tarafında grafik arayüzleri olan güzel bir çözüm. Ama bu güzelin bir kusuru var, adındaki Open yanıltıcı, sizi 2 eşzamanlı kullanıcı ile kısıtlıyor. Bu gerçeği daha önceden de kendi ortamımızda yaptığımız kurulumlardan biliyordum, ama Amazon’un AWS Marketplace’inde OpenVPN’i gördüğümde olabilir mi acaba demeden edemedim. Daha sonra OpenSWAN adlı proje dikkatimi çekti. Tabi bu aşamada OpenSWAN’ın FreeSWAN projesinin bir alt kolu olduğunu bilmiyordum. Yine Open adı beni yanlış bir yola yönlendirdi. OpenSWAN ile yıldızımız bir türlü barışmadı. En büyük sıkıntı yok denecek kadar az olan dokümantasyondu. Neredeyse kodları inceleyesim geldi, o derece kötü idi durum. OpenSWAN’dan da ümidi kesince bu projenin orijin’i olan FreeSWAN projesinden ortaya çıkan bir başka projenin de StrongSWAN olduğunu öğrendim. Tabi OpenSWAN’la yaptığım bunca debelenme de süreci biraz hızlandırdı. Ama ayağa kaldırabildiğim, dokümantasyonu orta derecede mevcut, bakımı OpenSWAN’a göre daha iyi yapılan bir proje olarak StrongSWAN seçtiğim (daha doğrusu seçmek zorunda olduğum) çözüm oldu. Bir başka FreeSWAN türevi olan LibreSWAN’ı deneyemedim (ki bunun için çokta üzüldüğümü söyleyemem) ancak bu proje de StrongSWAN ayarında bir proje gibi görünüyor.
Protokol olarak da IKEv2 protokolünü seçtim. Bunun nedeni oldukça basit, çünkü L2TP ve PPP konfigürasyonları ve bu protokollerdeki sıkıntıları debug etmekle uğraşmak zorunda kalmıyorsunuz. Bu arada yukarıda belirtmeyi atladım, VPN çözümümüz bir IPSec çözümü. IKEv2 desteği modern işletim sistemlerinin hemen hepsinde mevcut ve kullanımı yukarıda belirttiğim nedenden dolayı daha kolay.
Artık kurulum stratejimize ve makalenin organizasyonuna geçebiliriz:
- Öncelikle Amazon’da internetten erişilebilir bir Ubuntu instance’ı başlatacağız.
- Ubuntu sunucumuz üzerinde bir (tabi ki self signed) CA sertifikası oluşturacağız (bu sertifikayı daha sonra istemcilerin Trust store’larına yüklememiz lazım, yoksa istemciler VPN sunucusuna güvenmeyecek ve VPN bağlantınız kurulamayacaktır).
- Bir sunucu sertifikası oluşturacağız ve bu sertifikayı oluşturmuş olduğumuz CA özel anahtarı ile imzalayacağız.
- StrongSWAN kurulumunu Ubuntu’nun paket manager’ı ile yapacağız. Kaynak kod’dan kurulum yapmak isteyenler tabi ki bu yolu da izleyebilir. Kaynak kod’dan kurulum ihtiyacı son sürümü kullanmak isterseniz veya çok özel bir ihtiyacınız varsa ortaya çıkabilir.
- StrongSWAN konfigürasyonunu yapacağız. İşin özü bu noktada. Göreli olarak uzun olsa da çok uzun olmayan, ancak hataya çok açık bir adım bu adım. Sertifika ayarı da bu adımda gerçekleşecek.
- Windows 7 istemcimizde yeni bir bağlantı konfigüre edeceğiz ve VPN erişimimizi gerçekleştireceğiz.
- Kali Linux istemcimizde NetworkManager uygulaması ile VPN bağlantımızı konfigüre edeceğiz ve VPN erişimimizi gerçekleştireceğiz (biz Kali’yi kullanacağız ama hemen hemen tüm Linux’larda benzer yol izlenebilir).
- Amazon’da internetten erişilemeyecek bir instance daha başlatacağız ve bu instance’a (örneğin ssh servisine) VPN tüneli üzerinden erişeceğiz.
- Makalenin ilgili bölümlerinde problemlerle karşılaştığınızda başvurulabilecek bazı debug imkanlarına da değineceğiz.
Amazon Web Services sitesi’ne erişelim
Buradan Amazon hesabımız ile konsol uygulamasına erişelim
Konsol’da hangi Amazon region’ında bulunan kaynaklardan faydalanmak istediğimizi sağ üstten seçelim (biz Seul’ü seçeceğiz)
Bu portal’de sağ üstte bulunan EC2 linkini tıklayalım.
Sayfanın ortasında görülen Launch Instance düğmesini tıklayalım
Üzerine VPN servisini kuracağımız Ubuntu Server Amazon Machine Image’ımızı seçelim.
Bu noktada network performansı bizim için çok önemli olabilir. Buna göre daha aşağılarda bulunan farklı bir imajı seçmek isteyebilirsiniz. Imajlar kullandıkları kaynak büyüklüklerine göre farklı fiyatlandırmalara tabi. Makalemiz için basit bir erişim denemesi yapacağımızdan ben öntanımlı olarak seçili olan imajı kullanacağım.
Next: Configure Instance Details düğmesine tıklayarak bir sonraki sayfaya geçelim (öntanımlı ayarlarla bu noktada da imajınızı başlatabilirsiniz, ama ben genel olarak ayarlardan bahsetmek istiyorum)
Amazon her bir region’ı içinde farklı availability zone’lar da sağlıyor. Region’ları farklı data center’lar olarak düşünmek lazım, bu region’lar arasında bir local area konfigürasyonu da (öntanımlı olarak) sağlanmıyor. Ama aynı region’ın içinde farklı availability zone’lar aynı LAN’da gibi çalışabiliyor.
Yani farklı subnet’leri farklı availability zone’lara yerleştirebilirsiniz.
Açıkçası Amazon veya diğer tüm bulut platformları (ilk bakışta kolaymış gibi görünse de) kendine has kurallara sahip ve karmaşık sayılır. Bu nedenle ciddi dokümantasyon okumak gerekiyor. Ben burada bizi etkileyebilecek birkaç konuya değinmek istiyorum.
Amazon’da her region’da sizin için öntanımlı olarak yaratılmış bir VPC (Virtual Private Cloud) var. VPC nedir derseniz; subnet yapısını, IP adreslemesini, routing kurallarını kendi ihtiyaçlarınıza göre yönetebileceğiniz bir mantıksal izolasyon kavramı. Sizin için öncelikli olan bilgi şu: öntanımlı VPC ve bununla birlikte gelen öntanımlı subnet’ler için internete erişim için gereken tüm routing kuralları hazır olarak geliyor. Eğer ben kendi VPC’mi ve subnet’lerimiz yaratacağım diyorsanız şu linkleri okumanız ve biraz da egzersiz yapmanız gerekiyor (bu linkler birer başlangıç noktası, daha fazla okumanız da gerekebilir):
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html#Create-VPC
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
Öntanımlı VPC ve subnet’i kullandığınızda sunucunuza otomatik olarak bir public IP ve bir public DNS adı’da atanacak. Bu public IP’yi kullanarak sunucunuza internetten (Security Group kurallarınıza bağlı olarak) erişebileceksiniz. Security Group konusuna birazdan değineceğim. Kendi tanımladığınız VPC’lerde başlatacağınız instance’larla gerekli routing tablolarını ilişkilendirmezseniz public IP alabilirsiniz ama bu IP’ye yapacağınız erişim sizin instance’ınıza yönlendirilmez. Yani sunucunuza erişemezsiniz.
Normalde bir üretim sunucusunun her reboot edildiğinde farklı bir public IP almasını istemezsiniz. Amazon’un bu ihtiyaca çözümü Elastic IP hizmeti. Elastic IP’leri bir instance’a bağlandığı ve kullanıldığı süre boyunca ücretsiz kullanıyorsunuz, ancak eğer atıl bir şekilde tutuyorsanız (makalenin yazıldığı tarihteki fiyatıyla) saatlik 0,005 USD’lik bir maliyete katlanıyorsunuz. Bu arada Amazon’un fiyatlarının region’dan region’a farklılık gösterebildiğini de eklemeliyim. Elastic IP kullanmanız halinde makinenizi stop etseniz dahi bir sonraki aktif hale getirmeniz sırasında aynı public IP’yi kullanabilirsiniz. Aksi takdirde makine her seferinde havuzdan farklı bir IP alacak, bu da tüm istemcilerde yeniden düzenleme (ve bizim durumumuzda ayrıca sunucu sertifikasının yeni IP adresine uygun biçimde tekrar üretilmesi) ihtiyacına neden olacak. Biz örneğimizde Elastic IP kullanmayacağız, siz de kullanmayacaksanız sunucu sertifikasının her seferinde tekrar üretilmesi ihtiyacını unutmayınız.
Next: Add Storage düğmesine tıklayarak bir sonraki adıma geçiyoruz.
Bu adımda storage tipinizi ve büyüklüğünü belirleyebilirsiniz. Eğer storage’ınızın instance’ınızı terminate ettikten sonra da yaşamasını istiyorsanız “Delete on Termination” seçimini kaldırabilirsiniz (ben henüz denemedim). Amazon bulut hizmetlerinde her özelliğin bir maliyeti var, yani storage’ınızın instance silindikten sonra da yaşaması demek bu kaynak için para ödemeye devam edeceğiniz anlamına gelir. İhtiyaçlarınıza bağlı olarak bu imkanı kullanabilir veya kullanmayabilirsiniz. Storage konusu da okuma ihtiyacı olan bir konu, özellikle bulutta veri işleyen bir uygulama barındıracaksanız.
Amazon kendi imajlarınızı oluşturmaya da imkan veriyor (bunu da denemedim ve bu da ücretli bir hizmet).
Öntanımlı ayarları tutarak devam ediyorum. Bir prod sunucusunda loglama ihtiyaçlarıma bağlı olarak belki storage kapasitesini artırmayı tercih edebilirim.
Next: Tag Instance düğmesine tıklayarak bir sonraki adıma geçiyoruz.
Tag’ler zannediyorum çok sayıda instance’ınız olduğunda ihtiyaç duymaya başladığınız bir konu, bu etiketleri kullanarak arama yapma ihtiyacınız olabilir. Ben bu adımda öntanımlı olarak gelen Name tag’ine BTRiskVPN adını verip geçeceğim.
Next: Configure Security Group düğmesine tıklayarak devam ediyoruz.
Öntanımlı Security Group adı ve açıklamasını değiştireceğim. Ayrıca SSH erişimini de sadece kendi kaynak IP adresimle değiştireceğim. Daha sonra bu gruba IPSec VPN erişimi sağlayabilmek için yeni kurallar da ekleyeceğim.
Security Group ayarlarını şu şekilde düşünün, her bir sunucu instance’ının önünde bir firewall var ve bu sunucuya atanan SG’da bu firewall’un kurallarını içeriyor. Aynı subnet’te olsalar bile her bir sunucu için SG ayarı yapmak zorundayız (benim anladığım kadarıyla).
Review and Launch düğmesine basarak ilerliyoruz.
Launch düğmesine tıklayarak instance’ımızı başlatalım.
Bu noktada Amazon bize sunucuya erişebilmemiz için bir anahtar çifti soruyor. Bu anahtar Linux sunucular için SSH erişiminde kullanılıyor, Windows sunuculara erişimde de Terminal Servisi erişimi için Administrator parolası alabilmek için gerekli. Biz yeni bir anahtar çifti oluşturacağız. Burada unutulmaması gereken konu oluşturulacak özel anahtarın bilgisayarınıza kaydedileceği, bunun güvenliğinden sizin sorumlu olmanız ve tabi ki anahtarı kaybetmemeniz. Yoksa sunucunuza ulaşma imkanınız olmayacaktır.
Yeni bir anahtar çifti seçme seçeneğini seçtikten sonra anahtar çiftimize BTRisk-Seul adını verdim. Şimdi Download Key Pair düğmesini tıklayarak özel anahtarımızı bilgisayarımıza indirelim. (Bu adımın özel anahtarı indirmek için tek şans olduğu ekranda da belirtiliyor)
PEM uzantılı özel anahtarımı BTRISK dizinimin altına kaydettim.
Putty’yi SSH client olarak kullanmam gerektiğinde PEM formatını PPK formatına dönüştürmem gerekecek.
Artık instance’ımı başlatmaya hazırım. Launch Instances düğmesine basarak instance’ımızı başlatalım.
Son ekrandaki instance id’sine tıkladığınızda veya EC2 konsolundan instances linkine tıkladığınızda durumu izleyebilirsiniz. Birkaç dakika içinde sunucumuza erişebileceğiz.
Şimdi yukarıda bahsettiğim anahtar format dönüşümünü gerçekleştirelim.
Bunun için PuTTYgen aracını kullanacağız. PEM formatındaki özel anahtar dosyasını yükleyebilmek için All Files seçeneğini seçerek anahtar dosyasını görüntülememiz lazım.
Biz yeni bir anahtar üretmeyeceğiz, sadece var olan bir anahtarın formatını değiştireceğiz. Bunun için Save private key düğmesini tıklayarak özel anahtarımızı PPK formatında kaydedelim.
Bu adımda PuTTYgen bizi özel anahtarı korumak için bir passphrase kullanmamız konusunda bizi uyarıyor. Önemli bir operasyon için kullanmanız halinde elbette anahtarı passphrase ile korumak lazım. Ben tembellik edip passphrase kullanmayacağım ve Yes seçeneğini tıklayarak PPK dosyasını ürettireceğim.
Artık PuTTY ile sunucumuza erişmeye hazırız. Ama önce Amazon’un bize verdiği public IP adresini öğrenelim.
Sunucumuz ayağa kalkmış (running statüde) ve 52.79.37.208 IP adresini almış. Daha önceden ilgili Security Group tanımında kendi public IP adresimize SSH erişim iznini vermiştik hatırlarsanız. Şimdi PuTTY üzerinde erişim için gerekli tanımları yapalım.
Bu erişim bilgilerini daha sonra da kullanabilmek üzere AMAZON isimli bir oturum tanımlıyorum ve IP adresini giriyorum.
Aşağıdaki adımda yapılacak kullanıcı kodunu “ubuntu” olarak tanımlamak önemli, zira Ubuntu normalde “root” ile SSH erişimine izin vermiyor.
Son olarak özel anahtarımızın yolunu aşağıdaki gibi tanımlıyoruz.
Open düğmesine bastığımızda bağlantı sağlanıyor ve sunucu tarafından iletilen açık anahtara güvenip güvenmediğimiz soruluyor. SSH erişiminde bir sertifika otoritesi mantığı olmadığı için istemci bizi uyarıyor.
Yes diyerek devam ediyoruz. Çok hassas iseniz elbette bu anahtarın doğruluğunu kontrol etmek isteyebilirsiniz.
Artık StrongSWAN kurulumumuza başlayabiliriz.
Bildiğiniz gibi önerilmez, ama ben tüm işlemleri root modunda yapacağım. Zaten kurulum aşamasında bu hakka ihtiyacım var, yoksa her komutun başında “sudo” yazmam lazım.
Kurulumda pek çok paket kuracağız. Bunun nedeni StrongSWAN’ın modüler bir yapıya sahip olması. Bunların hepsine ihtiyacımız olmayacaktır muhtemelen, ama mümkün olan tüm fonksiyonaliteyi aşağıdaki komutla sunucumuza indirelim ve kuralım. Örneğin EAP ve MSCHAPv2 protokollerini kullanacağımız için strongswan-plugin-eap-mschapv2 plugin’ine kesinlikle ihtiyacımız var. Bu arada paket isimleri Linux dağıtımlarına göre farklılaşıyor, hatta stable StrongSWAN versiyonları da farklı işletim sistemleri için farklı. Buradaki paket isimleri Ubuntu için geçerli, farklı bir Linux işletim sisteminde farklı isimlendirmelerle karşılaşırsınız.
# apt-get install strongswan strongswan-plugin-af-alg strongswan-plugin-agent strongswan-plugin-certexpire strongswan-plugin-coupling strongswan-plugin-curl strongswan-plugin-dhcp strongswan-plugin-duplicheck strongswan-plugin-eap-aka strongswan-plugin-eap-aka-3gpp2 strongswan-plugin-eap-dynamic strongswan-plugin-eap-gtc strongswan-plugin-eap-mschapv2 strongswan-plugin-eap-peap strongswan-plugin-eap-radius strongswan-plugin-eap-tls strongswan-plugin-eap-ttls strongswan-plugin-error-notify strongswan-plugin-farp strongswan-plugin-fips-prf strongswan-plugin-gcrypt strongswan-plugin-gmp strongswan-plugin-ipseckey strongswan-plugin-kernel-libipsec strongswan-plugin-ldap strongswan-plugin-led strongswan-plugin-load-tester strongswan-plugin-lookip strongswan-plugin-ntru strongswan-plugin-pgp strongswan-plugin-pkcs11 strongswan-plugin-pubkey strongswan-plugin-radattr strongswan-plugin-sshkey strongswan-plugin-systime-fix strongswan-plugin-whitelist strongswan-plugin-xauth-eap strongswan-plugin-xauth-generic strongswan-plugin-xauth-noauth strongswan-plugin-xauth-pam strongswan-pt-tls-client
Eğer StrongSWAN’ı kaynak kodundan derlemek ve kurmak isterseniz aşağıdaki işlemleri gerçekleştirmeniz gerekir.
Bağımlılıkları kurmak için:
- apt-get -y install gcc
- apt-get -y install make
- apt-get -y install libgmp3-dev
- wget http://download.strongswan.org/strongswan-x.x.x.tar.bz2
- tar xjf *.bz2
- ./configure --prefix=/usr --sysconfdir=/etc
- make
- make install
StrongSWAN kurulum sonrası hemen çalıştırıldı, ama bu haliyle tabi ki işimize yaramaz.
Yukarıdaki çıktıda belki dikkatinizi çekmiştir, sunucumuza atanan local IP adresi 172.31.7.136. Biz sunucuya Amazon’un sağladığı NAT imkanı sayesinde internetten erişiyoruz. Ama IPSec VPN’imiz bu IP’yi tanımıyor, kendisini yukarıdaki local IP adresine bağlamış durumda. Bu durum bizi engellemeyecek, çünkü IPSec’in NAT desteği var. Ancak bu gerçeği de aklımızda tutmamız lazım. İstemci’ler public IP olan 52.79.37.208 adresine bağlandıklarını düşünecek, ancak bu adres 172.31.7.136 private IP adresine NAT’lanacak. Bu durum StrongSWAN konfigürasyonunda öntanımlı olarak destekleniyor, ama OpenSWAN’da başıma çok iş açmıştı.
Bir sonraki adımda sertifika işlemlerimizi gerçekleştireceğiz. IKEv2 protokolünü kullanacağımız için bu gerekli. L2TP tünelleme kullanıyor olsa idik buna ihtiyaç olmayacaktı. Ama daha önce de belirttiğim gibi hem tünelleme hem de kriptoloma işlemini tek protokolle halletmek için bu yolu izleyeceğiz.
Öncelikle sertifika işlemlerini yapmak için StrongSWAN kurulumu sırasında oluşturulan /etc/ipsec.d/ dizininin altına geçelim.
# cd /etc/ipsec.d
Şu ana kadarki makalelerimizde sertifika üretme işlemi için genellikle openssl’i kullandık. Burada StrongSWAN’ı (yani ipsec uygulamasını) kullanalım (muhtemelen o da openssl API’lerini kullanıyordur). Ancak bundan önce haveged paketini kurmamız gerekiyor. ipsec uygulaması haveged olmadan çok uzun çalışıyor (neden bilmiyorum). haveged bir entropy servisi olarak tanımlanıyor, yani pseudo (sözde) random sayı üretmek için yardımcı oluyor diye anlıyorum. Sözde dememin sebebi bir uygulama ile random sayı üretmek için mutlaka bazı girdilere ihtiyacımız olmasından kaynaklanıyor, bu girdiler de genellikle uygulamanın çalıştığı donanımın bazı özelliklerinin değerleri olarak kullanılıyor. Gerçek bir rassallık mümkün değil yani.
# apt-get install haveged
Ayrıca haveged servisini başlatmamız gerekiyor.
# service haveged restart
Şimdi özel anahtarımızı aşağıdaki komut ile oluşturabiliriz.
# ipsec pki --gen --type rsa --size 4096 --outform der > private/strongswanKey.der
Ayrıca oluşturduğumuz özel anahtar dosyasına erişim haklarını sadece “root” kullanıcısı erişebilecek biçimde düzenliyoruz.
# chmod 600 private/strongswanKey.der
Bir sonraki adımda public (açık) anahtarımızı oluşturacağız ve bu anahtarı az önce oluşturduğumuz özel anahtar ile imzalayarak (kriptoloyarak) kendi imzaladığımız (self signed) CA sertifikasını oluşturacağız. Evet PKI altyapısı CA özel anahtarının güvenliğine bağlı, CA’nın üzerinde başka bir merci yok.
# ipsec pki --self --ca --lifetime 3650 --in private/strongswanKey.der --type rsa --dn "C=TR, O=BTRisk, CN=BTRiskVPN Root CA" --outform der > cacerts/strongswanCert.der
Oluşturduğunuz sertifikanın özelliklerini aşağıdaki komutla görebilirsiniz.
# ipsec pki --print --in cacerts/strongswanCert.der
CA sertifikamızı 2026 yılına kadar kullanabiliriz. Bir CA operasyonu tabi ki bu kadar basit değil. İptal edilen sertifikalar için CRL altyapısını kurmak ve muhtemelen daha farklı konuların da halledilmesi gerekiyor. Ancak bizim ihtiyacımız bu kadar.
Şimdi sıra sunucu sertifikamızı üretmekte. Eğer paranız çoksa bu sertifikayı tüm üreticilerin tanıdığı güvenilir bir sertifika otoritesinden alarak bu zahmetlere katlanmayabilirsiniz. Ama paranız olsa bile işin detayını öğrenmek ve kendiniz yapmak istemeseydiniz bunu okuyor olmazdınız herhalde.
Sunucu sertifikasını üretmek için önce yine bir özel anahtar üretmemiz gerekiyor.
# ipsec pki --gen --type rsa --size 4096 --outform der > private/BTRiskVPNHostKey.der
Sunucu sertifikamızın erişim haklarını da sadece “root” kullanıcısı tarafından erişilebilecek biçimde düzenliyoruz.
# chmod 600 private/BTRiskVPNHostKey.der
Hem imzalama isteğini üretmek, hem de sertifika otoritesine sertifikayı imzalatmak için aşağıdaki tek satırlık komutu kullanabiliriz (/etc/ipsec.d/ dizininin içinde olmak koşuluyla):
# ipsec pki --pub --in private/BTRiskVPNHostKey.der --type rsa | ipsec pki --issue --lifetime 730 --cacert cacerts/strongswanCert.der --cakey private/strongswanKey.der --dn "C=TR, O=BTRisk, CN=vpn.btrisk.com" --san 52.79.37.208 --san @52.79.37.208 --flag serverAuth --flag ikeIntermediate --outform der > certs/BTRiskVPNHostCert.der
Yukarıda bahsetmeye değer konular şunlar. Öncelikle vpn.btrisk.com diye bir alan adı yok. Aslında Amazon bize bir public DNS adı sağlıyor ve bunu sertifikayı oluştururken kullanabiliriz. Ancak biz VPN sunucumuza erişirken alan adını kullanmak yerine IP adresini kullanacağız. Bunun için de Subject Alternative Name (SAN) özelliğini kullanacağız. IP adresini bir de başında @ işareti ile kullanmamızın sebebi (denemedim, ama okuduklarımdan anladığım kadarıyla) Apple cihazlarda da sıkıntı yaşamadan bağlantı için IP adresini kullanabilmek.
Oluşturduğumuz sunucu sertifikasının özelliklerini görmek için aşağıdaki komutu kullanabiliriz.
# ipsec pki --print --in certs/BTRiskVPNHostCert.der
Sunucu sertifikası oluşturmak için kullandığımız tüm özellikleri açıklamadım, ama flags bölümünde geçen özellikler IPSec servisini kullanabilmemiz için önemli. Ayrıca altNames bölümünde de IP adresimiz görünüyor.
Sunucu sertifikamız da oluştuktan sonra ipsec konfigürasyonumuzu yapabiliriz.
Öncelikle ipsec veya SSL protokolü kriptolama, anahtar değişimi ve hashing için çok sayıda kombinasyonu destekliyor. Bunun da ötesinde ipsec protokolü çok farklı authentication protokol ve yöntemlerini de destekliyor. Örneğin sunucu ve istemci’nin birbirini doğrulaması için L2TP kullanıyor olsa idik bir Preshared Key’de kullanabilirdik, ancak biz bir RSA sertifikası ile sadece sunucuyu doğruluyoruz. Bundan sonraki aşamada kullanıcı doğrulama geliyor. Eğer çok ileri güvenlik ihtiyaçlarınız varsa StrongSWAN’ı Radius kullanacak biçimde konfigüre edip kulanıcıları bir Aktif Dizin sunucusunu kullanarak doğrulayabilir ve/veya bir OTP (Tek Kullanımlık Parola) çözümü ile de entegre edebilirsiniz. Bizim seçtiğimiz yöntem kullanıcılara atanmış olan kullanıcı adları ve parolaların ipsec çözümü içinde doğrulanması olacak. Teknik olarak kullanacağımız protokol EAP, ancak EAP sadece bir üst protokol, kendi içinde pek çok protokolü destekliyor.
Aşağıda uzun deneme ve yanılmalar sonucunda ulaştığım çalışan, basit bir ipsec konfigürasyonunu görebilirsiniz. “/etc/ipsec.conf” dosyası içinde bulunan bu konfigürasyonu olabildiğince açıklamaya çalışacağım. StrongSWAN dokümantasyonu elbette size geri kalan durumlarda yardımcı olacaktır.
config setup
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=3
keyexchange=ikev2
conn IPSec-IKEv2-EAP-VIP
left=%defaultroute
leftsubnet=0.0.0.0/0
[email protected]
leftcert=BTRiskVPNHostCert.der
leftsendcert=always
leftauth=pubkey
leftfirewall=yes
right=%any
rightauth=eap-mschapv2
rightsendcert=never
eap_identity=%any
rightsourceip=10.251.0.0/24
rightdns=8.8.8.8,2001:4860:4860::8888
auto=add
“config setup” bölümü genel konfigürasyon parametreleri için kullanılıyor. Bizim bu alanda bir ihtiyacımız olmamış, zaten çok fazla bir parametre de içeremiyor bu alan, ama ilgilenirseniz bu bölümle ilgili dokümantasyon linki şu şekilde: https://wiki.strongswan.org/projects/strongswan/wiki/ConfigSetupSection. Bu bölümde en kayda değer ayar debug detayı ile ilgili olan bölüm olabilir. Ipsec bağlantılarını debug etmek gerçekten çok yorucu ve kör döğüşü şeklinde gerçekleşiyor. Çünkü kendi yazmadığınız bir çözümün logladığı ifadeler üzerinden ve son derece karmaşık protokollerle ilgili anlamlar çıkarmaya çalışıyorsunuz. Ancak bu bilgiler bile en azından size tutunacak bir dal veriyor ve bunları kullanarak internette çözüm arayabiliyorsunuz. Örnek bir konfigürasyon ayarı aşağıdaki gibi olabilir (Ubuntu için syslog dosyasında bu logları izleyebilirsiniz).
config setup
charondebug="ike 4, knl 4, cfg 4"
Debug işlemine geçmeden önce şu konulara göz atmanız faydalı olabilir; Amazon sunucunuzun public ip adresi değişmişse sunucu sertifikanızı tekrar üretin ve mutlaka StrongSWAN ile ilgili herhangi bir değişiklik sonrasında “ipsec restart” komutu ile değişikliklerinizin etkin olmasını sağlayın.
Eğer aynı kullanıcı kodu ile birden fazla VPN oturumu yapılabilmesini istiyorsanız “config setup” bölümünde “uniqueids=never” ayarını kullanabilirsiniz.
“conn” ile başlayan section’lar bağlantı tanımlarını içeriyor. “config setup” section’ı bir tane olabilir, ancak “conn” (ve biz kullanmıyoruz ama “ca”) section’ları birden fazla olabilir.
Tüm “conn” section’ları “conn %default” bölümündeki ayarlarıda otomatik olarak alır.
“conn %default” bölümünde anahtar değişimi için ikev2 protokolünü kullanacağımızı belirtiyoruz. Tünelleme için L2TP veya PPTP gibi protokollerle uğraşmak istemediğimiz için ikev2’yi tercih ettiğimizi söylemiştim. Yani IKEv2 sadece anahtar değişikliği için değil tünelleme fonksiyonu için de kullanılacak.
Bu bölümün altındaki bağlantı konfigürasyonunun isminin hiçbir önemi yok. Ben bu bağlantının IPSec, IKEv2 ve EAP protokollerini kullandığı ve Virtual IP (yani istemcide bağlantı sonrasında ekstra bir arayüz oluşturulması ve bu arayüze de VPN sunucu tarafından bir IP adresi verilmesi) imkanını kullandığı anlamında bir isim verdim.
“ikelifetime” parametresi tekrar bir negotiation olmadan önce aynı anahtar değişim kanalının ne kadar aktif kalması gerektiğini belirtiyor. Öntanımlı değeri 3 saat.
“keylife” (lifetime parametresi olarak da kullanılabiliyor) bir bağlantının tekrar negotiate edilmeden önce ne kadar yaşaması gerektiğini belirtiyor. Öntanımlı değeri 1 saat.
“rekeymargin” (margintime parametresi olarak da kullanılabiliyor) bir bağlantının ya da anahtar değişim kanalının zaman aşımına uğramadan ne kadar önce yeni negotiation sürecinin başlaması gerektiğini belirtiyor. Öntanımlı değeri 9 dakika.
“keyingtries” parametresi bir bağlantı negotiation işleminin işlemden vazgeçilmeden önce kaç defa yapılabileceğini belirtiyor. Öntanımlı değeri 3 defa.
“keyexchange” parametresi adından da tahmin edilebileceği gibi anahtar değişimi için kullanılacak protokolü belirtiyor. Öntanımlı değer “ike” ve bu değer StrongSWAN 5.0.0 versiyonu sonrasında ikev2 anlamına geliyor.
Aslına bakarsanız bu bölümdeki tüm parametreleri ihmal edebilirdik ve ikev2 bağlantımız çalışırdı, çünkü öntanımlı değerler benim için yeterli idi. Benim örnek aldığım konfigürasyonda bu parametreler tanımlı olduğu için ben de kullanmış oldum.
IPSec-IKEv2-EAP-VIP bölümündeki left ve right kavramları tarafları ifade ediyor. Aynı kavramlar StrongSWAN’ı kullanan bir istemci için de kullanılabilir. Kafanızı karıştırmak gibi olmasın ama eğer bu parametrelere bir IP atanmışsa ve bu IP’lerden birisi sunucu üzerinde tanımlı ise sunucu kendisini bu tarafmış gibi görüyor. Ama daha basit bir yaklaşım ve kafanızın karışmaması için left ve right’ın ne anlama geldiğini şu şekilde hatırınızda tutabilirsiniz. (L)eft’in L’si LOCAL’in ilk harfi ile aynı, (R)ight’ın R’si REMOTE’un ilk harfi ile aynı. Yani Left ile başlayan konfigürasyon parametreleri VPN sunucusu ile ilgili, Right ile başlayanlar ise istemci ile ilgili parametreler olarak tanımlanabilir. Böylece daha az kafa karıştırıcı bir yöntem izlemiş olursunuz.
“left” parametresi (yukarıda left’i sunucu olarak düşünelim demiştik) sunucunun IP adresinin, alan adının ve diğer özel değerlerin belirtildiği alan. Taraf parametreleri Security Association’ları ile ilgili kuralları ve IPSec’in sizin için halletmesini isteyeceğiniz routing kurallarını oluşturması gibi imkanları içerdiğinden önemli ve zaten sizi en çok uğraştıracak bölüm. Biz burada %defaultroute değerini seçtik, çünkü kullandığımız sunucu bir Amazon instance’ı ve biz bir sabit local IP adresi belirlemedik. Bu değer sayesinde IPSec servisi ne zaman başlarsa başlasın IP adresi olarak default-route IP adresini kullanacak. Belki %any değeri de kullanılabilirdi, ancak bu haliyle çalışıyor ve %any değerini denemedim.
“leftsubnet” parametresi son derece önemli. Network tekniği olarak çok iyi anlatamayacağım, ancak istemci bu VPN servisine bağlandığında istemci tarafında oluşacak routing kurallarında hangi network’e iletilecek paketlerin bu tünel içinden route edilmesi gerektiği anlamına geliyor. Buradaki ayarımız biraz kaba (split tunnelling’i desteklemiyor, yani bilgisayar kullanıcısı internete kendi mevcut arayüzünden çıksın ve sadece belli bir subnet’e iletilen paketler tünelden iletilsin’I desteklemiyor) ama çalışıyor. Split tunneling’I desteklemediği için bazı kullanımlar için uygun olmayabilir, çünkü (tüm internet erişimi dahil olmak üzere) kullanıcının kendi LAN’ı dışındaki tüm trafik VPN tünelinden taşınıyor. Split tunneling için lütfen dokümantasyonu okuyun ve bol bol deneme yapmanız gerekebileceğini unutmayın. Belirttiğim gibi 0.0.0.0/0 ayarı ile istemci tarafında LAN dışındaki tüm trafiği VPN kanalına yönlendirmiş oluyoruz. Bu kaba yöntem eğer Amazon tarafında tek bir subnet değil de çok sayıda subnet oluşturduysanız da sizi uğraşmaktan kurtarabilir, çünkü bu durumda bu subnet’leri ayrı ayrı belirtmeniz lazım. Ayrıca istemci uyumsuzlukları da sizi uğraştırabilir.
“leftid” parametresinin konfigüre edilmesi gereksiz, çünkü dokümantasyon bu değerin left parametresinde belirtilen IP adresine öntanımlı olarak ayarlandığını söylüyor. Zaten bunun karşılığı olan rightid diye bir parametre de yok gördüğünüz gibi ve sorun çıkmıyor. @ işareti de alan adı kullanılması halinde bunu çözümletmemek için de kullanılıyormuş. Aslına bakarsanız alan adı da geçerli değil, ama kaynak olarak kullandığım konfigürasyonda mevcuttu ve ben de kaldırmadım. Hem left’in sunucu tarafı olduğunu hatırlamama da yardımcı oluyor. Yalnız burada kullandığım alan adı ürettiğim sunucu sertifikasındaki alan adı ile tutarlı, bu önemli olabilir. Kullanacaksanız aklınızda olsun.
“leftcert” parametresi tabi ki çok önemli. VPN sunucusunun sertifika dosyasının adını belirtiyor. Burada belirtilen yol /etc/ipsec.d/certs dizinine göreli (relative) olabilir, aksi durumda tam yolu belirtmeniz lazım. Sertifikalar PEM veya DER formatında olabilir.
“leftsendcert” parametresi gönderme, sorulduğunda gönder ve gönder gibi değerler alıyor. Biz zaten sunucu sertifikasına ihtiyaç olduğunu bildiğimiz için “always” seçeneğini belirlemişiz. Öntanımlı değeri “ifasked” yani sorulursa gönder.
“leftauth” ve “rightauth” parametreleri oldukça karmaşık olabilir. Biz sunucu tarafının authentication’ı için sertifika kullanıyoruz, bu nedenle “pubkey” değerini kullanmışız. İstemcilerin doğrulanması içinse istemcilere vereceğimiz kullanıcı kodu ve parolalarını kullanacağız. Bu nedenle aşağıdaki rightauth parametresi “eap-mschapv2” olarak belirlenmiş.
“leftfirewall” parametresi “yes” olarak belirlendiğinde StrongSWAN bizim için remote istemciden gelen paketlerin forward edilebilmesi için Ubuntu Server üzerindeki iptables kurallarını geçişe izin verecek biçimde düzenliyor. Yani biz ekstra bir kural yazmak zorunda kalmıyoruz. Bununla birlikte hiçbir kural içermeyen bir iptables yapısında bu parametreye ihtiyaç olur mu, açıkçası şüpheliyim.
“right” parametresi %any olarak belirtilerek oluşturulacak SA (Security Association)’larda istemci tarafının herhangi bir IP adresine sahip olabileceği belirtilmiştir.
“rightauth” parametresi ile yukarıda da belirtildiği üzere remote kullanıcı doğrulama amacıyla eap-mschapv2 protokolü kullanılacaktır. Kullanıcı adı ve parola bilgileri aşağıda da belirtileceği gibi /etc/ipsec.secrets dosyası içinde belirtilecektir.
“rightsendcert” parametresine ihtiyaç var mı, açıkçası denemedim, ama şablonda vardı ve bu haliyle çalışıyor. Çalışması da normal çünkü istemci tarafından herhangi bir sertifika talep etmeyeceğiz.
“eap_identity” parametresi bu bağlantı üzerinden pek çok kullanıcı geleceğinden %any olarak belirtilmiş. Eğer bu bağlantı belli bir kullanıcı için tanımlanmış olsa idi onun kullanıcı adını kullanabilirdik sanıyorum.
“rightsourceip” parametresi son derece önemli, çünkü Virtual IP (yani istemciye IP atama işlemi) havuzu atama özelliği bu parametre sayesinde çalışıyor. Burada istemciye 10’lu bir subnet’ten IP atanmasını öngörüyoruz. Burada önemli olan konu istemcinin kendi ağıyla ve Amazon’da bulunan ağ bölümlerinin adresleri ile çakışmayan bir adres alanının seçilmesi. Bu nedenle 10.251 gibi garip bir adres alanı seçtim. Daha önceki denemelerimde rightsubnet adında bir parametreyi de örnek aldığım bir kaynaktan yola çıkarak kullanmıştım. Ancak birden fazla kullanıcı VPN sunucusuna bağlanamıyordu. Sebebin StrongSWAN tarafından eklenen firewall kurallarında subnet’i kullanması olduğunu, ilk kullanıcıdan sonra gelen kullanıcı da authenticate olduktan hemen sonra aynı kuralı eklemeye çalıştığında hata aldığını ve bunun nedeninin de subnet tanımı olduğunu uzun ve acı debug sürecinin sonunda anladım. Bu yüzden hangi parametreyi ne için kullandığımızı anlamak önemli. Çözümler için para verenleri daha iyi anlıyorum bu durumlarda, çünkü bir sonraki safha kodu okumak ve uygulama mimarisini anlamak, evet mesleki olarak çok doyurucu ama zaman meselesi.
“auto” ayarı ipsec başlatıldığında ilgili bağlantı ile ilgili ne yapılacağını belirtir. Add seçeneği bağlantının yüklenmesi ancak başlatılmaması gerektiğini anlatır. Start olsa idi bağlantı da başlatılacaktı. Gateway-to-gateway bir konfigürasyonda start kullanılabilir. Daha önce OpenSWAN ile yaptığım denemelerden bu ayarın start olarak belirlenmesinin de bir sıkıntı oluşturmadığını gözlemlemiştim.
Son olarak istemciye bir DNS sunucu adresi göndermemiz lazım. Bunun için Google’ın DNS sunucularından birisinin adresini “rightdns” parametresine hem IPv4 hem de IPv6 adres formatında atadım.
Bu konfigürasyonda görülmeyen, ancak daha önce de bahsettiğim gibi OpenSWAN’da başımı belaya sokan NAT Traversal desteği IKEv2 ile öntanımlı olarak StrongSWAN tarafından desteklenmekte, yani herhangi bir ayara gerek yok. NAT Traversal sıkıntısını biraz daha detaylı açıklamak istiyorum, ancak tüm detayları açıklamaya çalışmaktan imtina edeceğim. VPN sunucusunun IP adresinin NAT’lanması (yani bir public IP taşıyan farklı bir gateway’in arkasında bulunması ve kendine ait farklı bir local IP’si olması) halinde, tünelleme ve kriptolama işlemleri sırasında hedef sunucu adresini de içeren gönderilen paket başlık alanları da kriptolanıyor. Bu başlıklar içindeki hedef IP adresi ise VPN sunucusunun public IP adresi (yani aslında VPN sunucusunun arkasında durduğu gateway IP’si). Dolayısıyla paketler tünel içinden hedefe ulaştıklarında aslında sanki farklı bir IP’ye gönderilmiş gibi görünüyorlar. NAT Traversal desteği bu sorunu, burada net biçimde açıklayamayacağım bir şekilde, çözüyor. Bu çözüm için de UDP 4500 portu kontrol kanalı olarak kullanılıyor, bu nedenle bu porta erişimi de açmak durumundayız.
Conn section’ı ile ilgili tam dokümantasyonu şu linkte bulabilirsiniz: https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection
Aşağıda /etc/ipsec.conf dosyası içinde yapmış olduğumuz konfigürasyonu görebilirsiniz.
IPSec sunucumuzu denemeye sadece iki adım uzaktayız (routing işlemlerini daha sonra halledeceğiz).
Bu noktada “/etc/ipsec.secrets” dosyası içinde erişim bilgilerini tanımlamamız lazım. Bu dosya hakkındaki detaylı bilgiye şu linkten ulaşabilirsiniz: https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets
Aşağıda bizim “/etc/ipsec.secrets” dosyasında yaptığımız örnek tanımı görebilirsiniz.
: RSA BTRiskVPNHostKey.der
fatih : EAP "Btr1skpar0la"
Burada yaptığımız birinci tanım sunucunun kullanacağı özel anahtarın adını içeriyor. Normalde iki nokta üst üste “:” karakterinden önce bir ID selector’ü kullanmamız gerekiyor. Eğer kullanılmıyorsa bu satır “:” karakteri ile başlamalı ve herhangi bir sunucu veya bağlantı kuran taraf ID’si için geçerli olur. Bizim durumumuzda bu satır sunucu tarafından kullanılacak.
İkinci bölümde “fatih” adlı kullanıcının ipsec.conf konfigürasyonunda EAP MSCHAPv2 ile bağlanacağını belirttiğimiz parolasının açık hali görülüyor. Açıktır ki bu dosyanın gizliliği son derece önemli. Öntanımlı erişim haklarına da baktığımızda bunu görebiliriz.
Ipsec tarafında yapmamız gereken son işlem “ipsec restart” komutu ile StrongSWAN’ın konfigürasyon ve erişim bilgileri dosyalarını okuyarak başarılı biçimde başladığından emin olmamız.
# ipsec statusall komutu ile sunucunun durumunu gözlemleyebiliriz.
Servisin çalıştığını da klasik “netstat –an” komutu ile gözlemleyebiliriz (UDP 500 ve UDP 4500 portlarına bakarak)
Son olarak bir hata var mı yok mu diye syslog dosyasına göz atabiliriz.
Pek açıklayıcı değil ama charon id’li satırlar ipsec ile ilgili. “charon” StrongSWAN için IKE servisinin adı. Öntanımlı olarak loglama için kullanılan facility’ler ve seviyeleri LOG_AUTHPRIV (sadece log seviyesi 0) ve LOG_DAEMON (tüm log seviyeleri). Daha detaylı loglara ihtiyacınız olursa https://wiki.strongswan.org/projects/strongswan/wiki/LoggerConfiguration kaynağından faydalanabilirsiniz. Loglar sizin için tam olarak bir anlam ifade etmese de bir terslik olduğunu anlayabilir, log ifadelerini kullanarak internette yardım arayabilirsiniz.
Bağlantıyı başlatmadan önce yapmamız gereken son düzenlemeler Amazon üzerindeki ağ erişim kısıtları. Bunlardan birincisi, ve unutulmaya meyilli olanı, Source / Destination kontrolünün iptal edilmesi. Amazon eğer kaynak veya hedef IP adresi ilgili instance olmayan bir paket görürse bunu öntanımlı olarak engelliyor. Bu yüzden bu kısıtı kaldırmamız lazım.
Yes, Disable düğmesine basarak bu kısıtı kaldırıyoruz.
Son olarak Security Group tanımını VPN trafiğini geçirecek biçimde ayarlamamız gerekiyor. Daha önce de çok farklı protokollerle IPSec VPN kurulabileceğini söylemiştik. Bizim kullandığımız IKEv2 yönteminde aşağıdaki protokol ve portlara erişim sağlanması lazım.
- UDP – 500 (IPSec kontrol kanalı, IKE protokolü tarafından kullanılır)
- UDP – 4500 (IPSec kontrol kanalı, NAT-Traversal desteği için kullanılır)
- ESP (IP protokolü no 50, veri iletim kanalı olarak kullanılır)
Save düğmesi ile SG ayarlarımızı kaydettikten sonra artık Windows 7 istemcimizde VPN erişimi için gerekli ayarları yapabiliriz.
Windows istemcimizde ilk yapmamız gereken şey, Ubuntu üzerinde oluşturmuş olduğumuz CA’in self-signed sertifikasının güvenilir (trusted) hale getirilmesi. Çünkü VPN sunucumuz bu CA’in imzaladığı sertifikayı kullanıyor ve eğer Windows CA’e güvenmezse sunucu doğrulama gerçekleşmeyecek.
Bunun için önce CA’in sertifikasını Windows bilgisayara aktaralım. Bu işlem için WinSCP’yi kullanabiliriz. /etc/ipsec.d/cacerts dizini altında daha önce “strongswanCert.der” olarak adlandırdığımız sertifikayı kendi bilgisayarımıza alalım.
Şimdi “mmc” uygulamasını başlatalım.
File menüsünden “Add/Remove Snap-in” seçeneğini seçelim.
“Certificates” seçeneği seçilerek Add düğmesine tıklanır.
Bir sonraki ekranda “Computer account” seçilmesi önemlidir. Bu seçim yapıldıktan sonra Next düğmesine tıklanır.
Bir sonraki ekranda “Local computer” seçili bırakılarak Finish düğmesi tıklanır.
OK düğmesine tıklanır ve konsola dönülür.
Certificates altındaki “Trusted Root Certification” ve Certificates üzerinde sağ kliklenir, All Tasks seçeneği altından Import linkine tıklanır.
Burada ilgili adımlar izlenerek CA sertifikamız import edilir.
Son olarak bir VPN bağlantısı tanımlamamız ve bağlantıyı gerçekleştirmemiz lazım.
Bunun için önce “Network and Sharing Center” dan “Set up a new connection or network” seçeneğini tıklayın.
Burada “Connect to a workplace” seçeneğini seçin ve Next düğmesine tıklayın.
Mevcut bağlantılarınız varsa çıkan şu ekranda “No, create a new connection” seçeneği seçili biçimde Next düğmesine tıklayın.
“Use my Internet connection (VPN)” seçeneğine tıklayın.
Çıkan ekranda VPN sunucunuzun public IP adresini girin ve Destination ismi olarak sizin için anlamlı bir isim verin (veya olduğu gibi bırakın). Daha sonra Next düğmesine tıklayın.
Son olarak kullanıcı adı ve parolanızı girin. Ben tembellik edip beni hatırla seçeneğini de seçtim, size seçmeniz gerektiğini söylemiyorum. Dilerseniz bir önceki ekranda “Don’t connect now; just set it up so I can connect later” kutusunu işaretledikten sonra bu işlemi sonlandırır ve daha sonra bağlanırken kullanıcı adı ve parolasını girebilirsiniz.
Bu aşamada sıkıntı yaşarsanız mutlaka şu sırada sorunu anlamaya çalışın:
- Network iletişimimde problem var mı?: Öncelikle istemci tarafında Wireshark veya farklı bir araçla IKE protokolünün çalıştığından (yani UDP 500 portuna yaptığınız isteklere yanıt aldığınızdan) emin olun. Paket filtresi olarak wireshark’ta “ip.addr==52.79.37.208” gibi bir filtre kullanabilirsiniz. Daha sonra sunucu üzerinde “tcpdump” ile izleme yapın, böylece sunucuya paketlerin ulaştığından emin olursunuz. SSH ile bağlanırken SSH trafiğini izlemekten kurtulmak için “tcpdump -i eth0 -s 1500 port not 22” komutu ile trafiği filtreleyebilirsiniz.
- Bir sonraki debug katmanı sunucunun ürettiği logların incelenmesi olmalı. Bu kaynağın öncelikle syslog dosyası olduğunu ve logların detayının yükseltilmesi ile ilgili kaynağı yukarıda paylaşmıştık.
Bu bağlantı ile VPN sunucumuza (örneğin SSH servisine) bağlantı sağlayabiliriz. Ancak henüz routing ihtiyacımızı karşılamadık. Bunun için aşağıdaki routing ayarlarını (kernel ayarı ve iptables ayarlarını) yapacağız ve bu ayarların sunucu reboot ettiğinde de yaşaması için gerekli düzenlemeyi gerçekleştireceğiz.
Routing ile ilgili yapmamız gereken birinci işlem kernel’ın routing desteğini aktif etmek.
# echo "net.ipv4.ip_forward = 1" | tee -a /etc/sysctl.conf
# sysctl -p
Sysctl kernel konfigürasyonu için kullanılan bir araç ve sysctl.conf dosyasına yazılan ayarlar sistem her reboot ettiğinde hayata geçecek. “sysctl –p” komutu sysctl.conf dosyasındaki ayarların hayata geçirilmesi için sadece bu seferlik kullanacağımız bir komut.
Daha sonra yapacağımız işlem VPN sunucumuz vasıtasıyla route edilen paketlerin yanıtlarının yeniden bize dönebilmesi için yapmamız gereken NAT ayarı olacak. Yani VPN sunucunun route ettiği tüm paketlerin gönderen IP adresi VPN sunucusunun IP adresi ile değiştirilecek ki geri gelen paketler yine VPN sunucusunun yolunu bulabilsin, VPN sunucusu da bize ait bu yanıtları bize gönderebilsin.
# iptables -t nat -A POSTROUTING -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Bu kurallardan birincisi route edilen tüm paketlerin çıkışına izin veriyor. İkincisi ise route edilen tüm paketlerin masquerade edilmesini, yani NAT uygulanarak kaynak IP adreslerinin eth0 arayüzüne ait IP adresi ile değiştirilmesini sağlıyor. Tabi burada arayüz ismimizin eth0 olduğunu varsayıyoruz. Öntanımlı bir kurulumda tek network arayüzü eth0 ile geliyor.
Şimdi VPN sunucumuzu kullanmaya ve Amazon’daki herhangi bir sunucumuza veya internete erişmeye hazırız.
Gördüğünüz gibi internet çıkış adresimiz Seul olarak görünüyor.
Son olarak yeni yazdığımız iptables kurallarının da reboot ettikten sonra da geçerli olmasını sağlayalım. Bunun için pek çok alternatif yol var, ama ben Ubuntu’nun desteklediği bir paket olan “iptables-persistent” paketini kullanacağım.
Önce bu paketi kuralım.
# apt-get install iptables-persistent
Aşağıda gördüğünüz gibi daha kurulum aşamasında mevcut kuralların bu paket tarafından kullanılan konfigürasyon dosyasına kaydedilmesini isteyip istemediğimiz soruluyor. Yes diyerek devam edeceğim. Eğer bu sorulmamış olsaydı aşağıdaki ekranda da belirtildiği gibi “iptables-save” komutu ile (tam olarak “iptables-save > /etc/iptables/rules.v4” komutu ile) mevcut kuralları kaydedebilirdim.
Aynı işlemi Ipv6 adresler için de yapmanızda herhangi bir sakınca yok.
Şimdi sistemi reboot ederek yaptığımız routing ve NAT ayarlarının etkili olup olmadıklarını kontrol edelim. Şimdiye kadar yaptığımız tüm ayarlar VPN sunucumuzun local IP adres değişikliğine dayanıklı biçimde yapıldı. Ancak sunucu sertifikamız malesef sunucunun public IP adresine özel üretildi. Amazon’un Elastic IP hizmetini kullansaydık bu da büyük bir problem olmayacaktı bizim için. Ancak mevcut durumda sertifikamızı alacağımız yeni public IP adresine göre tekrar oluşturmamız gerekecek.
Yeni public IP adresimiz farklı bir adres olarak atandı.
Şimdi tekrar PuTTY ile sunucuya erişerek “/etc/ipsec.d” dizini altında aşağıdaki komutla sunucu sertifikamızı “san – Subject Alternative Name” özelliklerinde bulunan IP adresi güncellenmiş olarak tekrar oluşturalım. Tabi Windows makinamızdaki VPN sunucu IP adresini de güncellememiz gerekecek (benim örneğimde yeni IP adresim 52.79.112.140).
# cd /etc/ipsec.d
# ipsec pki --pub --in private/BTRiskVPNHostKey.der --type rsa | ipsec pki --issue --lifetime 730 --cacert cacerts/strongswanCert.der --cakey private/strongswanKey.der --dn "C=TR, O=BTRisk, CN=vpn.btrisk.com" --san 52.79.112.140 --san @52.79.112.140 --flag serverAuth --flag ikeIntermediate --outform der > certs/BTRiskVPNHostCert.der
Bu işlemi yaptıktan sonra unutmamamız gereken bir nokta da “ipsec” servisini tekrar başlatmamız. Aksi takdirde yeni sertifikamız kullanılmaya başlanmaz.
Windows 7 üzerindeki VPN bağlantısındaki IP adresini de düzelttikten sonra tekrar bağlanmayı deneyebilir ve reboot ayarlarımızın çalışıp çalışmadığını test edebiliriz.
Açıkçası bazen bağlantı başarılı olmayabiliyor, bu durumda bağlantıyı tekrar başlatmayı deneyin. Eğer işler yolunda gitmezse syslog dosyasındaki logları izleyin.
Kali Linux ile VPN bağlantısı
Windows dışında VPN sunucumuzu bir de bir Linux istemci ile denemek istiyorum. Neden Kali derseniz, kendi lab ortamlarımız için de ihtiyaç duyacağımız bir ortam olduğu için bu dağıtımı seçtim. Bu arada şu anda kullandığım dağıtım Debian tabanlı, ama daha sonra bambaşka bir Linux versiyonu olabilir.
Linux client ile StrongSWAN VPN sunucusuna bağlanmak için internette araştırma yaptığınızda StrongSWAN’ın Network Manager plugin’i ile ilgili kaynaklara ulaşabilirsiniz. Yanlış istikamet ! Çünkü her linux dağıtımının farklı görünümde (belki de farklı türde) network manager uygulamaları var ve ulaşacağınız kaynaklar hepsi için geçerli değil. En azından Kali’de benim işime yaramadı. Daha sonra madem Linux dünyasındayız, StrongSWAN’ın kendisi de Linux tabanlı, şu ana kadar da komut satırında işimizi gördük, o zaman neden istemci kurulumu ve konfigürasyonunu da komut satırından yapmıyorum diye düşündüm. Zaten StrongSWAN’ın örnek konfigürasyonlarına bakarsanız (https://wiki.strongswan.org/projects/strongswan/wiki/ConfigurationExamples) buradaki istemci konfigürasyonlarının da Linux üzerinde gösterildiğini görürsünüz. Yani her iki tarafta da StrongSWAN çalışıyor.
Bu nedenle oluşturduğum bir sanal makineye Kali’nin güncel bir versiyonunu kurdum ve aşağıdaki süreci izledim.
Öncelikle StrongSWAN’ın kurulumunu yapalım. Ubuntu üzerine kurulum yaparken faydalandığım bir kaynakta belirtildiği gibi strongswan’ın yanı sıra pek çok plugini de kurdum, muhtemelen pek çoğuna ihtiyacım yoktu. Debian tabanlı Kali bilgisayarımda ise aşağıdaki paketlerin kurulumu gerekli ve yeterli oldu (libstrongswan-standard-plugins paketini kurmadığımda EAP-MSCHAPv2 protokolü çalışmadı).
# apt-get install strongswan libstrongswan-standard-plugins
Daha sonra ipsec.conf ve ipsec.secrets konfigürasyon dosyalarımızı aşağıdaki gibi düzenleyelim. Bu dosyalardaki konfigürasyon ayarları ile ilgili daha detaylı bilgiyi sunucu kurulumu bölümünde bulabilirsiniz. Burada istemci açısından önemli olabilecek konulara değineceğim sadece.
config setup
conn btrisk
keyexchange=ikev2
right=52.79.190.157
rightid=%52.79.190.157
rightsubnet=0.0.0.0/0
rightauth=pubkey
leftsourceip=%config
leftauth=eap-mschapv2
eap_identity=fatih
auto=add
Burada bir defa tanımlanan config setup bölümünde öntanımlı değerler birim için yeterli, o yüzden bir tanımlama yapmıyoruz.
“btrisk” adlı bağlantı bölümünde ikev2 protokolünü belirledikten sonra right (remote) tarafta bulunan sunucunun IP adresini tanımlıyoruz. Sunucuyu sertifika ile tanımladığımız için rightid parametresini sağlamamız lazım. Burada sunucunun IP adresini kullanıyoruz, daha önce sertifikayı oluştururken belirttiğimiz vpn.btrisk.com adı işe yaramıyor.
“rightsubnet” parametresi client tarafında kendi subnet’imiz dışındaki tüm trafiğin VPN sunucusuna yönlendirilmesi için StrongSWAN tarafından routing kurallarının oluşturulması için kullanılacak.
Sunucu tanılama için sertifika kullanacağımızı rightauth=pubkey parametresi ile belirtiyoruz.
İstemci için hatırlarsanız Virtual IP dağıtılması için sunucu tarafında tanımlama yapmıştık. İstemci tarafında “leftsourceip” parametresi için “%config” değeri ile sunucu tarafından atanacak olan IP adresini kullanacağımızı belirtiyoruz. İstemci tanılama için sunucu EAP-MSCHAPv2 protokolünü beklediğinden burada da uyumlu bir tanımlama yapmamız lazım.
Kullanacağımız ID olarak “eap_identity” parametresine “fatih” kullanıcı adını tanımlıyoruz.
“auto” parametresini anlamak bağlantı açısından önemli, “add” değeri “ipsec” servisi başladığında otomatik olarak bağlantının kurulmaması, bizim istediğimiz zaman bağlantıyı kurmamız için belirleniyor.
Bir sonraki konfigürasyon dosyası olan “ipsec.secrets” dosyasını istemcimizin kullanacağı erişim bilgilerini tanımlamak için kullanıyoruz.
Fatih : EAP “Btr1skpar0la”
Son olarak sunucu sertifikasını oluşturmak için kullandığımız CA sertifikasını ilgili dizine (/etc/ipsec.d/cacerts) kopyalamamız lazım, çünkü sunucu sertifikasının doğrulanması için buna ihtiyacımız var.
Artık bağlantımızı ayağa kaldırmaya hazırız. Bunu yapmadan önce yapmış olduğumuz tüm ayarların geçerli olabilmesi için “ipsec” servisini yeniden başlatalım.
# ipsec restart
Şimdi bağlantımızı ayağa kaldırabiliriz.
# ipsec up btrisk
Yukarıda da gördüğünüz gibi bir bağlantıyı “up” opsiyonuyla ayağa kaldırıyoruz.
Tekrar Seul üzerinden internete çıkıyoruz.
Böylece makalemizin sonuna geldik. Eğer VPN erişimlerini sadece Amazon’da bulunan subnet’lerinizle kısıtlamak istiyor ve internet çıkışını engellemek istiyorsanız, ilgili right ve left subnet tanımlarını uygun şekilde tanımlayabilirsiniz. Konfigürasyon konusunda mutlaka dokümantasyona göz atmanızı tavsiye ederim.
