Bölüm 48: Tünelleme ve IPsec

Bir önceki durakta yolun üstündeki kutuları saydık. Hepsi paketimizi görüyordu.

Paketi saklamanın bir yolu yok. Ama onu bir başka paketin içine koymak mümkün. Dıştaki zarfı okuyan kutu, içeridekini hiç göremez. Peki bu nasıl yapılıyor?

Bir paket nasıl başka bir paketin yükü olur?

Tünellemenin tanımı kısa: bir IP paketi, başka bir IP paketinin yükü hâline geliyor. Dıştaki paket için içteki sıradan bir bayt dizisidir.

Can alıcı ayrıntıyı adreslerde bulacaksın. Dış başlığın kaynağı ile hedefi tünelin iki ucunu gösteriyor; iç başlıktakiler ise asıl göndereni ve asıl alıcıyı. Aynı paketin üstünde aynı anda iki ayrı adres çifti bulunur. Yol üstündeki ara kutuların hepsi bu yüzden dış başlığa bakar ve içerideki adresi hiç göremez.

Bunu mümkün kılan alanı IP başlığında bulabilirsin. Protokol alanı, içerideki yükün ne olduğunu tek baytla ilan ediyor.

Listedeki 47 numara bir ayrımı da netleştiriyor: GRE’nin tek işi encapsulation yapmak ve hiçbir şeyi şifrelemiyor. Tünellemekle şifrelemeyi aynı şey sanma.

Tünelin taşıdığı şeyin her zaman bir IP paketi olduğunu da varsayma. İki uzak veri merkezi arasında Ethernet frame’lerini IP datagramlarının içinde taşıyabiliyorsun; VXLAN’ın segment kimliği 24 bit, dış zarfı UDP ve tahsisli hedef portu 4789. 24 bit, 16 milyonu aşkın ayrı sanal ağ demek; 29. bölümdeki VLAN kimliği ise 12 bitte kalıp 4.094’te tıkanıyordu. Bulut veri merkezlerinin VXLAN’a geçmesinin sebebi bu sayı.

Tünellemenin doğuş sebebi gayet pratik. 38. bölümde gördüğümüz gibi internette bütün router’ların aynı gün yükseltildiği bir bayrak günü yaşanmıyor. Yeni protokolü konuşan ağ parçaları birbirinden kopuk kaldı ve aralarındaki bütün hatlar eski protokolü konuşuyordu. Tünel bu boşluktan doğdu.

Tünelin iki görünümü var ve hangisine baktığın çok şeyi değiştiriyor. Mantıksal görünümde iki uç tek bir sanal bağla bağlıymış gibi duruyor; fiziksel görünümde arada bir sürü router sıralanıyor. 20. bölümde encapsulation her katmanın mecburen yaptığı bir işti; tünel aynı işi bir kat yukarıda ve kasten tekrarlar. Kargo tezgâhı bu kez kutuyu ikinci bir kutuya koyar ve üstüne yeni bir barkod basar. Ayırma merkezi yalnızca yeni barkodu okur.

Dıştaki zarfın içtekini nasıl sardığını adım adım açalım:

IPsec zarfı nereden sarmaya başlıyor?

IPsec’in koruması datagram düzeyinde çalışıyor: şifreleme, kimlik doğrulama ve bütünlük doğrudan IP paketine uygulanıyor. Uygulamanın bundan haberi olmasına gerek kalmıyor, çünkü koruma bir katman altta yapılıyor. Kapsam da geniştir: BGP ve DNS gibi kontrol trafiği de aynı zarfın içine girer. Uygulamalar tek tek seçmek zorunda değil; hangi trafiğin korunacağına birazdan göreceğimiz politika karar veriyor.

IPsec’in iki kipini ayırt etmen gerekiyor. Taşıma kipinde yalnızca yük şifrelenip doğrulanıyor ve orijinal IP başlığı açıkta kalıyor. Tünel kipinde ise başlığı dahil datagramın tamamı şifreleniyor. Aradaki fark, dışarıdan bakan birinin kiminle konuştuğunu görüp göremeyeceğidir: tünel kipinde yalnızca tünelin iki ucu görünür.

IPsec’i tek bir protokol olarak da düşünme. Kimlik Doğrulama Başlığı (AH, RFC 4302, protokol numarası 51) kaynak doğrulaması ile bütünlük veriyor ama gizlilik vermiyor. Şifrelenmiş Yük (ESP, RFC 4303, numarası 50) üçünü birden verir ve çok daha yaygın kullanılır. AH’nin sahadan çekilmesinin bir sebebi de adres çevirisiyle geçinememesi: IP başlığındaki adresi de doğruladığı için yolda adresi değiştiren her çevirici doğrulamayı bozuyor.

