GCP VM પર Cloud VPN: આંતરિક IP વાપરો, NAT IP નહીં
ગેટવે એન્ડપોઇન્ટ, VM નું આંતરિક સરનામું અને બાહ્ય એક-થી-એક NAT સરનામું ત્રણ જુદી જુદી જવાબદારીઓ ભજવે છે. તમારો રૂટ કયું વાપરે છે તે તપાસો.
જ્યારે સ્થાનિક નેટવર્ક Cloud VPN દ્વારા VPC સુધી પહોંચે છે, ત્યારે Compute Engine સેવા માટેનું ગંતવ્ય સામાન્ય રીતે VM નું આંતરિક સરનામું હોય છે. બાહ્ય IPv4 સરનામું એ બીજું સરનામું નથી જે તમે એ જ ખાનગી રૂટમાં મૂકી શકો. આ ક્ષેત્રમાં મોટાભાગની ગૂંચવણ એથી ઊભી થાય છે કે ત્રણ જવાબદારીઓ ધરાવતાં ત્રણ સરનામાંને એકબીજાના બદલે વાપરી શકાય તેમ ગણવામાં આવે છે, તેથી શરૂઆત એ કરો કે આપેલ પેકેટ કયું વાપરે છે તેનું નામ આપો.
ત્રણ સરનામાં, ત્રણ જવાબદારીઓ
એમાંથી કોઈપણને ડિબગ કરતા પહેલાં ત્રણેયનાં નામ આપો, કારણ કે જવાબ બદલાય તેનાથી તમે આગળ કઈ વસ્તુ તપાસશો.
| Address | Job |
|---|---|
| Cloud VPN endpoint | where the IPsec peers meet |
| Internal IP | the address your route and firewall must name |
| External IPv4 | the platform's inbound mapping, not a guest address |
પ્રથમ ટનલનું છે. બીજું તમારા રૂટ અને ફાયરવોલ ડિઝાઇનનું છે. ત્રીજું આવતી ઇન્ટરનેટ ઍક્સેસનું છે અને તે મેપ થાય છે, જોડાય નહીં. એમાંથી એક માટે કામ કરતી ડિઝાઇન બાકીના બે વિશે કંઈ કહેતી નથી.
બાહ્ય સરનામું બીજું ઇન્ટરફેસ કેમ નથી
Compute Engine પર આંતરિક અને બાહ્ય પહોંચ કેવી રીતે અલગ પડે છે તે માટે સરનામાંકન માર્ગદર્શિકા જ સત્તાધારી છે. Compute Engine નું બાહ્ય IPv4 એ ઇન્સ્ટન્સના એકમાત્ર આંતરિક NIC પર એક-થી-એક મેપિંગ છે, તેથી ગેસ્ટને તે NIC પર ક્યારેય બીજું ઇન્ટરફેસ કે બીજું સરનામું દેખાતું નથી. VM અંદરથી જે જણાવે છે તે હજી પણ એક પ્રાથમિક આંતરિક સરનામું જ છે.
તેથી જ ખાનગી ક્લાયન્ટ ટનલ દ્વારા 10.24.1.7 તરફ રૂટ કરે છે અને VM ના બાહ્ય સરનામાને લક્ષ્ય બનાવતો ક્લાયન્ટ જુદા માર્ગો પર હોય છે. જાહેર સરનામા માટે ફાયરવોલ નિયમ ખોલવાથી VPC રૂટમાં કંઈ બદલાતું નથી જેને ટનલનો ટ્રાફિક વહન કરવાનો છે, અને ગેસ્ટ રૂટમાં ફેરફાર કરવાથી પ્લેટફોર્મનું મેપિંગ ખસતું નથી. તમારો રૂટ જે સરનામાનું નામ આપે છે તે પસંદ કરો, પછી ફક્ત એ જ ઑબ્જેક્ટ તપાસો જે તેને સંચાલિત કરે છે. આ શિસ્ત આ ટ્રબલશૂટિંગ માર્ગમાંથી મોટાભાગની અટકળ દૂર કરે છે.
gcloud સાથે માર્ગ ચાલો
ઇન્સ્ટન્સથી શરૂ કરો અને એ જ ઑબ્જેક્ટમાંથી બંને સરનામાં વાંચો, જેથી તમે જાણી શકો કે તમારું દસ્તાવેજીકરણ કયા વિશે વાત કરે છે:
gcloud compute instances describe app-1 --zone=europe-west1-b \
--format="value(networkInterfaces[0].networkIP,networkInterfaces[0].accessConfigs[0].natIP)"પછી જે રૂટિંગ અને પરવાનગી પર માર્ગ ખરેખર આધાર રાખે છે તેની પુષ્ટિ કરો:
gcloud compute routes list --filter="destRange:10.24.1.0/24"
gcloud compute firewall-rules list --filter="sourceRanges:10.99.0.0/24"
gcloud compute vpn-tunnels describe TUNNEL_NAME --region=europe-west1ટનલના જાહેર કરેલા અને શીખેલા રેન્જ વાંચો, વર્કલોડ સબનેટ માટેનો VPC રૂટ, અને સ્થાનિક સ્રોતને મંજૂરી આપતો ફાયરવોલ નિયમ. ગેસ્ટ પરનો લિસનર સંબંધિત બને તે પહેલાં આ ત્રણેય મળવા જોઈએ.
પછી ગેસ્ટ તપાસો: સેવા આંતરિક સરનામા પર સાંભળે છે, અને તેનો પરત માર્ગ ફરી VPC દ્વારા પસાર થાય છે? ફક્ત જાહેર સરનામા સાથે જોડાયેલો લિસનર આ કસોટીમાં નિષ્ફળ જશે, તેમ છતાં ક્લાઉડ બાજુનો દરેક ઑબ્જેક્ટ સાચો હોય.
જાહેર પ્રીફિક્સ એ બીજો પ્રશ્ન છે
ઉપરમાંથી કંઈ પણ એ અર્થમાં નથી કે VPN ની અંદર વહન થતું દરેક સરનામું RFC1918 હોવું જ જોઈએ. દૂરના નેટવર્કને જાહેર અવકાશમાંથી કાયદેસર રીતે નંબર આપી શકાય, જો પ્લેટફોર્મ રૂટિંગને સમર્થન આપે અને ઑપરેટર પાસે સરનામાનું સત્તાધિકાર હોય. આ એક સામાન્ય ડિઝાઇન પસંદગી છે.
આ સામાન્ય બાહ્ય NAT સરનામાને બીજા આંતરિક સબનેટ સરનામા તરીકે ગણવા જેવું નથી. એક પ્રીફિક્સ છે જે તમે રૂટ કરો છો; બીજું મેપિંગ છે જે પ્લેટફોર્મ આવતી ઍક્સેસ પર લાગુ કરે છે.
બાહ્ય IPv6 અને ખાસ રચાયેલા સરનામા ગોઠવણીની પોતાની અર્થશાસ્ત્ર છે. જો તમારી યોજના એમાંથી એક પર આધારિત હોય, તો IPv4 કેસમાંથી સામાન્યીકરણ કરવાને બદલે તે સુવિધા માટે પ્લેટફોર્મનું દસ્તાવેજીકરણ વાંચો. IPv4 મેપિંગ સામાન્ય કેસ છે, એકમાત્ર નહીં, અને દરેક અપવાદના પોતાના નિયમો છે.
ઓવરલેપ થતી રેન્જ એ બીજી સમસ્યા છે
ઓવરલેપ થતી ખાનગી રેન્જ એ લોકો જાહેર સરનામા તરફ વળવાનું ખરું કારણ છે, અને તે ખોટો લિવર છે. ગંતવ્યને VM ના NAT સરનામામાં બદલવાથી ઓવરલેપ ઉકેલાતું નથી; તે બદલે છે કે પેકેટ કયા સરનામા માટે હોવાનો દાવો કરે છે, પરત માર્ગ કેવી રીતે કામ કરે છે તે વ્યાખ્યાયિત કર્યા વિના.
ઓવરલેપ જાણી જોઈને ઉકેલો: ફરીથી નંબર આપો, સમર્થિત અનુવાદ ડિઝાઇન વાપરો, અથવા એવા નેટવર્ક દ્વારા રૂટ કરો જ્યાં પ્રીફિક્સ અથડાય નહીં. એમાંથી દરેક માલિક ધરાવતી ડિઝાઇન છે. NAT સરનામું ડિઝાઇન નથી.
બે ફીલ્ડ અલગ રીતે દસ્તાવેજ કરો
ટનલ પીઅર અને વર્કલોડ ગંતવ્યને બે અલગ રનબુક ફીલ્ડ તરીકે નોંધો, દરેક સાથે તેને ટેકો આપતો રૂટ અને ફાયરવોલ નિયમ. ઉપર આવતી IPsec ટનલ ફક્ત એટલું કહે છે કે બંને પક્ષ સહમત છે; તે એ વિશે કંઈ કહેતી નથી કે વર્કલોડ કયા સરનામા પર પહોંચી શકાય છે, કે તેનો ખાનગી રૂટ પૂર્ણ છે કે નહીં.
બીજી બાજુએ વાસ્તવિક ક્લાયન્ટ સાથે ચકાસો: નામ રિઝોલ્વ કરો, તે આંતરિક સરનામું પરત આપે છે તેની ખાતરી કરો, કનેક્ટ કરો અને પરત ટ્રાફિક તપાસો. Compute Engine IP સરનામા દસ્તાવેજીકરણ એ ઉપર વપરાયેલા આંતરિક-વિરુદ્ધ-બાહ્ય ભેદનો સંદર્ભ છે.