VPN Nedir? Site-to-Site, Uzaktan Erişim ve IPsec

VPN (Virtual Private Network, sanal özel ağ), internet gibi herkesin paylaştığı bir ağ üzerinden iki nokta arasında şifreli bir tünel kurarak özel bir bağlantı sağlayan yöntemdir. Kurumsal ağlarda iki işi vardır: iki şubeyi birbirine bağlamak ve evdeki bir çalışanı şirketin iç ağına almak. Bu yazıda iki Linux makineyi iki şubenin güvenlik duvarı gibi kurdum, aralarında IPsec tüneli açtım ve aynı veriyi tünelden önce ve sonra ağda yakaladım.

Bir elçiliğin başkente gönderdiği diplomatik çantayı düşünün. Çanta herkesin kullandığı yollardan, havalimanlarından geçer, ama gümrük onu açamaz. Etiketinde yalnız gönderen ve alan elçilik yazar; içindeki mektupların kimden kime gittiği görünmez. Çanta açılana kadar içi gizlidir ve yalnız varacağı elçilikte açılır. VPN, ağın diplomatik çantasıdır.

Bu yazı ağ protokolleri rehberimizin bir parçasıdır ve Kurumsal Network Kurulumu hizmetimize aittir. Şubelerin birbirine hangi yolla bağlanacağına, VPN ile MPLS ve SD-WAN arasındaki seçime şube bağlantısı sayfamızda baktık; burada konu, VPN’in kendisinin nasıl çalıştığıdır.

VPN Nedir? Paylaşılan Yol Üzerinde Özel Bağlantı

VPN, paylaşılan bir ağın üzerinde yalnız iki ucun okuyabildiği şifreli bir bağlantıdır. İki şube arasında kendi kablonuzu çekemezsiniz; aradaki yol, internet sağlayıcılarının herkesle paylaştığı yoldur. VPN bu yolu değiştirmez, üzerinden geçen trafiği paketler. Gönderen taraf her paketi şifreler, başına kendi başlığını ekler ve karşı uca gönderir. Karşı uç başlığı çıkarır, şifreyi çözer ve paketi iç ağına verir. Yoldaki cihazlar yalnız iki uç arasında gidip gelen şifreli paketleri görür.

Kurumsal ağda iki tür VPN kurulur:

• Site-to-site VPN: iki ağı birbirine bağlar. İki şubenin güvenlik duvarı arasında sürekli açık bir tünel durur; şubedeki bilgisayarlar tünelden habersizdir ve karşı şubedeki sunucuya kendi ağındaymış gibi ulaşır.
• Uzaktan erişim VPN’i: tek bir kullanıcıyı ağa bağlar. Evdeki çalışanın bilgisayarındaki VPN istemcisi, bağlandığı an şirketin güvenlik duvarına kendi tünelini kurar.

Telefona kurulan bireysel VPN uygulamaları aynı tekniği başka bir iş için kullanır: trafiğinizi bir hizmet sağlayıcının sunucusuna taşır ve internete oradan çıkarır. Şirket VPN’inin amacı adres gizlemek değil, iç sistemlere paylaşılan yol üzerinden güvenle ulaşmaktır.

VPN tek başına bir protokol değildir; bir bağlantı biçimidir ve onu protokoller kurar. Tünel, içinden geçen protokolü de değiştirmez. Uzak masaüstü, dosya paylaşımı ya da DNS sorgusu tünelin içinde kendi protokolüyle konuşur; dışarıdan yalnız tünelin paketleri görünür. Lab’da da tünel açıkken ağda yalnız ESP paketleri göründü, içlerindeki TCP bağlantısı olduğu gibi taşındı.

Tüneli kuran protokoller de iki ailedir. IPsec ağ katmanında çalışır ve site-to-site bağlantıların standart protokolüdür; bu yazıda ölçtüğüm odur. SSL VPN ise TLS üzerinde çalışır ve daha çok uzaktan erişimde kullanılır.

VPN Nasıl Çalışır? IKE ile El Sıkışma, ESP ile Taşıma

IPsec tüneli iki aşamada kurulur. Önce iki uç birbirini tanır ve anahtar üzerinde anlaşır; bu işi IKE (Internet Key Exchange) yapar. Sonra asıl veri, ESP (Encapsulating Security Payload) paketleri içinde taşınır.

Lab’da iki Ubuntu makinesini iki şubenin güvenlik duvarı yerine koydum ve ikisine de açık kaynak IPsec yazılımı strongSwan’ı kurdum. Bir tarafın yapılandırması şu (paylaşılan anahtarı burada gizledim):

