Tünelleme Protokolü Olarak GRE – Generic Routing Encapsulation


Merhabalar,

Bu yazıda network mimarilerinde tünelleme nedir? Hangi amaçlarla kullanılır onlardan bahsedeceğim.

Ben üniversitede okurken İTÜ YDY binası ile Taşkışla binası arasında bir tünel olduğundan bahsederlerdi. Girip göremedik ama meclislerde bunun bahsini yaptık :D.

Nasıl bu eski iki kışla arasında haberleşme, erzak ve mühimmat taşıma gibi işler için bir tünel var ise network topolojilerinde de aradaki tüm yapılardan kendini saklayacak, içerisinde istediğimiz protokolü çalıştırıp istediğimiz veriyi güvenli bir şekilde akıtabileceğimiz yapı tüneller.

Araya ister ISP girsin ister onlarca cihaz olsun tünelleme protokolleri sayesinde biz iki uzak lokasyonumuzu haberleştirebiliriz. Bu haberleştirme L2 haberleştirmeye kadar varabilir. Yani bi lokasyonda kullandığımız bir vlan’I başka bir lokasyonda aynı broadcast domain’e dahil olacak şekilde yapılandırabiliriz. Hatta STP paketlerini bile geçirip STP domainimizi uzatabiliriz. Bir başka açıdan bakarsak bazı tünelleme fonksiyonları sayesinde atak yiyebilir veya atak yapabiliriz. Örneğin DNS hizemtini kullanarak içerisine gömülen SSH verisi ile isteğimizi izinli UDP53 portundan dışarı çıkartıp, izinli olmayan TCP22 istediğimiz yere ulaştırabiliriz.

Tünel bize;

  • Yapılandırmada esneklik,
  • Güvenlik,
  • Topolojide basitlik ve kolaylık sağlar ve maliyeti azaltıcı faydalar sunar.

Tünelleme bir veya birden fazla protokolün birleşmesiyle yapılabilir. GRE, MPLS, IPSec , L2TP birkaç tünelleme protokolüne örnek. Bu yazıda Cisco standartı GRE protokolü üzerinden tünelleme mantığını açıklamaya devam edip konfigürasyonu gösteceğim.

Tünelleme yaparken ilk kuralımız mutlaka 2 uç arasıda L3 connectivity’nin sağlanması. Eğer bu sağlanır ise bu iki uç arasından istediğimiz veriyi akıtabiliriz.

GRE: Generic Routing Encapsulation.

Cisco standartı bir tünelleme protokolüdür. Burada iki uç arasında açılan tünel interfaceleri yardımıyla internet veya güvensiz sayılan ağ üzerinden iletişim sağlanır.

Tünellerin kendi ip adresleri olmak zorundadır. İki uç birbirine erişebilir olduğunda tünel interface ayağa kalkar ve GRE iletişimi başlayabilir. Tünele verilen ip adresi artık iletim yapılabilen bir network olur bu sebeple kendi networkümüz içerisinde kullanılmayan bir ip aralığı tahsis etmeliyiz.

Temel konfigürasyonda static GRE tünelde her farklı uç için farklı tünel interfaceleri gerekmektedir.

Tünel kaynak ve hedef ip adresleri belirtilip konfigürasyon yapılır. Bu çok esnek olmamakla birlikte tünel modu değiştirilip birkaç ek konfigürasyon ile çok uçlu bir yapı kurulabilir.

Şimdi yukarıdaki topoloji için temel konfigürasyon yapıp paket içeriklerine bakalım.

R1:
interface fa0/0
ip address 1921.68.1.1 255.255.255.252
no shutdown
ip route 0.0.0.0 0.0.0.0 192.168.1.2
ISP:
interface fa0/0
ip address 192.168.1.2 255.255.255.252
no shutdown
interface fa2/0
ip address 172.16.1.1 255.255.255.252
no shutdown
R2:
interface fa2/0
ip address 172.16.1.2 255.255.255.252
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.1

Bu konfigürasyon ile temel L3 iletişimimizi yapmış olduk. R1 ile R2 arasındaki network sayısınıi kullanılan routing protokollerini arttırabiliriz. Fakat basitlik her zaman iyidir. Yine hatırlatayım burada temel nokta bu iki cihaz arasında L3 erişiminin olması uzaklık ve karmaşıklık önemli değil.

Şimdi tünel konfigürasyonunu da yapalım. Tünel interfacesi sanal bir interface olduğu için direk up durumda gelir. Burada  karşılaşılabilecek hata status up olmasına ragmen protokol down olmasıdır.  Bu oluyor ise L3 iletişiminizde bir sorun vardır. Tünel kaynak ip adresinden tünel hedef ip adresine erişim yoktur.

interface Tunnel 0
ip address 10.0.0.1 255.255.255.0
tunnel source 192.168.1.1
tunnel destination 172.16.1.2
R2:
interface tunnel 0
ip address 10.0.0.2 255.255.255.0
tunnel source 172.16.1.2
tunnel destination 192.168.1.1

R1#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
FastEthernet0/0        192.168.1.1     YES manual up                    up
FastEthernet1/0        unassigned      YES unset  administratively down down
FastEthernet1/1        unassigned      YES unset  administratively down down
FastEthernet2/0        unassigned      YES unset  administratively down down
FastEthernet2/1        unassigned      YES unset  administratively down down
Serial3/0              unassigned      YES unset  administratively down down
Serial3/1              unassigned      YES unset  administratively down down
Serial3/2              unassigned      YES unset  administratively down down
Serial3/3              unassigned      YES unset  administratively down down
Serial3/4              unassigned      YES unset  administratively down down
Serial3/5              unassigned      YES unset  administratively down down
Serial3/6              unassigned      YES unset  administratively down down
Serial3/7              unassigned      YES unset  administratively down down
Tunnel0                10.0.0.1        YES manual up                    up
R1#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/67/140 ms
R1#

