AWS Client VPN DNS: સબનેટ નહીં, VPC રિઝોલ્વર વાપરો

એન્ડપોઇન્ટ 10.0.8.0/24 માં છે, તેથી રિઝોલ્વર 10.0.8.2 હોવું જોઈએ. આ તર્ક હું સૌથી વધુ સાંભળું છું અને તે બે વાર ખોટો છે. Route 53 Resolver પ્રાથમિક VPC IPv4 શ્રેણી વત્તા બે પર જવાબ આપે છે, જે 10.0.0.0/16 ના VPC માટે 10.0.0.2 છે, એન્ડપોઇન્ટ કઈ સબનેટ વાપરે તે ધ્યાનમાં ન લેતાં. બીજી ભૂલ વધુ શાંત છે: એન્ડપોઇન્ટમાં સાચું સરનામું મૂકવાનો અર્થ એ નથી કે ક્લાયન્ટની ઓપરેટિંગ સિસ્ટમ ક્યારેય તેને કંઈ પૂછે. બંને ભૂલો એક જ લક્ષણ આપે છે: નામ રિઝોલ્યુશન કેટલાક ક્લાયન્ટમાં કામ કરે છે અને બીજામાં નિષ્ફળ જાય છે.

દંતકથા સબનેટ સંલગ્નતાથી શરૂ થાય છે

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

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

પ્રાથમિક VPC શ્રેણીમાંથી સરનામું ગણો

VPC નું પ્રાથમિક IPv4 CIDR લો અને નેટવર્ક સરનામામાં બે ઉમેરો. 10.0.0.0/16 10.0.0.2 આપે છે, 172.31.0.0/16 172.31.0.2 આપે છે, અને ગૌણ શ્રેણી ધરાવતું VPC રિઝોલ્વરને પ્રાથમિક પર જ રાખે છે. તે VPC ની અંદરની 10.0.8.0/24 સબનેટ તેને ખસેડતી નથી. એન્ડપોઇન્ટને સ્પર્શ કરો તે પહેલાં VPC ID ની બાજુમાં સરનામું લખો, કારણ કે આ સંખ્યા VPC ની લાક્ષણિકતા છે, કનેક્શનની નહીં.

VPC લિંક-લોકલ સરનામા 169.254.169.253 પર પણ જવાબ આપે છે. આ સરનામું VPC ની અંદરથી પહોંચી શકાય છે, પરંતુ ટનલની બીજી બાજુના લેપટોપ માટે તે સામાન્ય રૂટ કરેલું ગંતવ્ય નથી.

એટલે બે માન્ય રિઝોલ્વર સરનામાં છે, અને તેમાંથી એક પણ સબનેટ વત્તા બે નથી.

એન્ડપોઇન્ટ સેટિંગ શું કરે છે અને શું નહીં

Client VPN એન્ડપોઇન્ટમાં DNS સર્વર ફીલ્ડ હોય છે, અને જ્યાં કન્સોલ VPC રિઝોલ્વર વિકલ્પ આપે છે ત્યાં એ જ વિચાર ભરે છે. તેમને સેટ કરવાથી કનેક્શન સ્થાપિત થતી વખતે સેવા ક્લાયન્ટને શું આપે છે તે બદલાય છે. તે અનમેનેજ્ડ OpenVPN ક્લાયન્ટ એ મૂલ્ય સાથે શું કરે તે બદલતું નથી, કારણ કે ક્લાયન્ટે તેને ઓપરેટિંગ સિસ્ટમ પર લાગુ કરવું પડે છે. આ જ ખાલીપણામાંથી «મારા Mac પર કામ કરે છે પણ Linux બોક્સ પર નહીં» આવે છે.

Linux માં રિઝોલ્વર એકીકરણ કનેક્શન મેનેજરની માલિકીનું છે, વપરાશકર્તાનું નહીં. /etc/resolv.conf જાતે સંપાદિત કરવાથી સાબિત થાય છે કે સરનામું એક સેશન માટે કામ કરે છે અને પછી ફરી જોડાવા પર અદૃશ્ય થઈ જાય છે — એટલે ઘણા સુધારેલા કિસ્સા બીજા દિવસે સવારે પાછા આવે છે.

કનેક્ટ થયા પછી ક્લાયન્ટ પર સક્રિય રિઝોલ્વર તપાસો, એન્ડપોઇન્ટનું કન્ફિગરેશન પેજ નહીં.

સ્પ્લિટ ટનલિંગ સાચા રિઝોલ્વરને હરાવી શકે છે

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

ઓવરલેપ થતી સ્થાનિક શ્રેણીઓ એ જ પરિણામ વધુ ખરાબ રીતે આપે છે: ક્વેરીનો જવાબ મળે છે, ફક્ત ખોટા સર્વરથી.

Amazon DNS સરનામા માટે સિક્યોરિટી ગ્રુપ ખોલશો નહીં

શોધો ટાઇમ આઉટ થાય ત્યારે સહજ વૃત્તિ રિઝોલ્વર સરનામા પર UDP 53 ની મંજૂરી આપતો નિયમ ઉમેરવાની હોય છે. AWS દસ્તાવેજ કરે છે કે સિક્યોરિટી ગ્રુપ અને નેટવર્ક ACL Amazon DNS ટ્રાફિકને એ રીતે ફિલ્ટર કરતા નથી જે રીતે કસ્ટમ DNS ઇન્સ્ટન્સ તરફના ટ્રાફિકને કરે છે. એ નિયમો ખોલવાથી VPC રિઝોલ્વર માટે કંઈ બદલાતું નથી અને સીમા વગર કારણે વિસ્તરે છે. તમે જાતે ચલાવો છો તે રિઝોલ્વર અલગ કિસ્સો છે અને તેને ખરેખર પોતાના નિયમોની જરૂર છે.

જો તમારા ડિઝાઇનમાં બંને હાજર હોય, તો કોઈ નિયમ સંપાદિત કરતા પહેલાં તપાસો કે ક્લાયન્ટ ખરેખર કયા તરફ નિર્દેશિત છે.

માર્ગ ચકાસો, પછી બીજું કંઈક માપો

એક જાહેર નામ રિઝોલ્વ કરો, VPC સાથે સંકળાયેલા ખાનગી હોસ્ટેડ ઝોનમાં નોંધાયેલું ખાનગી નામ રિઝોલ્વ કરો, અને બંને વચ્ચે ક્લાયન્ટનું સક્રિય રિઝોલ્વર વાંચો. આ ક્રમ «રિઝોલ્વર સરનામું ખોટું છે» ને «ઝોન સંકળાયેલો નથી» અને «ક્લાયન્ટે સેટિંગ અવગણ્યું» થી અલગ કરે છે. દરેકનો ઉપાય અલગ છે, અને એક પણ થ્રુપુટ સમસ્યા નથી.

સફળ શોધ ટકાઉ ટ્રાન્સફર ઝડપ વિશે કંઈ કહેતી નથી, તેથી રિપોર્ટ કરતી વખતે આ બે વાતચીત અલગ રાખો.