GCE'de OpenVPN: rotaları push etmeden önce bir alias IP ekleyin

Push edilen bir rota VM'i next hop yapmaz. Alias IP aralığını ekleyin, sunucu havuzuyla eşleştirin ve istemcileri test etmeden önce VPC dönüş rotasını oluşturun.

Bir istemci Compute Engine VM'deki OpenVPN sunucusuna bağlanır, durum penceresi bağlı der, ve VPC içindeki bir konağa ping hâlâ hiçbir yere gitmez. İçgüdü bir push satırı daha eklemektir ve bu asla sorunu çözmez. Compute Engine paketlerin nereye gideceğine kendi rota tablosundan ve VM arayüzünün gerçekte tuttuğu adreslerden karar verir, bu yüzden VM'in sahip olmadığı bir tünel havuzu kimsenin teslim etmediği bir havuzdur.

Yapılandırma dosyası yerine ölen paketi izleyin, eksik parçalar sırayla ortaya çıkar.

Ölen paketten başlayın

SYN istemciden çıkar, tünele girer ve VPC içindeki bir hedefe yönelik kapsüllenmiş paket olarak VM'e ulaşır. OpenVPN onu kapsülden çıkarır ve eth0 üzerinden iletmeye çalışır; burada fabric her şeyden önce tek bir soru sorar: bu örnek hedef adrese sahip mi. Başkasının subnet'inden kesilmiş bir tünel havuzu bu soruda başarısız olur ve paket herhangi bir rota ya da güvenlik duvarı kuralına bakılmadan atılır.

Yani istemciden VPC'ye yönün iki ayrı gereksinimi vardır ve hiçbiri push yönergesi değildir. VM'in tünel havuzunu kapsayan bir alias aralığına ihtiyacı vardır ve onu bu adreslerin meşru sahibi yapan tam olarak budur. VPC'nin her korunan prefix için VM'i next hop olarak adlandıran bir rotaya ihtiyacı vardır. Biri eksikse paket başka bir yerde ölür, istemci ise aynı sessizliği görür.

Arızayı bu sırayla okuyun, çünkü istemci tarafından iki koşul aynı görünür. Hiçbir şey yanıt vermezken bağlı olduğunu bildiren bir tünel, kötü bir şifrelemenin değil topoloji sorununun imzasıdır.

Örnek tünel havuzuna sahip mi

VM'e kendi subnet'i içinde ikincil bir aralık verin, sonra OpenVPN adresleri tam olarak o aralıktan dağıtsın. Birincil adresi 10.156.0.10/20 olan bir örnekte /28 alias havuzu diğer örneklerin zaten tuttuğu adreslerden ayırır:

gcloud compute instances network-interfaces update openvpn-vm \
  --zone=europe-west1-b \
  --aliases=eth0:10.156.1.0/28

Ardından server yönergesi aynı bloğu tanımlamalıdır. İlk adresi tünelin gateway'i olur ve kalan adresler istemcilere dağıtılır. Burada iki sayı bir bloğu tanımlar, bir ağ ve bir netmask, ve bu OpenVPN'in hâlâ beklediği havuz sözdizimidir.

server 10.156.1.0 255.255.255.240

Adresin gerçekten arayüze indiğini, yalnızca OpenVPN yapılandırmasında kalmadığını doğrulayın. Fabric, NIC'in bildirdiğini iletir, daemonun inandığını değil. Tek bir komut bunu çözer:

ip -4 addr show dev eth0

eth0'a asla ulaşmayan ikincil bir adres ya da başka bir subnet ile çakışan bir havuz, daha sonra başlangıç hatası olarak değil aralıklı kayıp olarak görünür. Daemon başlar, istemciler bağlanır ve yalnızca bazı hedefler yanlış davranır. Alias aralığını küçük tutun ki havuz rota tablosunda kolayca tanınsın. Onu asla başka bir örneğin zaten kullandığı bir subnet'ten kesmeyin.

Dönüş trafiğine next hop verin

VPC'deki bir konaktan gelen yanıt, tünel havuzundaki bir istemci adresine yöneliktir ve bu adres VPC'nin bildiği hiçbir subnet'e ait değildir. O havuz için rota yoksa yanıt eşleşme bulamayan ilk hopta durur ve istek uzak uçta pekâlâ başarılı olmuş olabilir.

gcloud compute routes create openvpn-return \
  --network=prod-vpc \
  --destination-range=192.168.127.0/24 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b \
  --priority=800

Aynı rota, VPC içinde değil bir istemcinin arkasında duran her prefix için gereklidir. O prefixler ayrıca o istemcinin ccd dosyasında bir iroute girdisine ihtiyaç duyar. Bu girdi sunucu tarafında muhasebedir: sunucuya prefixin hangi istemciye ait olduğunu söyler ve istemcinin kendisine hiçbir şey kurmaz.

Push listesini konuşmanın istemci tarafı için saklayın, çünkü yalnızca bağlanan makineye rotalar ekler. Bir VPC subnet'i için push satırı ve havuza dönüş VPC rotası aynı yolun iki yarısıdır ve her yarım tek başına istekleri taşıyan ama yanıtları taşımayan bir tünel üretir.

Güvenlik duvarları, iletme ve aradaki hoplar

VPC güvenlik duvarı kapsülden çıkarılmış paketi değerlendirir, bu yüzden bir ingress kuralı tünel havuzunu ve bu yolla VM'e ulaşan her site prefixini kabul etmelidir. Varsayılan reddetme tutumu burada sessizce başarısız olur: paket kapsül çözüldükten sonra atılır ve OpenVPN günlüğü sağlıklı bir oturum gösterir.

İletme yapan, sonlandırmayan her Linux ana bilgisayarında net.ipv4.ip_forward'ın etkin olduğunu kontrol edin. Sahiplik kuralı orada da geçerlidir: sahip olmadığı bir subnet için ileten makine paketi tıpkı VM gibi atar. Tüneli suçlamadan önce değeri okuyun.

Tam olarak bir prefix başarısız olduğunda

Kısmi arıza okunması en kolay durumdur, çünkü yoldaki diğer her şey zaten kanıtlanmıştır. Rota listesiyle başlayın ve prefixi kapsaması gereken girdinin hedef aralığını ve next hop'unu okuyun, sonra örnek açıklamasını okuyup alias aralığını sunucunun dağıttığı havuzla karşılaştırın.

gcloud compute routes list --filter=destination-range~10.164.0.0
 gcloud compute instances describe openvpn-vm --format=get(networkInterfaces[0].aliasIpRanges)

Eksik rota prefix için next hop yokluğu olarak görünür, eksik alias ise arayüzde atılan paket olarak; istemciden ikisi benzer görünür ve o iki çıktıda tamamen farklıdır. İkisi de varsa geriye kalan şüpheli, prefixi talep eden istemcinin ccd iroute'udur.

Dört değeri tünelin yanına yazın: alias aralığı, sunucu havuzu, push edilen prefixler, VPC rotaları. Eskimiş alias havuzdaki her adresi bozar, eskimiş rota bir yönü bozar, eksik push prefixi istemciden saklar ve yanlış iroute prefixi yanlış peer'a gönderir. Bir sonraki subnet ekleyen kişi dördüne de tek yerde ihtiyaç duyar ve not akşamdan ucuzdur.

İlgili makaleler