Şimdi wireshark çıktılarımızı inceleyelim.

Paketleri incelediğimizde 2 adet IP başlığı ve ek olarak bir de GRE bağlığı görüyoruz. Burada kafamız karışmasın wiresharkın gösteriminden ötürü burada tünel ip başlıklarını direk görüyoruz. Normalde L3 önlendirmenin yapıldığı ip adresleri ilk IPv4 başlığındaki ip adresleri. Bunu GRE üzerinden şifreleme yaptığımızda daha açık göreceğiz.

İlk ip başlığı tünel kaynak ve hedef ip adreslerinin olduğu kısımdır.Bu L3 iletişimi taşıyan ISP tarafından görülür ve yönlendirme bu ipler üzerinden yapılır.

Daha sonra ikinci ip başlığı tünel interfacelerden geçen trafiğe ait başlıktır. ISP tarafında bu ip adresi de görülür fakat bu kullanılarak yönlendirme yapılmaz. Burada şunu söylemek gerekir GRE tek başına size gizlilik ve güvenlik sağlamaz. Trafiğinizi şifrelemez. Trafiği şifrelemek için GRE üzerinde IPSec çalıştırmak gerekir.

GRE IP protokol 47’yi kullanır. Eğer networkte bu protokol güvenlik cihazları tarafından bloklanıyor ise yine iletişimde sorun yaşarsınız.

Biraz daha detaylara inelim.

Eğer GRE kullanıyor iseniz paketiniz içerisine yeni bir başlık eklendiğinden MTU ve MSS ayarını düzenlemeniz gerekebilir. GRE kendisi 4 byte’lık bir başlık ekler, yeni ip başlığı da 20 byte olur. Toplamda 24 byte’lık bir fazlalık oluşur. Cisco’nun önerdiği değer; MTU:1400 MSS:1360’tır.

Tünel interface’I için bazı Güvenlik önlemleri var bunlardan bir tanesi tunnel key komutu. Bu komut ile GRE içerisindeki 1 bit set edilerek temel güvenlik sağlanmış olur. İki tarafta da bu key’in eşleşmesi gerekmektedir.

interface tunnel 0
tunnel key 123456

Son olarak tünele bir de şifreleme ekleyelim. Bu sayede GRE tünelini tam anlamıyla kullanırız.

Normalde IPSec tünel için policy, transforms-set ve map oluşturulur. GRE over IPsec yapacak isek map ayarına gerek yoktur. Map içerisinde tanımlanan şifrelenecek trafik burada tünel interface’inden geçen her trafik olacağı için sadece profil oluşturup atamak yeterlidir.

crypto isakmp policy 1
 authentication pre-share
 encryption aes
 group 2
 hash sha
crypto ipsec transform-set GRE-Set esp-aes
crypto ipsec profile GRE-Profile
 set transform-set GRE-Set
interface Tunnel 0
 tunnel protection ipsec profile GRE-Profile

Bu aşamadan sonra artık tünel interface’leri arası trafiğimiz şifreli olarak görülecektir.

IPSec’I aktif ettikten sonra gördüğünüz üzere artık iki uç nokta arası ip başlıklarını görüyoruz fakat içeriği hakkında bir bilgimiz yok. GRE tünelinden gelen tüm paketler artık enkript ediliyor.

Şimdi bir özellik daha kontrol edelim. Tünel lokal ip adresleri dışında bir trafiği tünelden geçirelim.

Burada yine aradaki ISP’nin bizim yönlendirdiğimiz trafiği bilmesine gerek kalmadan ben istediğim trafiği GRE üzerinden aktarabilirim.

R1:
interface loop10
ip address 10.10.10.10 255.255.255.2555
ip route 20.20.20.20 255.255.255.255 tunnel0
R2:
interface loop20
ip address 20.20.20.20 255.255.255.255
ip route 10.10.10.10 255.255.255.255 tunnel0
ISP#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       + - replicated route, % - next hop override

Gateway of last resort is not set

      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.1.0/30 is directly connected, FastEthernet2/0
L        172.16.1.1/32 is directly connected, FastEthernet2/0
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/30 is directly connected, FastEthernet0/0
L        192.168.1.2/32 is directly connected, FastEthernet0/0
ISP#

Evet R1 üzerinde  oluşturduğumuz Loopback10 interface’I ile R2 üzerinden oluşturduğumuz Loopback20 interface’I GRE Tünel üzerinden haberleşti. Burada crypto tanımlarına bir ekleme yapmamıza gerek yok çünkü oluşturduğumuz IPSec profile’I tunel interface’ine direk uyguladık, bu interface içerisinden geçen her trafik enkripte eidlecek.

ISP router’ın üzerine bakarsanız yeni networklere ait bir bilgi bulunmuyor. Hala routerların kendisine bakan networklerini kullanarak routing yapıyor.

Aklıma GRe ile ilgili gelenler bunlar, ileriki yazılarda GRE üzerinden dinamik roting protokolü kullanmayı anlatabilirim.

Sağlıcakla kalın.