તમારું GCP VM OpenVPN IPv6 પૂલને કેમ જવાબ આપી શકતું નથી

તમારો IPv6 VPN ક્લાયંટ વર્કલોડ સુધી પહોંચે છે, વર્કલોડ ટનલની અંદર જવાબ આપે છે, અને જવાબ કદી પહોંચતો નથી. પહેલી વૃત્તિ ફાયરવોલ કે ટનલને દોષ આપવાની હોય છે, અને સામાન્ય રીતે બંનેમાંથી કોઈ દોષિત હોતું નથી. OpenVPN જે સરનામું આપે છે તે એક આંતરિક નેટવર્ક છે જે ફક્ત ટનલની અંદર જ અસ્તિત્વ ધરાવે છે; Google Cloud ને ખબર નથી કે fd42:90::/64 એક ચોક્કસ VM પાછળ હોવાનું છે, જ્યાં સુધી તમે તેને કહો નહીં.

બે અલગ સિસ્ટમોએ આ હકીકત શીખવી પડશે, અને તેમાંથી ફક્ત એક જ OpenVPN છે. VPC ને કંઈપણ પાછું મોકલતા પહેલા રૂટની જરૂર છે, અને VM ને જે આવે છે તે ફોરવર્ડ કરવાની પરવાનગી આપવી પડશે. કોઈપણ અડધી ભૂલ કરો તો લક્ષણ એકસરખું દેખાય છે.

પૂલ આંતરિક નેટવર્ક છે, સબનેટ નહીં

OpenVPN તમે પસંદ કરો તે શ્રેણીમાંથી IPv6 સરનામાં આપી શકે છે, અને તે શ્રેણી ટનલના બે છેડા વચ્ચેની એક કલ્પના છે. તે Google Cloud સબનેટ નથી, તે VPC સબનેટ યાદીમાં દેખાતું નથી, અને VM નું નેટવર્ક ઇન્ટરફેસ તે સરનામાં મેળવતું નથી. તેથી ક્લાયંટને જવાબ આપતો વર્કલોડ એવા સરનામે પેકેટ મોકલે છે જેને નેટવર્ક અનરૂટેબલ ગણે છે.

પૂલને VPC પહેલેથી વાપરે છે તે દરેક શ્રેણીની બહાર રાખો. તમારી બીજી ટનલ પાછળની શ્રેણીઓની પણ બહાર રાખો. ઓવરલેપ સ્વચ્છ રૂટિંગ નિષ્ફળતાને અનિયમિતમાં ફેરવે છે જે ફક્ત લોડ હેઠળ દેખાય છે.

fd42:90::/64 જેવું અનન્ય સ્થાનિક સરનામાંકન આ આંતરિક નેટવર્ક માટે વ્યાજબી પસંદગી છે. ઉપસર્ગ એ પણ યાદ કરાવે છે કે ડિઝાઇન સ્વભાવે ખાનગી છે. ULA પૂલમાં કંઈ પણ તેને જાહેર ઇન્ટરનેટ પર કાયદેસર સ્રોત બનાવતું નથી.

VPC ને લક્ષ્ય અને આગલું હોપ આપો

જવાબને એવા VPC રૂટની જરૂર છે જેનું લક્ષ્ય પૂલ હોય અને જેનું આગલું હોપ VPN VM હોય. વર્તમાન સ્ટેટિક-રૂટ દસ્તાવેજીકરણ IPv6 લક્ષ્ય શ્રેણીઓને આવરી લે છે અને કયા આગલા હોપ પ્રકારો પાત્ર છે તેની યાદી આપે છે, તેથી જૂનું IPv4 ઉદાહરણ કૉપિ કરવાને બદલે તમારી ટોપોલોજી માટે સમર્થિત સ્વરૂપ ચકાસો.

આગલા હોપનું સરનામું એવું હોવું જોઈએ જે ખરેખર ઇન્સ્ટન્સના ક્લાઉડ ઇન્ટરફેસને સોંપાયેલું હોય. VM નું આંતરિક ટનલ સરનામું તે સરનામું નથી. તેનો ઉપયોગ કરવાથી એવો રૂટ બને છે જે સ્વચ્છ રીતે ઇન્સ્ટોલ થાય છે અને કદી કોઈ પેકેટ સાથે મેળ ખાતો નથી. રૂટ લખતા પહેલા ઇન્ટરફેસ યાદી વાંચો.

રૂટની પ્રાથમિકતા એન્ટ્રી જેટલી જ મહત્વની છે. સબનેટ રૂટ તમે ઉમેરો તે કસ્ટમ રૂટ કરતાં વધુ વિશિષ્ટ છે, તેથી હાલની સબનેટ શ્રેણીમાંથી કાપેલો પૂલ કસ્ટમ રૂટ કેવી રીતે લખાયો હોય તે છતાં સબનેટ રૂટ સામે હારી જશે. અલગ પૂલ પસંદ કરો, પછી ખાતરી કરો કે રૂટ ઇન્સ્ટન્સને આગલા હોપ અને સાચો લક્ષ્ય ઉપસર્ગ દર્શાવે છે:

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

