ખાનગી DNS VPC માં કામ કરે છે પણ VPN પર નહીં
EC2 ની અંદર ઉકેલાતું પણ VPN પર ન ઉકેલાતું ખાનગી નામ resolver માર્ગની સમસ્યા છે. ઝોન રેકોર્ડ બદલતા પહેલાં નિષ્ફળતાનો આકાર વાંચો.
એક ખાનગી નામ EC2 ઇન્સ્ટન્સમાંથી ઉકેલાય છે પણ VPN દ્વારા જોડાયેલા લેપટોપમાંથી નહીં, અને ઝોન કન્સોલમાં સાચું દેખાય છે. પહેલી વૃત્તિ રેકોર્ડ સંપાદિત કરવાની હોય છે, જે લગભગ કદી સમસ્યા નથી હોતી. રેકોર્ડ કોઈને જવાબ આપી રહ્યો છે; ફક્ત તમારા લેપટોપને જવાબ આપી રહ્યો નથી. બંને કૉલર વચ્ચેનો ફરક એ છે કે તેઓ કયા resolver ને પૂછે છે અને તે resolver નો VPC ના DNS દૃશ્ય સુધી સમર્થિત માર્ગ છે કે નહીં.
રેકોર્ડ અસ્તિત્વમાં છે તે સાબિત કરીને શરૂ કરું છું, પછી બાકીનો સમય ક્વેરી માર્ગ પર ગાળું છું. આ અલગ સિસ્ટમો છે અને અલગ રીતે નિષ્ફળ જાય છે.
કંઈપણ બદલતા પહેલાં નિષ્ફળતાનો આકાર વાંચો
ત્રણ પરિણામો ત્રણ અલગ વસ્તુઓ દર્શાવે છે, અને એક ક્વેરી તેમને અલગ પાડે છે: ક્લાયન્ટ ખરેખર જે resolver વાપરે છે તેની સામે નામ માટે dig ચલાવો.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
સમય પૂરો થવો એ નેટવર્ક વિશેનું નિવેદન છે. NXDOMAIN એ DNS દૃશ્ય વિશેનું નિવેદન છે. જાહેર જવાબ એ નીતિ વિશેનું નિવેદન છે. સમય પૂરો થતો હોય ત્યારે ઝોન રેકોર્ડ સંપાદિત કરવો કેસનો એકમાત્ર ઉપયોગી પુરાવો ફેંકી દે છે.
VPC નું પ્લસ-બે સરનામું દૂરનું resolver કેમ નથી
CIDR પ્લસ-બે સરનામું VPC ની અંદરના સંસાધનો માટે સ્થાનિક સેવા છે. AWS દસ્તાવેજ કરે છે કે સ્થાનિક નેટવર્કમાંથી, અથવા બીજા VPC ના DNS સર્વરમાંથી, ક્વેરી સીધી તે સરનામા પર મોકલવી સમર્થિત નથી અને અસ્થિર પરિણામ આપી શકે છે.
એનો અર્થ એ નથી કે પ્રયોગ કદી કામ કરતો દેખાતો નથી. એનો અર્થ એ છે કે વર્તન એવો કરાર નથી જે હેલ્પડેસ્ક સ્ક્રિપ્ટમાં મૂકી શકાય. સમર્થિત દિશા એ ઇનબાઉન્ડ Resolver એન્ડપોઇન્ટ છે: તમારા VPC ની અંદર સરનામાંની જોડી, તમારા નિયંત્રિત નેટવર્કથી પહોંચી શકાય તેવી, જે AWS ની બહારથી આવતી ક્વેરી સ્વીકારે છે.
માર્ગ એ ક્રમમાં બનાવો જેમાં તે સ્વચ્છ રીતે નિષ્ફળ જાય છે
ત્રણ હોપ હોવા જોઈએ, અને દરેકની નિષ્ફળ થવાની પોતાની રીત છે.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesફોરવર્ડરને VPN દ્વારા એન્ડપોઇન્ટ સરનામાં સુધી માર્ગ જોઈએ, અને પરત માર્ગ પણ કામ કરવો જોઈએ. પોર્ટ 53 પર પરંપરાગત DNS માટે એન્ડપોઇન્ટ UDP અને TCP પર જવાબ આપે છે, તેથી બંને પ્રોટોકોલની પરવાનગી હોવી જોઈએ અને બંનેને વચ્ચેની કોઈપણ સ્ટેટફુલ તપાસમાંથી પસાર થવું પડે છે.
પછી DNS દૃશ્ય અલગ તપાસો. ખાનગી હોસ્ટ કરેલો ઝોન ફક્ત તે VPC ને દેખાય છે જેની સાથે તે જોડાયેલો છે, અથવા જાણી જોઈને કરેલી શેરિંગ વ્યવસ્થા દ્વારા. પહોંચી શકાય તેવો એન્ડપોઇન્ટ પોતાની જાતે દરેક ખાનગી ઝોનને તેના રિઝોલ્યુશન સંદર્ભમાં ઉકેલી શકાય તેવો બનાવતો નથી.
આઉટબાઉન્ડ એન્ડપોઇન્ટ વિરુદ્ધ દિશાની સેવા કરે છે અને તમારા લેપટોપથી આવતી ક્વેરીનો જવાબ આપશે નહીં.
બંને છેડેથી ચકાસો
ક્લાયન્ટથી ફોરવર્ડર સામે ક્વેરી કરો, પછી ફોરવર્ડરથી એન્ડપોઇન્ટ સામે. જો ક્લાયન્ટ નિષ્ફળ જાય અને ફોરવર્ડર સફળ થાય, તો અંતર તે બંને વચ્ચે છે.
જો બંને નિષ્ફળ જાય, તો એન્ડપોઇન્ટ પરની સુરક્ષા નીતિ અને તે ખરેખર જે સ્રોત સરનામું જુએ છે તે જુઓ. NAT પાછળનો ફોરવર્ડર લેપટોપના VPN સરનામાના બદલે NAT સરનામું રજૂ કરે છે, અને આ ફરક એકલો ક્વેરી પડતી મૂકવા માટે પૂરતો છે. જો બંને સફળ થાય પણ એપ્લિકેશન હજી નિષ્ફળ જાય, તો કદાચ એપ્લિકેશન તમે ચકાસ્યા તેના કરતાં અલગ resolver વાપરી રહી છે.
જાહેર અને ખાનગી નામસ્થાનો જાણી જોઈને અલગ રાખો. Split DNS એ નીતિ છે જે તમે ગોઠવો છો, એક શોધના સંયોગથી ડેટા પરત કરવાની આડઅસર નથી.
જે હું નહીં કરું
એક શોધ ચલાવનાર NAT નિયમ ઉમેરીને તેને ડિઝાઇન કહીશ નહીં.
એક પરીક્ષણે એક વાર રેકોર્ડ પરત કર્યો તે માટે હું દરેક દૂરના ક્લાયન્ટને પ્લસ-બે સરનામા તરફ વાળીશ નહીં. અને એક જ ફોરવર્ડરને પ્રવેશ જોઈએ ત્યારે એન્ડપોઇન્ટની સુરક્ષા નીતિને આખા VPN પૂલ સુધી નહીં વિસ્તારું. જો સંસ્થા પહેલેથી VPC ની અંદર મંજૂર ફોરવર્ડર ચલાવે છે, તો પહેલાં તે ડિઝાઇન વાંચો, કારણ કે તમે ઉમેરેલો બીજો એન્ડપોઇન્ટ એ જ છે જેને કોઈ દસ્તાવેજ કરતું નથી.