Şirketinizin merkez lokasyonu ile uzak lokasyonlarını birbirleri arasında bağlamak için endüstri standardı bir bağlantı yöntemi olan IPSec VPN çözümünü kullanabilirsiniz. Günümüzde şirketler, sistemlerini kendilerine ait veri merkezlerinde barındırabildikleri gibi, bulut hizmeti sağlayan servis sağlayıcılardan da BT hizmetlerini kiralayıp, sistemlerinin tamamını veya bir kısmını buluta taşıyabilmektedir(Iaas, Saas, Paas gibi). Şirketler bulut hizmetlerinden faydalanırken, ülkeden ülkeye ve sektörden sektöre göre değişmekle birlikte farklı yükümlülükler veya kısıtlamalar ile karşılaşmaktadır.
Yazımda bu vizyonu biraz farklılaştıracağım. Yazıma konu olan hayali şirket, sistemlerinin bir kısmını AWS üzerinde bir kısmını Azure üzerinde barındırıyor J Bu senaryoda iki büyük bulut servis sağlayıcısı, hayali şirketimizin iki farklı lokasyonu olarak veya HQ/DR site’ları olarak düşünülebilir.
Bu tür testler için VPN cihazları (Juniper, Checkpoint, Cisco, Software VPN vb.) gerekiyor senaryoyu incelemek için AWS üzerinde bir sanal sunucuyu VPN Gateway olarak yapılandırdım. Yazılımsal veya donanımsal VPN sisteminize ayırdığınız kaynağa bağlı olarak performans değişebilir fakat bulut ortamında VPN yapılandırmasını incelemek için sizler de bu şekilde bir test ortamı hazırlayabilirsiniz.
Topolojimden bahsedeyim. Önceki yazımda genel olarak AWS’den ve AWS’de geçen kavramlardan bahsetmiştim. AWS terminolojisi hakkında önceki yazımı inceleyebilirsiniz.
Resim-1
AWS üzerinde VPN Gateway yapılandırdığımı belirtmiştim. VPN Gateway hizmetini bir sanal sunucu üzerinde çalıştırdım. VPN hizmeti için kullandığım sanal sunucu Ubuntu Server‘dır ve kullandığım VPN yazılımı Openswan yazılımıdır. Ubuntu Server’dan farklı olarak test için AWS üzerinde Windows Server 2012 r2 Instance’ını oluşturdum. Benzer şekilde Azure üzerinde de bir adet Windows Server 2012 r2 sanal sunucum mevcut.
AWS’de çalıştırdığım sistemin Network ve VPN altyapısını açıklayayım.
Resim-2
Üstte görüldüğü gibi 10.0.0.0/16 Subnet’ini kullanacak bir VPC oluşturdum.
Resim-3
VPC ‘de kullanmak için 10.0.0.0/24 ve 10.0.1.0/24 Instance Subnet’lerini oluşturdum.
Resim-4
VPC’den internet’e erişebilmek için bir Internet Gateway objesi oluşturdum.(igw-9b…)
Resim-5
VPC için kullanılacak olan Routing Table’ı oluşturdum(rtb-627..). Routing Table’da, internet’e erişebilmek için veya VPN tünelinin diğer tarafındaki Network’e erişebilmek için Route’lar belirlemeniz gerekiyor! Routing Table’da varsayılan olarak gelen Route, VPC içinde kalan Local Network’ü tanımlayan Route’dur.
Bunun dışında VPC’den internet’e erişebilmek için kullanacağınız Gateway’i(internet Gateway) belirlemeniz gerekiyor(üst kısımda belirlediğimi yazmıştım). İlaveten bu yazımdaki senaryom gereği,VPN tünelinden geçerek Azure tarafındaki Subnet’e(172.16.0.0./16) nasıl erişileceğini belirlemek gerekiyor.
Routing Table’daki yapılandırmam şu şekilde oldu. İlerleyen kısımlarda Routing Table’dan ekran alıntısı paylaşacağım.
10.0.0.0./16 > VPC içindeki Local Network’ümdür.
172.16.0.0/16 Subnetine erişirken Ubuntu Instance’ının Network Interface’ini kullanacağım
0.0.0.0/0 genel internete erişirken(üstteki iki Destination dışında kalan yerlere) internet Gateway’imi kullanıyorum.
Ubuntu Instance’ına aşağıdaki ip adresleri (Public ve Private) atanmış durumdadır.
Resim-6
Ubuntu Instance’ına uzaktan bağlanabilmek için ve diğer gereksinimler için, Instance seviyesinde kullanılan Security Groups yapılandırmasını aşağıdaki gibi yaptım. Hata denetimi için tüm Security Group’ları göz önünde bulundurunuz!
Resim-7
İlk kural SSH ile erişim içindir. İkinci kural opsiyonel, test için oluşturdum. Üçüncü ve dördüncü kurallar Azure Site’ından gelecek IPSec VPN bağlantısının AWS VPC’si içindeki Instance’ına (VPN yazılımına, Ubuntu) geçebilmesi için gerekiyor. Son kuralı test amaçlı açtım (Azure’daki sunucudan gelen ICMP paketinin AWS’deki Instance’a aktarılması yani ping ile test yapabilmek için). Outbound kurallarda varsayılan olarak her trafik izinlidir! Fakat ihtiyaçlarınız doğrultusunda değiştirebilirsiniz.
Openswan, Linux dağıtımları (Fedora, Red hat, Ubuntu, Debian, Gentoo vb.) üzerinde çalışan Virtual Private Network(VPN) yazılımıdır. Test senaryomda kullandığım Linux dağıtımı, Ubuntu’dur. Ubuntu Instance’I üzerine Openswan kurulumunu ve yapılandırmasını genel olarak açıklayayım. Kaynaklar kısmında belirttiğim web sitelerinden detaylara erişebilirsiniz.
Openswan yazılımını apt-get install openswan (yetkili kullanıcıya geçmek için sudo) komutu ile kurabilirsiniz.
Resim-8
Üstte gösterilen ipsec.conf dosyası içinde aşağıdaki satırları yapılandırmak yeterli olacaktır.
config setup
plutodebug=all
plutostderrlog=/var/log/pluto.log
protostack=netkey
nat_traversal=yes
Virtual_Private=%v4:10.0.0.0/16
oe=off
include /etc/ipsec.d/*.conf
Pluto.log dosyası hata denetimi için çok önemlidir!
Bu dosyayı yapılandırdıktan sonra Azure tarafı için bir yapılandırma dosyası oluşturuyoruz. Test ortamımda, yapılandırma dosyasına amznazure.conf ismini vermiştim.
Resim-9
IPSec ve VPN konseptini bilenler için üstteki ekran görüntüsünü ve alt kısımlarındaki yapılandırmaları yorumlamak oldukça kolaydır. Bu yapılandırmada hedeflenen kısaca şudur. AWS tarafındaki 10.0.0.0/16 Subneti ile Azure tarafındaki 172.16.0.0/16 Subneti VPN tünelinin uçlarındaki Subnet’lerdir.
AWS tarafındaki VPN Peer’inin ip adresi 10.0.0.101’dir (Ubuntu Instance’ının Network Interface’i). Azure tarafındaki VPN Peer’in IP adresi 104.40.149.222 ‘dir. IKE ve ESP için kullanılabilecek seçenekleri üstte görüldüğü gibi seçtim. IKE ve ESP için sadece gereken yöntemleri yazmanız yeterli olacaktır.
Düzenlememiz gereken bir başka dosya ise ipsec.secrets dosyasıdır.
Resim-10
Bu dosyada geçen 10.0.0.101 adresi AWS tarafındaki VPN Peer’idir. %any yerine Azure tarafında VPN Peer’inin IP adresini de yazabilirsiniz. PSK ‘yı Azure tarafındaki VPN Gateway objesinden tedarik ediyorsunuz.
Resim-11
Yapılandırılması gereken son ayar da aşağıdaki gibidir.
Resim-12
Bu işlemi de yaptıktan sonra sysctl –p /etc/sysctl.conf komutu ile(yetki için başına sudo yazarak) değiştirdiğimiz Network ayarının geçerli olmasını sağlıyoruz.
Ubuntu Instance’ımız için aşağıdaki değişikliği de yapıyoruz.
Resim-13
Ubuntu Instance’ına etkiyen Security Groups’dan ve Routing Table’dan, yazımın ilk kısımlarında bahsetmiştim. Bu aşamada şunu tekrar hatırlatmak istiyorum. AWS VPC’nize hizmet veren Routing Table’da, Azure tarafına erişim için VPN tünelinin kullanılacağını, yani Ubuntu Instance’ının Network Interface’inin kullanılacağını belirlemeniz gerekiyor! Ortamımdaki Routing Table aşağıdaki gibidir.
Resim-14
172.16.0.0/16 Network’üne erişim için, ilgili Instance’ın ilgili Network interface’inin kullanılacağı bilgisi, üstte görüldüğü gibi belirtilmiş durumdadır.
Bu arada yaptığınız işlemlerden sonra, IPSec servisini ara ara yeniden başlatmak için service ipsec restart komutunu kullanabilirsiniz. Yetkili kullanıcıya geçmek için “sudo”
Azure tarafındaki VPN Network’ünün yapılandırma adımlarını tek tek resmetmeyeceğim. Azure tarafındaki VPN konfigürasyonu için anadilimizde bir sürü kaynak hazırlanmıştır ve hazırlanmaya devam ediyordur. Yazımın sonunda kaynaklar kısmında birkaçını belirttim. Fakat konu hakkında sorularınız olursa benimle iletişime geçebilirsiniz.
Azure tarafındaki konfigürasyonumu bir kaç ekran görüntüsü şeklinde aktarıyorum.
Resim-15
Awsazrs2sVNET isimli obje, VPN Network objesidir. Bu obje üstteki tanım gereği S2SawsazrLocalNet isimli Network’e bağlanacaktır. S2SawsazrLocalNet isimli Network’ün detayını ilerleyen kısımlarda belirteceğim.
Resim-16
Clduyg address space’ini, uygulama sunucuları için, cldback address space’ini diğer Network’teki sunucular için düşündüm. Son Subnet’te Gateway(VPN) Subnet’im. Azure-AWS veya Azure-On-Premise VPN bağlantısı oluştururken, Routing problemleri yaşama adına, bu kısımlardaki address space’lere ve Subnet seçimlerine dikkat etmek gerekiyor!
Resim-17
Üstte görüldüğü üzere, S2SawsazrLocalNet Network objesi ile Azure’un AWS tarafına VPN tüneli oluştururken kullanacağı VPN Gateway ip adresini ve AWS tarafında erişeceği Internal Network’e ait bilgileri yapılandırdım. Hatırlarsanız, benzer ayarları Ubuntu Instance’ı için azmnazure.conf dosyasında da yapmıştık.
Resim-18
Yapılandırmaları tamamladıktan sonra Azure tarafındaki VPN bağlantısı durumunu üstteki gibi gözleyebilirsiniz. Azure tarafındaki VPN bağlantısında hata denetimi yapmak pek konforlu değil fakat kaynaklar kısmında belirttiğim bir adresi ziyaret ederek hata denetimi Script’ini temin edebilirsiniz. Script’i bir süre çalıştırıp log toplayabiliyorsunuz. AWS tarafındaki VPN Gateway’imi kapatarak örnek log topladım. Örnek aşağıdaki gibidir. Sanırım bir kaç defa MS Support’a case açtıktan sonra Error Code’larını Azure perspektifinden yorumlamaya alışabilirsiniz.
Resim-19
Ubuntu Instance’ındaki VPN bağlantısında (openswan VPN yazılımında), hata denetimini aşağıdaki şekillerde yapabilirsiniz.
Resim-20
Resim-21
Resim-22
Daha detaylı IPSec log’larını /var/log/pluto.log dosyasından temin edebilirsiniz. Bu arada openswan yazılımını test amaçlı kullandık gibi görünüyor fakat üretim ortamınızda da uygun kaynaklar sağlayarak kullanabilirsiniz!
Şimdi AWS tarafındaki test Instance’ından(Windows Server 2012 r2), Azure tarafındaki test sanal sunucusuna erişmeyi deneyelim.
Resim-23
Üstte görüldüğü üzere Azure tarafındaki sunucuma ICMP ile eriştim.
Resim-24
Benzer şekilde Azure’dan AWS tarafındaki Instance’ıma ICMP ile eriştim. Test amaçlı başka bir işlem yapalım. Söz konusu Site to Site VPN olduğunda, genelde test edilen konulardan biri de Active Directory Domain Controller ve Active Directory Additional Domain Controller arası iletişim olacaktır. AWS Cloud’daki Windows Server’ımı DC rolüne, Azure tarafındaki sunucumu da Additional DC rolüne yükselteceğim.
Azure tarafındaki sanal sunucunun AWS ‘deki Domain’e katılması ve devamı için AWS tarafındaki Domain Controller Instance’ının Firewall’unda (Security Groups) Active Directory için gereken portları açmanız gerekiyor! Bu durum Segmented Network’lerde alışık olduğumuz durumlardan biridir. Erişim problemlerini araştırırken AWS tarafındaki tüm Security Group’ları göz önüne alınız!
Resim-25
Üstte görüldüğü üzere AWS’de ve Azure’da birer Domain Controller çalışmaya başladı. Site to Site VPN Network’ü kurulduktan ve VPN bağlantısı sağlandıktan sonra, AWS’deki Instance’larınız ile Azure’daki sanal sunucularınız, tanımladığınız Firewall Rule’larına bağlı olarak birbirleri ile iletişime geçmektedirler.
Bir sonraki yazımda bu çalışmayı bir adım daha ilerletmeyi düşünüyorum.
Herkese sorunsuz ve neşeli günler dilerim.
Referanslar
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
https://help.ubuntu.com/community/IpTablesHowTo
http://manpages.ubuntu.com/manpages/trusty/man8/Route.8.html
https://gallery.technet.microsoft.com/scriptcenter/Azure-Virtual-Network-2b4d0793
http://azure.microsoft.com/blog/2014/12/02/azure-Virtual-Network-Gateway-improvements/
http://askubuntu.com/questions/90314/unable-to-edit-proc-sys-net-ipv4-ip-forward-in-xubuntu
http://www.murat.ws/ipsecl2tp-VPN-debianubuntu/
http://xmodulo.com/create-Site to Site-ipsec-VPN-tunnel-openswan-linux.html
https://bugzilla.redhat.com/show_bug.cgi?id=537106
http://www.cyberciti.biz/faq/ubuntu-start-stop-ipTables-service/
http://blog.jameskyle.org/2012/07/configuring-openswan-ipsec-Server/
http://xmodulo.com/create-Site to Site-ipsec-VPN-tunnel-openswan-linux.html
http://stackoverflow.com/questions/10813000/openswan-tunnel-not-working-after-Network-restart
http://michaelwasham.com/2013/09/03/connecting-clouds-Site to Site-aws-azure/
http://aws.amazon.com/vpc/pricing/
https://github.com/xelerance/Openswan/blob/master/programs/examples/sysctl.conf.in