ESP’nin de çeviriyle bir derdi var: portu yok, oysa 46. bölümdeki port çevirisi flow’ları portla ayırıyordu. İki uç arada bir çevirici olduğunu fark ederse ESP’yi bir UDP datagramının içine koyup 4500 numaralı portu kullanıyor (NAT-T). Tünelin içinde bir tünel daha.

ESP tünel kipinde sıra hiç değişmiyor. Orijinal datagramın tamamına, başlık alanları dahil, bir kuyruk ekleniyor. Sonuç, ilişkideki algoritma ve anahtarla şifreleniyor. Öne ESP başlığı konuyor ve bir mesaj doğrulama kodu üretilip ekleniyor. Son adımda en öne, adresleri tünelin uçlarına yazılmış yeni bir IP başlığı eklenir. Bugün en yaygın seçim AES-GCM; o, 9. bölümde gördüğümüz gibi şifreleme ile doğrulama kodunu tek adımda üretiyor.

ESP başlığı iki adet 4 baytlık alanla başlar. İndeks ile sıra numarasını taşıyan bu sabit kısım 8 bayt eder. Kuyrukta ise dolgu, dolgu uzunluğu ve sonraki başlık alanları durur. Dolgu 0 ile 255 bayt arasında değişiyor. Blok şifreler bloğu tamamlamak için dolgu istediği için tünelin ek yükünü sabit bir sayı olarak hesaplayamıyorsun.

Sıra numarası tekrar oynatma saldırılarını engelliyor. Her yeni güvenlik ilişkisinde sıfırdan başlıyor ve gönderilen her datagramda bir artıyor. Alan taraf bütün paketleri hatırlamıyor; bir pencere tutuyor ve tekrarı o pencerenin içinde arıyor; pencerenin önerilen boyu 64 paket. Paketin sonundaki doğrulama alanında ise paylaşılan gizli anahtarla üretilmiş bir mesaj doğrulama kodu buluyorsun. Anahtarı bilmeyen biri tek bir biti değiştirse kod tutmuyor ve paket düşüyor; gönderene bir uyarı da gitmiyor.

Kim, hangi anahtarla, hangi yöne?

Burada şaşırtıcı bir ayrıntı var: IP bağlantısız çalışıyor ama IPsec bağlantı yönelimli çalışıyor. Veri gönderilmeden önce iki uç arasında bir güvenlik ilişkisi kuruluyor ve ikisi de durumu bellekte tutuyor.

İlişkinin kimliğini 32 bitlik bir sayı taşıyor ve adına güvenlik parametre indeksi deniyor. Değerini alıcı seçiyor, çünkü tabloyu o tutuyor. Gönderen bu sayıyı pakete yazıyor, alan uç da tablosuna bakıp hangi anahtarla çözeceğini buluyor. İlişki tek yönlüdür; çift yönlü bir tünel için gidişe bir, dönüşe bir tane gerekir. Anahtarları da ayrıdır. Sayının ne kadar hızlı büyüdüğünü görmek için sayalım: dört uçlu tam bir örgüde 6 tünel ve 12 ayrı güvenlik ilişkisi kurman gerekiyor.

IPsec iki ayrı veritabanı tutuyor ve ikisinin işi başka. Güvenlik politikası veritabanı ne yapılacağını söylüyor: bu datagram korunacak mı, düz mü geçecek, atılacak mı. Güvenlik ilişkileri veritabanı nasıl yapılacağını söyler: hangi anahtar, hangi algoritma, hangi sıra numarası. Karar, paketin kaynak adresine, hedef adresine ve protokol numarasına bakılarak verilir. Bölünmüş tünel, yani trafiğin yalnızca bir kısmını tünele sokma kararı, işte bu satırda veriliyor.

Anahtarları elle girmek küçük bir kurulumda işini görüyor ama yüzlerce uçlu kurumsal bir ağda altından kalkamıyorsun. Bu yüzden anahtar kurulumunu IKE (Internet Key Exchange) adlı protokole devrediyorlar. İki taraf kimliğini ya önceden paylaşılmış bir sırla ya da sertifikayla kanıtlar. 10. bölümde ortak sırra Diffie-Hellman anahtar uzlaşmasıyla varılıyordu; tünel o mekanizmayı olduğu gibi devralır.