connections {
  sube {
    version = 2
    local_addrs = 192.168.1.46
    remote_addrs = 192.168.1.45
    proposals = aes256-sha256-modp2048
    local {
      auth = psk
      id = sistemkusu-syslog
    }
    remote {
      auth = psk
      id = sistemkusu-cacti
    }
    children {
      sube {
        local_ts = 192.168.1.46/32
        remote_ts = 192.168.1.45/32
        mode = tunnel
        esp_proposals = aes256gcm16
        start_action = none
      }
    }
  }
}
secrets {
  ike-sube {
    id-1 = sistemkusu-syslog
    id-2 = sistemkusu-cacti
    secret = "<paylaşılan anahtar>"
  }
}

İki öneri satırı iki aşamaya karşılık geliyor: proposals el sıkışmanın, esp_proposals verinin şifrelemesi. local_ts ve remote_ts ise tünelden hangi trafiğin geçeceğini söyler. Lab’da her iki taraf da tek bir adres, gerçek bir şube bağlantısında buraya iki şubenin ağları yazılır.

Tüneli bir taraftan başlattım:

$ sudo swanctl --initiate --child sube
[IKE] IKE_SA sube[1] established between 192.168.1.46[sistemkusu-syslog]...192.168.1.45[sistemkusu-cacti]
[IKE] scheduling rekeying in 13022s
[IKE] maximum IKE_SA lifetime 14462s
[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
[IKE] CHILD_SA sube{1} established with SPIs cca9b10d_i c55a6eff_o and TS 192.168.1.46/32 === 192.168.1.45/32
initiate completed successfully

Karşı makinede aynı anı dinlediğimde el sıkışma dört paketti:

18:40:47.927617 IP 192.168.1.46.500 > 192.168.1.45.500: isakmp: parent_sa ikev2_init[I]
18:40:47.931750 IP 192.168.1.45.500 > 192.168.1.46.500: isakmp: parent_sa ikev2_init[R]
18:40:47.937219 IP 192.168.1.46.4500 > 192.168.1.45.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
18:40:47.973259 IP 192.168.1.45.4500 > 192.168.1.46.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
18:40:47.984023 IP 192.168.1.45 > 192.168.1.46: ESP(spi=0xcca9b10d,seq=0x1), length 112

İlk iki paket IKEv2’nin tanımladığı ilk değişimdir. RFC 7296 onu şöyle anlatıyor: “The first pair of messages (IKE_SA_INIT) negotiate cryptographic algorithms, exchange nonces, and do a Diffie-Hellman exchange.” İkinci çift kimlik doğrulamadır: “The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first Child SA” (RFC 7296, bölüm 1.2). Beşinci satırdan itibaren veri artık ESP’dir.

El sıkışma port 500’de başladı ve ikinci çiftte port 4500’e geçti. RFC 7296, IKE’nin normalde port 500’ü kullandığını ama mesajların 4500’de de alınabileceğini, orada her mesajın dört sıfır baytla başladığını yazıyor; tcpdump’ın NONESP-encap dediği bu ön ek. Lab’da iki makine arasında adres dönüşümü yoktu. Yazılımın neden 4500’e geçtiğini ayrıca doğrulamadım. Portların ne olduğunu port nedir yazımızda anlattık.

Kurulan tünelin durumu:

$ sudo swanctl --list-sas
...
sube: #1, ESTABLISHED, IKEv2, 6d081a5cb4e688ac_i* f2ffa50be765b506_r
  local  'sistemkusu-syslog' @ 192.168.1.46[4500]
  remote 'sistemkusu-cacti' @ 192.168.1.45[4500]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  established 39s ago, rekeying in 12983s
  sube: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_GCM_16-256
    installed 39s ago, rekeying in 3456s, expires in 3921s
    in  cca9b10d,   6561 bytes,    16 packets,    29s ago
    out c55a6eff,   6911 bytes,    18 packets,    29s ago
    local  192.168.1.46/32
    remote 192.168.1.45/32

İki satır ayrıca okunmaya değer. rekeying in 3456s, verinin anahtarının yaklaşık bir saat içinde kendiliğinden yenileneceğini söylüyor; tünel aynı anahtarı sonsuza kadar kullanmaz. in ve out satırlarındaki cca9b10d ve c55a6eff ise iki yönün SPI değerleri. RFC 4303, SPI’ı “an arbitrary 32-bit value that is used by a receiver to identify the SA to which an incoming packet is bound” diye tanımlıyor (RFC 4303, bölüm 2.1): alıcı, gelen paketin hangi tünele ait olduğunu bu sayıdan anlar.

IPsec Tüneli Ağda Nasıl Görünür? Tünelden Önce ve Sonra

Tünelin ne değiştirdiğini görmek için aynı veriyi iki kez gönderdim; biri tünel yokken, öbürü tünel açıkken gitti. Veri olarak aranması kolay bir işaret metni seçtim: SERCE-GIZLI-VERI-2026.

Tünel yokken alıcı makinede yakalanan paket veriyi olduğu gibi taşıyordu:

18:39:19.579826 IP 192.168.1.46.41952 > 192.168.1.45.5555: Flags [P.], seq 1:23, ack 1, win 502, options [nop,nop,TS val 3332908804 ecr 2431164691], length 22
	0x0000:  4500 004a 20ad 4000 4006 9655 c0a8 012e  E..J..@.@..U....
	0x0010:  c0a8 012d a3e0 15b3 5427 224c 70ea 0ae8  ...-....T'"Lp...
	0x0020:  8018 01f6 1405 0000 0101 080a c6a8 2704  ..............'.
	0x0030:  90e8 a113 5345 5243 452d 4749 5a4c 492d  ....SERCE-GIZLI-
	0x0040:  5645 5249 2d32 3032 360a                 VERI-2026.

Sağdaki sütunda metin okunuyor; paketin hangi uygulamaya gittiği de (5555 numaralı port) başlıkta açık. Tünel açıkken aynı iki makine arasındaki paketlerden biri şöyleydi:

18:40:47.984023 IP 192.168.1.45 > 192.168.1.46: ESP(spi=0xcca9b10d,seq=0x1), length 112
	0x0000:  4500 0084 d440 4000 4032 e25b c0a8 012d  E....@@.@2.[...-
	0x0010:  c0a8 012e cca9 b10d 0000 0001 3ee0 b79f  ............>...
	0x0020:  ee35 355b 3716 22e4 47fd 7e60 9951 8711  .55[7.".G.~`.Q..
...

İlk satırdaki 4032’nin ikinci baytı, 32, IP başlığının protokol alanıdır: onaltılık 32, yani 50, ESP’nin numarası. Artık TCP ya da port yok. cca9 b10d SPI’dır, 0000 0001 sıra numarası; ondan sonrası anlamsız baytlar. RFC 4303 ESP paketinin alanlarını bu sırayla sayıyor: SPI, sıra numarası, şifreli veri, dolgu, dolgu uzunluğu, sonraki başlık ve bütünlük değeri.

Gönderen makinede aynı aktarımı dinlediğimde makineden çıkan paketlerin beşi de ESP’ydi, işaret metni hiçbir pakette yoktu. Diplomatik çanta yola çıkmıştı; gümrük yalnız çantayı ve etiketindeki iki adresi görüyordu.

Bu lab’da tünelin iki ucu, trafiğin kendi kaynağı ve hedefiydi; bu yüzden paketin dışındaki adresler de iç adreslerle aynıydı.

Gerçek bir site-to-site bağlantıda durum farklıdır. RFC 4303 tünel kipini şöyle tanımlıyor: “In tunnel mode, the ‘inner’ IP header carries the ultimate (IP) source and destination addresses, while an ‘outer’ IP header contains the addresses of the IPsec ‘peers’” (RFC 4303, bölüm 3.1.2). Yani iki şube arasındaki bir tünelde yoldaki cihazlar yalnız iki güvenlik duvarının adresini görür; hangi bilgisayarın hangi sunucuyla konuştuğu şifrenin içinde kalır.

VPN Tünelini Yanlış Yerden Dinlemek: Alıcıda Görünen Düz Metin

Ölçümün en öğretici kısmı beklemediğim bir sonuçtu. Tünel açıkken ilk yakalamayı veriyi alan makinede yapmıştım ve orada işaret metni yine düz görünüyordu. İlk bakışta tünel veriyi şifrelemiyor gibiydi.

Yakalamaya ayrıntılı bakınca desen çıktı:

18:40:50.407385 IP 192.168.1.46 > 192.168.1.45: ESP(spi=0xc55a6eff,seq=0x4), length 96
18:40:50.407385 IP 192.168.1.46.36498 > 192.168.1.45.5555: Flags [S], seq 1314041075, win 64240, options [mss 1460,sackOK,TS val 3332999631 ecr 0,nop,wscale 7], length 0
18:40:50.407475 IP 192.168.1.45 > 192.168.1.46: ESP(spi=0xcca9b10d,seq=0x5), length 96

Düz görünen her paket gelen yöndeydi ve bir önceki gelen ESP paketiyle aynı mikrosaniyede kayda düşmüştü: ilk satırdaki ESP paketi ile ikinci satırdaki bağlantı isteğinin zamanı aynı, 18:40:50.407385. Alıcının gönderdiği paketlerin ise hiçbir düz kopyası yoktu. Karşı sınama olarak aynı aktarımı gönderen makinede dinledim; orada da desen aynıydı: giden yönde yalnız ESP, gelen yönde her ESP’nin yanında aynı anda kaydedilmiş bir düz kopya.

Yani ağdan yalnız ESP geçti. Düz kopyayı gösteren, şifreyi çözen makinenin kendisiydi: çözülen paket de aynı ağ arayüzünde yakalama aracına görünüyordu. Diplomatik çanta elçiliğe varınca açılır; elçiliğin içinde mektubu okuyan biri, çantanın yolda açık gittiğini sanmamalıdır.

Bunun pratik dersi, tüneli sınayan biri içindir: şifrelemenin çalışıp çalışmadığı tünelin ucunda değil, iki uç arasındaki yolda ya da en azından gönderen tarafta dinlenerek sınanır. Alıcıda alınan bir yakalama “VPN şifrelemiyor” diye yanlış bir sonuca götürür. Ölçüm aracının kendisi de sınanması gereken bir şeydir; Linux TFTP sunucusu kurulumu yazısında da test aracı isteği sunucuya varmadan değiştirmişti.

VPN’in Bedeli: MTU ve 54 Bayt

Diplomatik çantanın da bir ağırlığı vardır: aynı mektubu çantayla göndermek, çantanın kendisini de taşımak demektir. VPN’de bu ağırlık, her pakete eklenen yeni başlıktır.

Tünel yokken iki makine arasında parçalanmasına izin verilmeyen (-M do) en büyük ping yükü 1472 bayttı:

$ ping -M do -s 1472 -c 1 -W 1 192.168.1.45
1480 bytes from 192.168.1.45: icmp_seq=1 ttl=64 time=1.29 ms
$ ping -M do -s 1473 -c 1 -W 1 192.168.1.45
ping: local error: message too long, mtu=1500

Tünel açıkken aynı 1472 baytlık paket gönderilemedi ve makine tünelin taşıyabileceği boyutu bildirdi:

$ ping -M do -s 1472 -c 1 -W 1 192.168.1.45
ping: local error: message too long, mtu=1446
$ ping -M do -s 1418 -c 1 -W 1 192.168.1.45
1426 bytes from 192.168.1.45: icmp_seq=1 ttl=64 time=0.715 ms
$ ping -M do -s 1419 -c 1 -W 1 192.168.1.45
ping: local error: message too long, mtu=1446

Tünel her paketten 54 bayt yedi: taşınabilen boyut 1500’den 1446’ya indi. Bu 54 bayt, dış IP başlığı, ESP başlığı ve şifrelemenin bütünlük değeri gibi RFC 4303’ün saydığı alanlardan oluşuyor; dökümü kullanılan şifreleme algoritmasına göre değişir. Paket boyutunun ve MTU’nun ne olduğunu ICMP makalemizde anlattık.

Pratik sonucu şu: tünelin öncesinde 1500 baytlık paketlerle konuşan bir bağlantı, tünelde bu paketleri sığdıramaz. Parçalanmasına izin verilmeyen bir paket tünele giremez; lab’da 1472 baytlık ping tam olarak böyle reddedildi.

Paket boyutunu yeni sınıra kullanıcı uydurmaz, protokoller uydurur. Bu işi üç mekanizma yapar:

1. Uçtaki işletim sistemi. Tünel makinenin kendisinde bitiyorsa yeni sınırı işletim sistemi bilir. RFC 4301 bu durum için “Signaling of the PMTU information is internal to the host” der (RFC 4301, bölüm 8.2.1). Lab tam bu durumdu: ping hatayı ağa paket göndermeden, local error olarak aldı.
2. Ağ geçidinin ICMP mesajı. Tünel bir ağ geçidinde bitiyorsa arkadaki bilgisayar tünelden habersizdir. Aynı bölüm geçidin büyük paketi atmasını ve gönderene bir ICMP mesajı döndürmesini ister: “The implementation SHOULD discard the packet and send a PMTU ICMP message.” Gönderen taraf bu mesajla paket boyunu kendisi küçültür; ICMP makalemizde anlattığımız PMTUD budur.
3. Ağ geçidinin MSS düşürmesi. TCP bağlantısı kurulurken iki uç, alabileceği en büyük veri parçasını (MSS) karşı tarafa bildirir. Geçit bu değeri tünele sığacak kadar düşürürse iki uç baştan küçük paketle konuşur. RFC 4459 bu yönteme “MSS clamping” der ve MSS taşımayan UDP trafiğinde işe yaramadığını da yazar (RFC 4459, bölüm 3.2).

Yöneticiye kalan iş, bu mekanizmaların önünü açmaktır. İkinci mekanizma ICMP’ye dayanır ve yoldaki bir güvenlik duvarı bu mesajı düşürürse çalışmaz. strongSwan’ın belgesi tünellerdeki MSS ve MTU sorunlarını tam buna bağlıyor: “This is caused by broken routers dropping ICMP packets and thus breaking PMTUD” (strongSwan, Forwarding and Split-Tunneling). ICMP makalesindeki görüntü burada da aynıdır. Tünel kurulur, küçük trafik akar, büyük aktarım takılır.

Hangi mekanizmanın çalıştığı üreticiye ve sürüme göre de değişiyor. Fortinet’in notuna göre FortiGate, FortiOS 7.6.1’den önce IPsec tünelinden geçen TCP trafiğinin MSS değerini kendiliğinden düşürüyordu; 7.6.1’den itibaren bunu yapmıyor ve ICMP mesajına güveniyor. Aynı not, tünel trafiğini donanımda işleyen (NPU) modellerde bu ICMP mesajının hiç üretilemediğini yazıyor. Önerdiği ilk çözüm, MSS değerini tünelin güvenlik duvarı kuralında elle vermektir (Fortinet, TCP MSS handling changes for IPsec tunnels).

VPN Neyi Korumaz?

Tünel trafiği yolda korur. Dört şeyi korumaz ve dördü de VPN kurarken ayrıca düşünülmelidir:

• Uçları korumaz. Lab’da gördüğümüz gibi veri iki uçta düz metindir. Evden bağlanan bir bilgisayar zararlı yazılım taşıyorsa, VPN o yazılımı da şirket ağına taşır. VPN kullanıcılarını ayrı bir segmente alıp yalnız ihtiyaç duydukları sistemlere erişmesine izin vermek bu yüzden gerekir; bunun nasıl planlandığını ağ segmentasyonu yazımızda anlattık.
• Trafiğin varlığını gizlemez. Gönderen makinede yakalanan ESP paketlerinin boyları (length 88, 96, 108, 136) ve zamanları açıkça okunuyordu. Gümrük çantanın içini göremez ama çantanın ne kadar büyük olduğunu ve ne sıklıkla gittiğini görür. Benzetmenin koptuğu yer burası: diplomatik çantayı uluslararası hukuk korur, VPN tünelini yalnız matematik ve anahtarlar korur.
• Zayıf bir anahtarı telafi etmez. Lab’da iki uç bir paylaşılan anahtarla birbirini tanıdı. Anahtar ele geçerse tünel de ele geçer. Kurumsal VPN’de uçları sertifikayla tanıtmak bu riski azaltır; sertifikanın nasıl dağıtıldığını sertifika otoritesi yazımızda anlattık.
• Kullanıcının kim olduğunu tek başına kanıtlamaz. Uzaktan erişim VPN’inde parola çalınırsa tünel saldırgana da açılır. Uzaktan erişimde ikinci doğrulama adımı bu yüzden zorunlu sayılmalı; yöntemlerin farkını iki faktörlü doğrulama yazımızda anlattık.

Uzak masaüstünü internete açmak yerine VPN’in arkasına almayı ise RDP makalemizde anlattık.

Sonuç: VPN Veriyi Yolda Korur, Uçlarda Korumaz

VPN, paylaşılan bir yol üzerinde iki nokta arasında şifreli bir tünel kurar: IKE ile iki uç anlaşır, ESP ile veri taşınır. Lab’da tünelden önce ağda okunabilen veri, tünel açıkken yalnız SPI’ı ve sıra numarası görünen ESP paketlerine dönüştü. Tünel her paketten 54 bayt aldı. Tünelin ucunda ise veri yine düz metindi ve bu, ucun kendisinde alınan bir yakalamayı yanıltıcı yaptı.

Diplomatik çanta yolda kapalıdır, elçilikte açılır. VPN kurmak çantayı kapatmaktır; kimin elçiliğe girebileceğine ve içeride nereye gidebileceğine karar vermek ayrı bir iştir. Aynı tüneli bir firewall’da iki ofis arasında kurmayı ve tünel koptuğunda trafiğin ne olduğunu FortiGate IPsec VPN yazımızda ölçtük.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn