GCE-də OpenVPN: route-ları push etməzdən əvvəl alias IP əlavə edin

Müştəri Compute Engine VM-də OpenVPN serverinə qoşulur, status pəncərəsi qoşulub deyir, lakin VPC daxilindəki hosta ping hələ də heç yerə çatmır. İnstinkt daha bir push sətri əlavə etməkdir və bu heç vaxt problemi həll etmir. Compute Engine paketlərin hara getdiyini öz route cədvəlinə və VM interfeysinin həqiqətən saxladığı ünvanlara əsasən qərar verir, ona görə VM-in sahibi olmadığı tunnel pool heç kimin çatdırmadığı pool-dur.

Konfiqurasiya faylı yerinə uğursuz olan paketi izləyin və çatışmayan hissələr sıra ilə görünəcək.

Ölən paketdən başlayın

SYN müştəridən çıxır, tunnelə daxil olur və VPC daxilindəki təyinat üçün inkapsullaşdırılmış paket kimi VM-ə çatır. OpenVPN onu dekapsulyasiya edir və eth0 vasitəsilə ötürməyə çalışır, burada fabric hər şeydən əvvəl bir sual verir: bu instans təyinat ünvanına sahibdirmi. Başqasının subnet-indən kəsilmiş tunnel pool bu sualda uğursuz olur və paket hər hansı route və ya firewall qaydasına baxılmadan atılır.

Beləliklə, müştəridən VPC-yə istiqamətin iki ayrı tələbi var və heç biri push təlimatı deyil. VM-ə tunnel pool-u əhatə edən alias aralığı lazımdır və bu onu həmin ünvanların qanuni sahibi edir. VPC-yə hər qorunan prefix üçün VM-i next hop kimi göstərən route lazımdır. Biri çatışmasa paket başqa yerdə ölür, müştəri isə eyni sükutu görür.

Nasazlığı bu sıra ilə oxuyun, çünki müştəri tərəfindən iki şərt eyni görünür. Heç nə cavab vermədiyi halda qoşulduğunu bildirən tunnel topologiya probleminin əlamətidir, pis şifrənin deyil.

İnstans tunnel pool-a sahibdirmi

VM-ə öz subnet-i daxilində ikinci dərəcəli aralıq verin, sonra OpenVPN ünvanları məhz həmin aralıqdan paylasın. Əsas ünvanı 10.156.0.10/20 olan instansda /28 alias pool-u digər instansların artıq saxladığı ünvanlardan ayırır:

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

Sonra server təlimatı eyni bloku təsvir etməlidir. Onun birinci ünvanı tunnel gateway-i olur, qalan ünvanlar isə müştərilərə verilir. Burada iki rəqəm bir bloku təsvir edir, şəbəkə və netmask, və bu OpenVPN-in hələ də gözlədiyi pool sintaksisidir.

server 10.156.1.0 255.255.255.240

Ünvanın həqiqətən interfeysə düşdüyünü, yalnız OpenVPN konfiqurasiyasında qalmadığını təsdiqləyin. Fabric NIC-in bildirdiyini ötürür, daemonun inandığını deyil. Bir əmr bunu həll edir:

ip -4 addr show dev eth0

eth0-a heç vaxt çatmayan ikinci dərəcəli ünvan və ya başqa subnet ilə üst-üstə düşən pool sonradan başlanğıc xətası kimi deyil, fasiləli itki kimi görünür. Daemon başlayır, müştərilər qoşulur və yalnız bəzi təyinatlar səhv davranır. Alias aralığını kiçik saxlayın ki, pool route cədvəlində asan tanınsın. Onu heç vaxt başqa instansın artıq istifadə etdiyi subnet-dən kəsməyin.

Geri trafikə next hop verin

VPC-dəki hostdan cavab tunnel pool-dakı müştəri ünvanına ünvanlanır, bu ünvan VPC-nin bildiyi heç bir subnet-ə aid deyil. Bu pool üçün route olmadan cavab uyğunluq tapmayan ilk hopda dayanır və sorğu o biri tərəfdə tamamilə uğurlu ola bilər.

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

Eyni route müştərinin arxasında, VPC daxilində olmayan hər prefix üçün lazımdır. Həmin prefixlərə həmçinin həmin müştərinin ccd faylında iroute qeydi lazımdır. Bu qeyd server tərəfində mühasibatdır: serverə hansı müştərinin prefix-ə sahib olduğunu deyir və müştərinin özünə heç nə quraşdırmır.

Push siyahısını söhbətin müştəri tərəfi üçün saxlayın, çünki o yalnız qoşulan maşına route əlavə edir. VPC subnet-i üçün push sətri və pool-a geri VPC route eyni yolun iki yarısıdır və hər yarım təkbaşına sorğuları daşıyan, amma cavabları daşımayan tunnel yaradır.

Firewall-lar, yönləndirmə və aradakı hop-lar

VPC firewall-ı dekapsulyasiya olunmuş paketi qiymətləndirir, ona görə ingress qaydası tunnel pool-a və bu yolla VM-ə çatan hər site prefix-ə icazə verməlidir. Default-deny mövqeyi burada səssizcə uğursuz olur: paket dekapsulyasiyadan sonra atılır və OpenVPN jurnalı sağlam sessiya göstərir.

Yönləndirən, bitirməyən hər Linux hostda net.ipv4.ip_forward-ın aktiv olduğunu yoxlayın. Mülkiyyət qaydası orada da tətbiq olunur: sahibi olmadığı subnet üçün yönləndirən maşın paketi VM kimi atır. Tunnel-i günahlandırmazdan əvvəl dəyəri oxuyun.

Tam bir prefix uğursuz olduqda

Qismən nasazlıq oxumaq üçün ən asan haldır, çünki yolda qalan hər şey artıq sübut olunub. Route siyahısından başlayın və prefix-i əhatə etməli olan qeydin təyinat aralığını və next hop-unu oxuyun, sonra instans təsvirini oxuyun və onun alias aralığını serverin payladığı pool ilə müqayisə edin.

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

Çatışmayan route prefix üçün next hop olmaması kimi görünür, çatışmayan alias isə interfeysdə atılmış paket kimi; müştəridən ikisi oxşar görünür və o iki çıxışda tamamilə fərqlidir. Əgər ikisi də varsa, qalan şübhəli prefix-ə iddia edən müştərinin ccd iroute-udur.

Dörd dəyəri tunnelin yanına yazın: alias aralığı, server pool-u, push edilmiş prefixlər, VPC route-ları. Köhnəlmiş alias pool-dakı hər ünvanı pozur, köhnəlmiş route bir istiqaməti pozur, çatışmayan push prefix-i müştəridən gizlədir və səhv iroute prefix-i səhv peer-ə göndərir. Subnet əlavə edəcək növbəti şəxs dördünü bir yerdə lazım bilir və bu qeyd axşamdan ucuzdur.