Pse VM-ja juaj në GCP nuk mund t’i përgjigjet pool-it IPv6 të OpenVPN

Klienti juaj VPN IPv6 arrin ngarkesën e punës, ngarkesa përgjigjet brenda tunelit dhe përgjigjja nuk arrin kurrë. Instinkti i parë është të fajësohet firewalls ose tuneli, dhe zakonisht asnjëri nuk është fajtor. Një adresë e dhënë nga OpenVPN është një rrjet i brendshëm që ekziston vetëm brenda tunelit; Google Cloud nuk e ka idenë se fd42:90::/64 duhet të jetë pas një VM të caktuar derisa t’i thoni.

Dy sisteme të ndara duhet ta mësojnë këtë fakt, dhe vetëm njëri prej tyre është OpenVPN. VPC-ja ka nevojë për një rrugë përpara se të mund të dërgojë diçka mbrapsht, dhe VM-së duhet t’i lejohet të përcjellë atë që vjen. Gaboni në cilëndo gjysmë dhe simptomi duket identik.

Pool-i është një rrjet i brendshëm, jo një nënrrjet

OpenVPN mund të japë adresa IPv6 nga një interval që zgjidhni ju, dhe ai interval është një trillim për të cilin bien dakord dy skajet e tunelit. Nuk është një nënrrjet i Google Cloud, nuk shfaqet në listën e nënrrjeteve të VPC-së, dhe ndërfaqja e rrjetit të VM-së nuk i merr ato adresa. Prandaj një ngarkesë pune që i përgjigjet një klienti dërgon një paketë drejt një adrese që rrjeti e konsideron të parrutsueshme.

Mbani pool-in jashtë çdo intervali që VPC-ja përdor tashmë. Mbajeni jashtë edhe intervaleve pas tuneleve tuaja të tjera. Mbivendosja e kthen një dështim të pastër rrugëtimi në një të herëpashershëm që shfaqet vetëm nën ngarkesë.

Adresimi lokal unik si fd42:90::/64 është një zgjedhje e arsyeshme për këtë rrjet të brendshëm. Prefiksi kujton gjithashtu se dizajni është privat nga natyra. Asgjë në një pool ULA nuk e bën atë burim legjitim në internetin publik.

Jepini VPC-së një destinacion dhe një hap tjetër

Përgjigjja ka nevojë për një rrugë VPC, destinacioni i së cilës është pool-i dhe hapi tjetër i së cilës është VM-ja VPN. Dokumentacioni aktual i rrugëve statike mbulon intervalet e destinacionit IPv6 dhe rendit cilat lloje të hapit tjetër janë të pranueshme, pra verifikoni formën e mbështetur për topologjinë tuaj në vend që të kopjoni një shembull IPv4 më të vjetër.

Një adresë e hapit tjetër duhet të jetë një që është realisht e caktuar për ndërfaqen cloud të instancës. Adresa e brendshme e tunelit të VM-së nuk është ajo adresë. Përdorimi i saj gjithsesi prodhon një rrugë që instalohet pastër dhe nuk përputhet kurrë me një paketë. Lexoni listën e ndërfaqeve përpara se të shkruani rrugën.

Përparësia e rrugës është po aq e rëndësishme sa vetë zëri. Rrugët e nënrrjeteve janë më specifike se rrugët e personalizuara që shtoni, kështu që një pool i prerë nga një interval nënrrjeti ekzistues do të humbasë ndaj rrugës së nënrrjetit, pavarësisht se si është shkruar rruga e personalizuar. Zgjidhni një pool të veçantë, më pas konfirmoni që rruga e tregon instancën si hapin tjetër dhe prefiksin e saktë të destinacionit:

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

Përcjellja duhet të aktivizohet dy herë

Një rrugë e dorëzon paketën te instanca. Nuk e bën instancën të gatshme të përcjellë diçka që nuk i është drejtuar asaj, dhe ky leje ekziston në dy shtresa.

Ana e cloud-it ka nevojë që aftësia e përcjelljes së instancës të jetë e aktivizuar; ky është parametri që lejon një VM të marrë trafik për adresa që nuk i zotëron dhe ta kalojë më tej. Ana e mysafirit ka nevojë për përcjelljen e vet IPv6, sepse kerneli merr një vendim të veçantë pasi paketa arrin. Të dyja duhet të jenë të ndezura përpara se një përgjigje e vetme të kalojë tunelin.

sysctl -w net.ipv6.conf.all.forwarding=1

Më pas rregullat e firewall-it duhet të lejojnë intervalin e brendshëm të burimit në të dy drejtimet. Google Cloud e vlerëson paketën e dekapsuluar, pra një rregull që mbulon vetëm nënrrjetin e VPC-së e hedh trafikun e pool-it pasi tuneli ka pasur sukses tashmë. Shtoni pool-in si interval burimi në rregullin hyrës dhe kontrolloni që asnjë politikë dalëse e personalizuar të mos e bllokojë përgjigjjen. Rregulli i nënkuptuar i lejimit mbulon rastin standard, një rregull dalës i shkruar me dorë jo.

Tregojini OpenVPN kush zotëron çfarë

OpenVPN përcjell te një klient kur e di që ai klient e zotëron destinacionin. Adresat e klientëve nga pool-i trajtohen nga direktiva e serverit që përcakton pool-in, por një nënrrjet pas një klienti është një rregullim tjetër dhe kërkon një zë të qartë pronësie për atë klient.

Ngatërrimi i të dyjave prodhon një tunel ku ping-et drejt serverit funksionojnë dhe asgjë pas tij nuk funksionon. Vendosni cilin rast po ndërtoni, më pas shkruani zërin përkatës në vend që të shtoni një rresht të dytë push dhe të shpresoni.

Mbani daljen në internet jashtë këtij dizajni

Qasja private dhe qasja në internet janë plane të ndara. Një pool ULA mund t’i arrijë ngarkesat e punës të VPC-së përmes tunelit kur rrugëtimi dhe përcjellja bien dakord, dhe i njëjti pool nuk ka rrugë drejt internetit publik përmes VPC-së, sepse porta e cloud-it nuk do të pranojë një burim tuneli arbitrar si të vetin.

Nëse klientët kanë nevojë edhe për dalje në internet, planifikoni një dizajn adresimi dhe rrugëtimi të mbështetur për atë, mbajeni të pavarur nga pool-i privat dhe testoni të dy rrugët veçmas. Një rrugë që funksionon nuk thotë asgjë për tjetrën, dhe një dizajn që i ngatërron të dyja dështon në një mënyrë që duket si tunel i prishur.