Kodėl jūsų GCP VM negali atsakyti į OpenVPN IPv6 telkinį

Jūsų IPv6 VPN klientas pasiekia darbo krūvį, darbo krūvis atsako į tunelį, o atsakymas taip ir neateina. Pirmas instinktas – kaltinti ugniasienę ar tunelį, ir paprastai nė vienas iš jų nekaltas. Adresas, kurį išduoda OpenVPN, yra vidinis tinklas, egzistuojantis tik tunelio viduje; Google Cloud net neįsivaizduoja, kad fd42:90::/64 turėtų būti už vienos konkrečios VM, kol jūs jam to nepasakysite.

Šį faktą turi išmokti dvi atskiros sistemos, ir tik viena iš jų yra OpenVPN. VPC reikia maršruto, kad galėtų ką nors siųsti atgal, o VM turi būti leidžiama persiųsti tai, kas ateina. Suklyskite bet kurioje pusėje – simptomas atrodys identiškai.

Telkinys yra vidinis tinklas, o ne potinklis

OpenVPN gali išduoti IPv6 adresus iš jūsų pasirinkto diapazono, ir tas diapazonas yra fikcija, dėl kurios sutaria abu tunelio galai. Tai ne Google Cloud potinklis, jis nerodomas VPC potinklių sąraše, o VM tinklo sąsaja negauna tų adresų. Todėl darbo krūvis, atsakantis klientui, siunčia paketą adresu, kurį tinklas laiko nemaršrutizuojamu.

Laikykite telkinį už kiekvieno diapazono, kurį VPC jau naudoja. Laikykite jį ir už diapazonų, esančių už kitų jūsų tunelių. Persidengimas švarią maršrutizavimo klaidą paverčia periodiška, kuri pasireiškia tik esant apkrovai.

Unikalus vietinis adresavimas, pavyzdžiui, fd42:90::/64, yra pagrįstas pasirinkimas šiam vidiniam tinklui. Prefiksas taip pat primena, kad dizainas iš prigimties yra privatus. Nieko ULA telkinyje nepadaro jo teisėtu šaltiniu viešajame internete.

Suteikite VPC tikslą ir kitą šuolį

Atsakymui reikia VPC maršruto, kurio tikslas yra telkinys, o kitas šuolis – VPN VM. Dabartinė statinių maršrutų dokumentacija apima IPv6 tikslo diapazonus ir išvardija, kurie kito šuolio tipai yra tinkami, todėl patikrinkite palaikomą formą savo topologijai, o ne kopijuokite senesnį IPv4 pavyzdį.

Kito šuolio adresas turi būti toks, kuris iš tikrųjų priskirtas egzemplioriaus debesijos sąsajai. VM vidinis tunelio adresas nėra tas adresas. Vis tiek jį naudojant gaunamas maršrutas, kuris įdiegiamas švariai ir niekada neatitinka jokio paketo. Perskaitykite sąsajų sąrašą prieš rašydami maršrutą.

Maršruto prioritetas yra toks pat svarbus kaip ir įrašas. Potinklio maršrutai yra konkretesni nei jūsų pridedami pasirinktiniai maršrutai, todėl telkinys, iškirptas iš esamo potinklio diapazono, pralaimės potinklio maršrutui, nesvarbu, kaip parašytas pasirinktinis maršrutas. Pasirinkite atskirą telkinį, tada patvirtinkite, kad maršrutas rodo egzempliorių kaip kitą šuolį ir teisingą tikslo prefiksą:

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

Persiuntimą reikia įjungti du kartus

Maršrutas pristato paketą egzemplioriui. Jis nepadaro egzemplioriaus pasirengusio persiųsti tai, kas jam neadresuota, ir šis leidimas egzistuoja dviem lygmenimis.

Debesijos pusėje turi būti įjungta egzemplioriaus persiuntimo galimybė; tai nustatymas, leidžiantis VM priimti srautą adresams, kurių jis neturi, ir jį perduoti. Svečio pusėje reikia savo IPv6 persiuntimo, nes branduolys po paketo atvykimo priima atskirą sprendimą. Abu turi būti įjungti, kol vienas atsakymas peržengs tunelį.

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

Tada ugniasienės taisyklės turi leisti vidinį šaltinio diapazoną abiem kryptimis. Google Cloud vertina išpakuotą paketą, todėl taisyklė, apimanti tik VPC potinklį, numeta telkinio srautą po to, kai tunelis jau pavyko. Pridėkite telkinį kaip šaltinio diapazoną į įeinančio srauto taisyklę ir patikrinkite, ar jokia pasirinktinė išeinančio srauto politika neblokuoja atsakymo. Numanoma leidimo taisyklė apima numatytąjį atvejį, ranka parašyta išeinančio srauto taisyklė – ne.

Pasakykite OpenVPN, kam kas priklauso

OpenVPN persiunčia klientui, kai žino, kad tas klientas valdo tikslą. Klientų adresus iš telkinio tvarko serverio direktyva, apibrėžianti telkinį, tačiau potinklis už kliento yra kitokia tvarka ir reikalauja aiškaus nuosavybės įrašo tam klientui.

Sumaišius abu, gaunamas tunelis, kuriame ping į serverį veikia, o nieko už jo – ne. Nuspręskite, kurį atvejį kuriate, tada parašykite atitinkamą įrašą, o ne pridėkite antrą push eilutę ir tikėkitės.

Laikykite interneto išėjimą už šio dizaino ribų

Privataus priėjimo ir interneto prieiga yra atskiri planai. ULA telkinys gali pasiekti VPC darbo krūvius per tunelį, kai maršrutizavimas ir persiuntimas sutampa, ir tas pats telkinys neturi kelio į viešąjį internetą per VPC, nes debesijos šliuzas nepriims savavališko tunelio šaltinio kaip savo.

Jei klientams taip pat reikia interneto išėjimo, suplanuokite tam palaikomą adresavimo ir maršrutizavimo dizainą, laikykite jį nepriklausomą nuo privataus telkinio ir testuokite abu kelius atskirai. Vienas veikiantis kelias nieko nesako apie kitą, o dizainas, kuris juos supainioja, žlunga taip, kad atrodo kaip sugedęs tunelis.