AWS Client VPN સ્પ્લિટ ટનલ: કયા રૂટ્સ પ્રકાશિત કરવા જોઈએ

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

સ્પ્લિટ-ટનલ ફ્લેગ એ ગંતવ્યોની યાદી નથી

AWS સ્પ્લિટ ટનલને કનેક્શન સ્થાપિત થતાં ક્લાઇન્ટના રૂટ ટેબલમાં એન્ડપોઇન્ટ રૂટ્સ ઉમેરવા તરીકે વર્ણવે છે. ખાનગી VPC માટેનો રૂટ ટનલને એ ગંતવ્ય સુધી મર્યાદિત કરે છે; બાકીનું બધું ક્લાઇન્ટના સામાન્ય માર્ગને અનુસરે છે. ડિફોલ્ટ રૂટ અલગ અસર ધરાવતી અલગ સૂચના છે, તેથી જ સ્પ્લિટ-ટનલ દસ્તાવેજીકરણ આ મોડ માટે ગોઠવાયેલા એન્ડપોઇન્ટ પર 0.0.0.0/0 પ્રકાશિત કરવા સામે ચેતવે છે: તે કનેક્ટિવિટી વિસ્તારવાને બદલે સામાન્ય રીતે તોડે છે. એન્ડપોઇન્ટ રૂટ ટેબલ એ નીતિ છે, અને ક્લાઇન્ટ રૂટ ટેબલ એ પરિણામ છે જે તમે તપાસી શકો છો.

એન્ડપોઇન્ટ રૂટ ટેબલ અને ક્લાઇન્ટના ઇન્સ્ટોલ કરેલા રૂટ્સ સાથે મળીને વાંચો. લેબલ ઇરાદો વર્ણવે છે; રૂટ્સ શું થાય છે તે વર્ણવે છે.

પ્રથમ નિર્ણય: સામાન્ય ઇન્ટરનેટ ટ્રાફિક સ્થાનિક રહેવો જોઈએ?

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

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

બીજો નિર્ણય: કયા ખાનગી પ્રીફિક્સ, કોના અધિકારથી?

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

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

જ્યારે ગંતવ્ય નામથી પહોંચી શકાય એવું હોવું જોઈએ, ત્યારે ધ્યાનમાં રાખો કે આગળનો પ્રશ્ન નામ રિઝોલ્યુશનનો છે, રૂટનો નથી.

ત્રીજો નિર્ણય: કયો રિઝોલ્વર ટનલને અનુસરે છે?

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

જાહેર નામો કનેક્શન પહેલાંની જેમ રિઝોલ્વ થવા જોઈએ, જે તમે શું પ્રકાશિત કરો છો તે અંગે સચોટ રહેવાનું બીજું કારણ છે.

રૂટ સેટ બદલો, પછી બંને દુનિયા ચકાસો

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

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

રૂટ યાદી તર્કની બાજુમાં રનબુકમાં લખો, જેથી આગલી વ્યક્તિ ઇરાદાપૂર્વકનું બાકાત અને ભૂલી ગયેલા બાકાત વચ્ચે ભેદ કરી શકે.