OpenVPN në GCE: shtoni një alias IP përpara se të pushoni rrugët

Një klient telefonon serverin OpenVPN në një VM të Compute Engine, dritarja e statusit thotë i lidhur, dhe një ping drejt një hosti brenda VPC nuk arrin ende askund. Instinkti është të shtohet një rresht push më shumë, dhe kjo nuk e rregullon kurrë. Compute Engine vendos ku shkojnë paketat nga tabela e vet e rrugëve dhe nga adresat që një ndërfaqe e VM mban në të vërtetë, prandaj një pool tuneli që VM nuk e zotëron është një pool ku askush nuk dorëzon.

Ndiqni paketën që dështon në vend të skedarit të konfigurimit, dhe pjesët që mungojnë shfaqen sipas radhës.

Filloni nga paketa që vdes

SYN largohet nga klienti, hyn në tunel dhe arrin në VM si një paketë e inkapsuluar për një destinacion brenda VPC. OpenVPN e dekapsulon dhe përpiqet ta përçojë përmes eth0, ku fabric shtron një pyetje para çdo gjëje tjetër: a e zotëron ky instanc adresën e destinacionit. Një pool tuneli i prerë nga subnet-i i dikujt tjetër dështon në atë pyetje, dhe paketa hidhet përpara se të konsultohet ndonjë rrugë ose rregull firewall.

Pra drejtimi nga klienti në VPC ka dy kërkesa të ndara, dhe asnjëra nuk është direktivë push. VM-së i duhet një interval alias që mbulon pool-in e tunelit, dhe pikërisht kjo e bën atë pronar legjitim të atyre adresave. VPC-së i duhet një rrugë që e emërton VM-në si next hop për çdo prefix të mbrojtur. Nëse mungon njëra, paketa vdes në një vend tjetër, ndërsa klienti sheh të njëjtin heshtje.

Lexojeni dështimin në atë radhë, sepse nga ana e klientit të dyja kushtet duken identike. Një tunel që raporton i lidhur ndërsa asgjë nuk përgjigjet është shenja e një problemi topologjie, jo e një cipher të keq.

A e zotëron instanca pool-in e tunelit

Jepini VM-së një interval dytësor brenda subnet-it të vet, pastaj bëni OpenVPN të shpërndajë adresa pikërisht nga ai interval. Në një instanc adresa parësore e të cilit është 10.156.0.10/20, një alias /28 e mban pool-in të ndarë nga adresat që instancat e tjera tashmë mbajnë:

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

Atëherë direktiva server duhet të përshkruajë të njëjtin bllok. Adresa e saj e parë bëhet gateway-i i tunelit, dhe adresat e mbetura u shpërndahen klientëve. Këtu dy numra përshkruajnë një bllok, një rrjet dhe një netmask, dhe kjo është sintaksa e pool-it që OpenVPN ende pret.

server 10.156.1.0 255.255.255.240

Konfirmoni që adresa vërtet zbarkoi në ndërfaqe dhe jo vetëm në konfigurimin e OpenVPN. Fabric përçon atë që raporton NIC, jo atë që beson daemon. Një komandë e vendos këtë:

ip -4 addr show dev eth0

Një adresë dytësore që nuk arrin kurrë eth0, ose një pool që mbivendoset me një subnet tjetër, shfaqet më vonë si humbje me ndërprerje dhe jo si gabim në nisje. Daemon niset, klientët lidhen, dhe vetëm disa destinacione sillen gabim. Mbani intervalin alias të vogël që pool-i të njihet lehtë në një tabelë rrugësh. Asnjëherë mos e prisni nga një subnet që një instanc tjetër tashmë përdor.

Jepini trafikut të kthimit një next hop

Një përgjigje nga një host në VPC adresohet drejt një adrese klienti në pool-in e tunelit, e cila nuk i përket asnjë subnet-i që VPC njeh. Pa një rrugë për atë pool, përgjigja ndalon në hop-in e parë pa përputhje, dhe kërkesa mund të ketë pasur sukses në skajin tjetë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

E njëjta rrugë nevojitet për çdo prefix që ndodhet pas një klienti dhe jo brenda VPC. Atyre prefix-eve u duhet gjithashtu një zë iroute në skedarin ccd të atij klienti. Ai zë është kontabilitet në anën e serverit: i thotë serverit cili klient e zotëron prefix-in, dhe nuk instalon asgjë në vetë klientin.

Mbani listën push për anën e klientit të bisedës, sepse ajo shton vetëm rrugë në makinën që lidhet. Një rresht push për një subnet të VPC dhe një rrugë e VPC përsëri drejt pool-it janë dy gjysmat e të njëjtës shteg, dhe secila gjysmë vetëm prodhon një tunel që mban kërkesa por jo përgjigje.

Firewall-et, përçimi dhe hop-et në mes

Firewall-i i VPC vlerëson paketën e dekapsuluar, prandaj një rregull ingress duhet të lejojë pool-in e tunelit dhe çdo prefix site që arrin VM-në në atë mënyrë. Qëndrimi default-deny dështon në heshtje këtu: paketa hidhet pas dekapsulimit, dhe log-u i OpenVPN tregon një sesion të shëndetshëm.

Në çdo host Linux që përçon në vend që të përfundojë, kontrolloni që net.ipv4.ip_forward është aktivizuar. Rregulli i pronësisë vlen edhe atje: një makinë që përçon për një subnet që nuk e zotëron e hedh paketën njësoj si VM. Lexojeni vlerën përpara se të fajësoni tunelin.

Kur dështon saktësisht një prefix

Dështimi i pjesshëm është rasti më i lehtë për t'u lexuar, sepse çdo gjë tjetër në shteg tashmë është vërtetuar. Filloni me listën e rrugëve dhe lexoni intervalin e destinacionit dhe next hop-in e zërit që duhej të mbulonte prefix-in, pastaj lexoni përshkrimin e instancës dhe krahasoni intervalin e saj alias me pool-in që serveri shpërndan.

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

Një rrugë që mungon shfaqet si mungesë next hop për prefix-in, ndërsa një alias që mungon shfaqet si një paketë e hedhur në ndërfaqe; nga klienti të dyja duken njësoj dhe në ato dy dalje janë krejt të ndryshme. Nëse të dyja janë të pranishme, i dyshuari që mbetet është iroute ccd i klientit që pretendon prefix-in.

Shkruani katër vlerat pranë tunelit: intervali alias, pool-i i serverit, prefix-et e pushuara, rrugët e VPC. Një alias i vjetëruar thyen çdo adresë të pool-it, një rrugë e vjetëruar thyen një drejtim, një push që mungon e fsheh prefix-in nga klienti, dhe një iroute i gabuar e dërgon prefix-in te peer-i i gabuar. Personi i radhës që shton një subnet i nevojiten të katërta në një vend, dhe shënimi është më i lirë se mbrëmja.