Anahtar değişiminin kendisi de iki aşamaya bölünmüştür. Önce çift yönlü bir yönetim ilişkisi kurulur. Asıl veri ilişkileri ikinci aşamada, o ilişkinin korumasında pazarlık edilir. Bugünkü sürüm IKEv2 ikisini dört mesajda, iki gidiş-dönüşte bitiriyor; ilk sürümde bu sayı dokuz mesaja kadar çıkıyordu.

Tünelin iki ucunu üç ayrı biçimde eşleştirebilirsin: iki uç makine, iki router ya da bir router ile bir uç makine. Sanal özel ağ (VPN) kurulumunun iki klasik türü, uzaktan erişim ile siteden siteye, bu seçeneklerin ikisine karşılık gelir. Eşleşme tesadüf değil; mimarinin kuralı şu: güvenlik geçidi tünel kipini desteklemek zorundadır, taşıma kipi ise isteğe bağlıdır.

Kurumun gerekçesi ayrıca ekonomiktir: özel hat çekmek yerine interneti omurga olarak kullanır. Bağlanan cihaz uzaktaki ağa fiziksel olarak bağlıymış gibi çalışır. Tünelin güvenliği yolun güvenliğine dayanmaz; ele geçirilen paketler anahtar olmadan çözülemez.

WireGuard aynı işi kaç parçayla yapıyor?

WireGuard’ın kendi tanımı tek satır: IP paketlerini UDP üzerinden güvenli biçimde encapsulate eder. El sıkışma Noise çerçevesinin (Noise Protocol Framework) IK kalıbını kullanır. UDP seçimi bilinçli. Tünel TCP’nin üstüne kurulsaydı, içerideki TCP ile dıştaki TCP aynı kaybı ayrı ayrı onarmaya çalışır, zamanlayıcıları birbirini kışkırtır ve bağlantı kilitlenirdi; bu olaya TCP meltdown deniyor. UDP ise kaybı gizlemez, onarmayı içerideki protokole bırakır. WireGuard Linux kernel’ına 2020’de girdi; kodunun birkaç bin satır olması, yüz binlerce satırlık IPsec uygulamalarının yanında başlı başına bir güvenlik özelliği sayıldı.

Şifre takımı pazarlığı yoktur; IPsec’te pazarlıkla seçilen ne varsa burada sabitlenmiştir. Simetrik şifreleme ChaCha20, doğrulama Poly1305, anahtar uzlaşması Curve25519, özet BLAKE2s. Seçenek listesi olmadığı için yanlış seçenek de yoktur. Bedeli de var: bir algoritma kırılırsa pazarlıkla başkasına geçilemiyor, protokolün yeni bir sürümü gerekiyor. Kuantum sonrası döneme karşı ise el sıkışmaya isteğe bağlı bir önceden paylaşılan anahtar katılabiliyor; kayıt ileride kırılsa bile o anahtarı bilmeyen oturumu açamıyor.

Merkezdeki fikre kripto anahtarlı routing deniyor. Açık anahtarlarla izinli adres listelerinin basit bir eşleşmesidir. Aynı liste iki iş görür: gönderirken routing tablosu gibi, alırken erişim denetim listesi gibi davranır.

Bölünmüş tünelin somut karşılığı bu listedir. Listeye 0.0.0.0/0 yazılırsa bütün trafik tünele girer. Dar bir önek yazılırsa yalnızca o hedefler girer ve geri kalan her şey yerel çıkışı kullanır.

El sıkışma iki dakikada bir tekrarlanır. Anahtarlar döner ve amaç 11. bölümdeki forward secrecy’dir. Zamanlama pakete değil saate bağlıdır, çünkü tasarımın paket kaybına dayanıklı olması gerekir. Tekrar oynatma koruması 64 bitlik, geri sarılamayan bir sayaçla ve yaklaşık 2.000 değerlik kayan bir pencereyle yapılır.

Kılavuz sayfası, adres çevirisinin arkasındaki bir interface için 25 saniyelik kalıcı canlı tutma aralığı önerir. Sebep açık: 46. bölümde gördüğümüz gibi çevirici boşta kalan UDP eşlemesini siliyor ve sahadaki kutuların çoğu bunu standardın önerdiğinden çok daha erken yapıyor. Eşleme unutulursa dönüş trafiği düşer.

Her pakette kaç bayt ödüyorsun?

Her bağ, taşıyabileceği en büyük yük boyuyla sınırlıdır; Ethernet’te bu sınır 1.500 bayttır. Tünel bu sınırı değiştirmez. Aynı sınırın içine daha fazla başlık sokar.