ફોરવર્ડિંગ બે વાર ચાલુ કરવું પડે

રૂટ પેકેટને ઇન્સ્ટન્સ સુધી પહોંચાડે છે. તે ઇન્સ્ટન્સને એવું કંઈ ફોરવર્ડ કરવા તૈયાર કરતું નથી જે તેને સંબોધિત નથી, અને તે પરવાનગી બે સ્તરે અસ્તિત્વ ધરાવે છે.

ક્લાઉડ બાજુને ઇન્સ્ટન્સ ફોરવર્ડિંગ ક્ષમતા ચાલુ હોવી જોઈએ; તે એ સેટિંગ છે જે VM ને એવા સરનામાંઓ માટે ટ્રાફિક સ્વીકારવા અને મોકલવા દે છે જે તેની માલિકીના નથી. ગેસ્ટ બાજુને પોતાનું IPv6 ફોરવર્ડિંગ જોઈએ, કારણ કે કર્નલ પેકેટ આવ્યા પછી અલગ નિર્ણય લે છે. એક પણ જવાબ ટનલ પાર કરે તે પહેલા બંને ચાલુ હોવા જોઈએ.

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

પછી ફાયરવોલ નિયમોએ આંતરિક સ્રોત શ્રેણીને બંને દિશામાં મંજૂરી આપવી પડશે. Google Cloud ડિકેપ્સ્યુલેટેડ પેકેટનું મૂલ્યાંકન કરે છે, તેથી ફક્ત VPC સબનેટ આવરી લેતો નિયમ ટનલ પહેલેથી સફળ થયા પછી પૂલનો ટ્રાફિક છોડી દે છે. પૂલને ઇનગ્રેસ નિયમમાં સ્રોત શ્રેણી તરીકે ઉમેરો, અને ચકાસો કે કોઈ કસ્ટમ ઇગ્રેસ પોલિસી જવાબને અવરોધતી નથી. ગર્ભિત પરવાનગી નિયમ ડિફૉલ્ટ કેસ આવરી લે છે, હાથે લખેલો ઇગ્રેસ નિયમ નહીં.

OpenVPN ને કહો કે કોનું શું છે

OpenVPN ક્લાયંટને ફોરવર્ડ કરે છે જ્યારે તે જાણે છે કે તે ક્લાયંટ લક્ષ્યનો માલિક છે. પૂલમાંથી આવતા ક્લાયંટ સરનામાં પૂલને વ્યાખ્યાયિત કરતી સર્વર સૂચના સંભાળે છે, પરંતુ ક્લાયંટ પાછળનું સબનેટ અલગ ગોઠવણી છે અને તે ક્લાયંટ માટે સ્પષ્ટ માલિકી એન્ટ્રીની જરૂર છે.

બંનેને ભેગા કરવાથી એવી ટનલ બને છે જ્યાં સર્વર પરની પિંગ કામ કરે છે અને તેની પાછળ કંઈ જ નહીં. તમે કયો કેસ બનાવી રહ્યા છો તે નક્કી કરો, પછી બીજી push લાઇન ઉમેરીને આશા રાખવાને બદલે મેળ ખાતી એન્ટ્રી લખો.

આ ડિઝાઇનની બહાર ઇન્ટરનેટ ઇગ્રેસ રાખો

ખાનગી ઍક્સેસ અને ઇન્ટરનેટ ઍક્સેસ અલગ યોજનાઓ છે. રૂટિંગ અને ફોરવર્ડિંગ સંમત થાય પછી ULA પૂલ ટનલ દ્વારા VPC વર્કલોડ સુધી પહોંચી શકે છે, અને તે જ પૂલને VPC દ્વારા જાહેર ઇન્ટરનેટ સુધી કોઈ માર્ગ નથી, કારણ કે ક્લાઉડ ગેટવે મનસ્વી ટનલ સ્રોતને પોતાના તરીકે સ્વીકારશે નહીં.

જો ક્લાયંટને ઇન્ટરનેટ ઇગ્રેસ પણ જોઈએ, તો તેના માટે સમર્થિત સરનામાંકન અને રૂટિંગ ડિઝાઇનની યોજના કરો, તેને ખાનગી પૂલથી સ્વતંત્ર રાખો અને બે માર્ગો અલગથી ચકાસો. એક કામ કરતો માર્ગ બીજા વિશે કંઈ કહેતો નથી, અને બંનેને ભેગા કરતી ડિઝાઇન તૂટેલી ટનલ જેવી રીતે નિષ્ફળ જાય છે.