સ્રોત/ગંતવ્ય તપાસ એક દરવાજો છે, આખો VPN માર્ગ નહીં

VPN એક EC2 ઇન્સ્ટન્સ પર સમાપ્ત થાય છે, તમે તે ઇન્સ્ટન્સના ટનલ સરનામા સુધી પહોંચી શકો છો, અને બીજા ખાનગી હોસ્ટ તરફ તેમાંથી પસાર થવાનો ટ્રાફિક અદૃશ્ય થઈ જાય છે. આ બે અલગ પરીક્ષણો છે, અને તેમને ભેગા કરવાથી કલાકો બગડે છે. પ્રથમ પૂછે છે કે તમે ઇન્સ્ટન્સ સુધી પહોંચી શકો છો કે નહીં; બીજું માગે છે કે તે એવા ગંતવ્ય માટે ટ્રાફિક ફોરવર્ડ કરે જે તેનું પોતાનું નથી, જેના માટે Linux ફોરવર્ડિંગ, ફાયરવોલ નીતિ, દૂરના બાજુ પર રૂટ અને AWS સ્તરની પરવાનગી જરૂરી છે, જેનો અતિથિ ઓપરેટિંગ સિસ્ટમ સાથે કોઈ સંબંધ નથી. કન્સોલમાં કંઈ પણ તે તફાવત તરફ ધ્યાન ખેંચતું નથી. લક્ષણ રૂટિંગ ખામી જેવું લાગે છે, અને સામાન્ય રીતે તે નથી હોતું.

કંઈપણ બદલતા પહેલા બે પરીક્ષણો અલગ કરો

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

ગેટવે તરફ કામ કરતો ping અને તેની પેલે પારના હોસ્ટ તરફ નિષ્ફળ જતો ping એ કોઈ વચ્ચે વચ્ચે આવતી સમસ્યા નથી. તે એવા ઇન્સ્ટન્સનું અપેક્ષિત વર્તન છે જેને કહેવામાં આવ્યું નથી કે તે ફોરવર્ડ કરી શકે છે.

કોઈ સેટિંગને અડકતા પહેલા માર્ગ લખી લો

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

પછી સ્રોત/ગંતવ્ય તપાસની સેટિંગ ખરેખર ફોરવર્ડિંગ ઘટક પર તપાસો, VPCના દરેક ઇન્સ્ટન્સ પર નહીં. AWS દસ્તાવેજીકરણ કરે છે કે અન્ય લોકો માટે ટ્રાફિક ફોરવર્ડ કરતા ઇન્સ્ટન્સને તે તપાસ બંધ રાખવી કેમ જરૂરી છે, અને એ પણ કે સેટિંગ VPC-વ્યાપી ડિફોલ્ટ નહીં પણ દરેક ઇન્સ્ટન્સનો નિર્ણય કેમ છે.

ચાર સીમાઓ, અને તપાસ તેમાંની ફક્ત એક છે

માર્ગને ચાર પ્રશ્નો તરીકે લો અને ક્રમમાં તેમના જવાબ આપો. પહેલો નિષ્ફળ જતો જવાબ એ જગ્યા છે જ્યાં કામ છે, અને બાકીનામાંથી કોઈ તેની ભરપાઈ કરશે નહીં.

ક્રમ મહત્વનો છે કારણ કે તપાસવું સસ્તું છે: રૂટ્સ એક પાના પર દેખાય છે, તપાસ એક જ લક્ષણ છે, અને ગંતવ્યનો અભિપ્રાય સામાન્ય રીતે કોઈ સૌથી છેલ્લે પૂછે છે તે વસ્તુ છે.

અનુવાદ બદલે છે કે ગંતવ્ય કયો સ્રોત જુએ છે

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

જો તમે અનુવાદ કરો છો, તો નિયમને ક્લાયન્ટ પ્રીફિક્સ અને ઉદ્દેશ્ય ગંતવ્ય સુધી મર્યાદિત કરો. જો જાળવી રાખો છો, તો ખાતરી કરો કે દૂરની બાજુ ખરેખર રૂટ જાણે છે, તે શીખી લેશે એમ ધારી ન લો.

મૂળ ક્લાયન્ટમાંથી પરીક્ષણ કરો, પછી ફેરફાર રાખો

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

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