Tünel interface’i de bir interface’tir ve kendi MTU değerini taşır. Bu değer altındaki bağdan hep daha dardır. Router, çıkış interface’inin MTU’sundan büyük bir paket alırsa onu daha küçük parçalara böler; tünel girişi de bir çıkış interface’idir.

Hesap kolay. Dış zarf seçeneksiz bir IPv4 başlığıysa 20 bayt gider; 1.500 baytlık yükte bu %1,3 eder. ESP tünel kipinin ek yükü seçilen algoritmaya göre değişiyor. AES-GCM ile en az 54 bayt: 20 baytlık dış başlık, 8 baytlık ESP başlığı, 8 baytlık başlangıç vektörü, 2 baytlık kuyruk ve 16 baytlık doğrulama kodu. İç pakete 1.446 bayt kalır, pay %3,6. WireGuard’ın IPv4 dış zarflı ek yükü 60 bayt: 20 baytlık IP, 8 baytlık UDP ve 32 baytlık kendi başlığı ile doğrulama kodu. İç pakete 1.440 bayt kalır, yani %4. Dış zarf IPv6 ise sabit başlık 40 bayt olduğu için ek yük 80 bayta çıkar ve iç pakete 1.420 bayt kalır. WireGuard’ın varsayılan MTU’sunun 1.420 olmasının sebebi bu en kötü durum.

Aynı hesap, 20. bölümde çıkardığımız 1.460 baytlık MSS değerini de aşağı çeker. IPv6 geçiş tünelleri standardı, yani RFC 4213, tünel interface’inin MTU’sunu tek satırla hesaplar: dış yolun MTU’su eksi kapsülleyen IPv4 başlığının boyu. Aynı standart sabit tünel MTU’sunu 1.280 ile 1.480 bayt arasına hapseder ve varsayılanın 1.280 olmasını önerir.

38. bölümde IPv6’nın her bağdan en az 1.280 baytlık MTU istediğini ve ayarlanabilir bağlar için 1.500 baytı, açıkça tünellere yer kalsın diye önerdiğini görmüştük. Tünel hesabı o önerinin neden yazıldığını gösteriyor.

Doğru boyu gönderenin kendisi ölçer: datagramlarını parçalama yasağı biti kurulu yollar, sığmayan paketi bir router atıp geriye parçalanamaz kodlu bir ICMP mesajı gönderdiğinde tahminini küçültür ve yeniden dener. Bu ölçmenin adı yol MTU keşfi, künyesi RFC 1191 ve tünelin varlığında zorunlu hâle geliyor. ICMP’ye güvenmeyen daha yeni bir yöntem de var: boyu, büyük paketlerin kaybolup kaybolmadığına bakarak kendisi buluyor (RFC 8899). QUIC bu yöntemi kullanıyor.

Parçalanan bir datagram yalnızca hedef uçta birleştirilir. Tünelde bu kural iki kez işler. Dış paket tünelin çıkışında, iç paket ise asıl hedefte birleştirilir. Kendi makinende ikisini de yoklayabilirsin.

ip link show wg0                      # tünel interface'inin MTU'su
ping -M do -s 1412 203.0.113.9        # 1.412 bayt yük + 28 bayt başlık = 1.440, DF kurulu

Windows’ta aynı denemenin karşılığı ping -f -l 1412 203.0.113.9.

Özet

• Tünel bir adres oyunudur: dış başlık tünelin iki ucunu, iç başlık asıl gönderen ile asıl alıcıyı taşır ve yol üstündekiler yalnızca dıştakini okur.
• Encapsulation ile şifreleme ayrı işlerdir: 47 numaralı protokol hiçbir şey şifrelemeden taşır, ESP ise gizlilik, bütünlük ve köken doğrulamasını birlikte verir.
• IPsec bağlantısız bir katmana durum ekler: tek yönlü güvenlik ilişkileri, 32 bitlik indeksleri ve iki ayrı veritabanıyla tünel bir oturuma dönüşür.
• WireGuard seçenekleri kaldırarak sadeleşir: tek şifre takımı, UDP taşıma ve izinli adres listesi hem routing hem erişim denetimi işini görür.
• Tünelin faturası her pakette kesilir: 1.500 baytlık yükte ek yük %1,3 ile %5,3 arasında değişir ve iç paketin sınırı hep daha dardır.

Tünelin ucundan çıktın ve paket artık kendi adresleriyle yoluna devam ediyor. Hedef ağın sınırında ise onu hiç tanımayan bir kural kümesi bekliyor. Oradan geçmek hakkın mı, yoksa izin mi?