AWS Client VPN એન્ડપોઇન્ટ DNS: રિઝોલ્વ કરેલ IP પિન કરવું કેમ નિષ્ફળ જાય છે
AWS Client VPN એન્ડપોઇન્ટનું નામ તમે રિઝોલ્વ કરેલ સરનામાથી બદલો અને ટનલ પછી કામ કરવાનું બંધ કરશે. એક્સપોર્ટ કરેલ નામ અને તેનું રેન્ડમ પ્રીફિક્સ રાખો.
ગયા અઠવાડિયે dig +short એ તમારી AWS Client VPN પ્રોફાઇલમાં એન્ડપોઇન્ટ નામ માટે એક સરનામું આપ્યું, અને ટનલ જોડાઈ. આ અઠવાડિયે એ જ પ્રોફાઇલ તમારા લેપટોપ પર 'Connecting' પર બેસી રહી છે જ્યારે સહકર્મીની અસ્પૃષ્ટ નકલ હજુ કામ કરે છે. કંઈ બ્લોક થયું નથી અને સર્ટિફિકેટ સમાપ્ત થયું નથી. કોઈએ એન્ડપોઇન્ટ હોસ્ટનામને એ રિઝોલ્વ કરેલ સરનામાથી બદલી નાખ્યું, અને સેવા હવે ત્યાં જવાબ આપતી નથી. એક્સપોર્ટ કરેલ નામ એ ભાગ છે જે આ ફેરફાર સહન કરવા માટે બનાવાયો છે.
તમારી પ્રોફાઇલનું નામ એ નામ ન પણ હોય જેની પૂછપરછ થાય છે
Client VPN માંથી એક્સપોર્ટ કરેલ પ્રોફાઇલમાં સામાન્ય રીતે remote-random-hostname હોય છે. એ વિકલ્પ ચાલુ હોય ત્યારે ક્લાયન્ટ એક વપરાશી લેબલ બનાવે છે, તેને બિંદુ વડે એન્ડપોઇન્ટ નામ સાથે જોડે છે અને સંયુક્ત નામ રિઝોલ્વ કરે છે. એન્ડપોઇન્ટના ઝોનમાંનો વાઇલ્ડકાર્ડ રેકોર્ડ કોઈપણ લેબલનો જવાબ આપે છે, તેથી બનાવેલ પ્રીફિક્સ પણ રિઝોલ્વ થાય છે અને તેથી જાતે ક્વેરી ફરી બનાવવાનો પ્રયાસ કરો ત્યારે આ યુક્તિ અદ્રશ્ય રહે છે.
તેથી જ્યારે તમે ટર્મિનલમાં એન્ડપોઇન્ટ નામ પેસ્ટ કરો છો અને જવાબ મેળવો છો, ત્યારે તમે ક્લાયન્ટ જોડાણ સમયે વાપરે છે તે નામ કરતાં અલગ નામ રિઝોલ્વ કર્યું છે. એ અસંગતિ પ્રોફાઇલમાં સુધારવાની ખામી નથી. લેબલ જાણી જોઈને ફરી બનાવાય છે: વિકલ્પ કેશને જૂનો જવાબ રાખતા અટકાવે છે, અને તે ક્યારેય તમારી મશીન કે સેશન ઓળખતું નથી.
મને એ સુસંગતતાનો કિસ્સો મળ્યો છે જ્યાં ક્લાયન્ટ વિકલ્પને સંપૂર્ણ અવગણે છે. AWS ઉપાયનું દસ્તાવેજીકરણ કરે છે: સાચું એન્ડપોઇન્ટ નામ રાખો અને આગળ રેન્ડમ સ્ટ્રિંગ અને બિંદુ ઉમેરો, તેને પેસ્ટ કરવાના મૂલ્ય તરીકે નહીં પણ નામકરણ પેટર્ન તરીકે ગણો. જૂના ક્લાયન્ટ પર તે લાગુ કરવું વાજબી છે; પ્રીફિક્સવાળી સ્ટ્રિંગને એન્ડપોઇન્ટ તરીકે હાર્ડકોડ કરવું નહીં.
સાચવેલો જવાબ કેમ સાચો રહી શકતો નથી
Client VPN એન્ડપોઇન્ટ સરનામાં AWS સંભાળે છે અને સમય સાથે બદલાય છે, જે શ્રેષ્ઠ પ્રથાઓનું દસ્તાવેજ સ્પષ્ટ કહે છે. પકડાયેલો જવાબ એક રિઝોલ્યુશનનો સ્નેપશોટ છે. તેને હાર્ડકોડ કરતી પ્રોફાઇલ સેવા ખસે કે તરત જ નિવૃત્ત હોસ્ટ તરફ નિર્દેશિત પ્રોફાઇલ બની જાય છે, અને નિષ્ફળતા ભાગ્યે જ DNS જેવી લાગે છે: તમને કનેક્શન ટાઇમઆઉટ કે અટકેલું હેન્ડશેક મળે છે, તેથી લોકો રૂટિંગ અને સર્ટિફિકેટ પાછળ દોડે છે.
/etc/hosts માં એ જ જવાબ એ જ સમાપ્તિ અને વધારાની સમસ્યા વારસામાં લે છે. hosts એન્ટ્રી રીબૂટ, ફરી એક્સપોર્ટ અને 'ક્લાયન્ટ ફરી ઇન્સ્ટોલ કરો' સુધારાઓમાં ટકી રહે છે, તેથી સરનામું ખસે ત્યારે નિષ્ફળતા પાછી આવે છે. મેં એકને અઠવાડિયાં સુધી નિરુપદ્રવ બેઠેલી જોઈ, પછી તેને વહન કરતા દરેક મશીનને નિષ્ક્રિય કરતી જોઈ, જ્યારે નવી ઇન્સ્ટોલ્સ સામાન્ય રીતે જોડાતી હતી. એ વિભાજન, એક જૂથ નિષ્ફળ અને બીજું એ જ ખાતામાં ઠીક, તમને મળતો સૌથી સસ્તો સંકેત છે.
રેન્ડમાઇઝેશનનો વ્યાપ પણ યોગ્ય રીતે નક્કી કરો. તે દરેક કનેક્શન પ્રયાસ દીઠ થાય છે. સ્થાપિત ટનલ તેના એન્ડપોઇન્ટને ફરી રિઝોલ્વ કરતું નથી, સેશન વચ્ચે સર્વર બદલતું નથી, અને વ્યક્તિગત એપ્લિકેશન વિનંતીઓ દરેક નવો VPN હોસ્ટ પસંદ કરતી નથી. ફક્ત આગલો પ્રયાસ ફરી રિઝોલ્વ કરે છે, તેથી આખી બપોર ચાલતું સેશન આવતીકાલની સવાર વિશે કંઈ કહેતું નથી.
ટનલ ઉપર આવે ત્યારે સેવા શું ચકાસે છે
Client VPN માંગે છે કે તમે જે સરનામા સાથે જોડાયેલા છો તે એન્ડપોઇન્ટના DNS નામ માટે રિઝોલ્વ થયેલા સરનામા સાથે મેળ ખાય. એ એક જ શરત અસંબંધિત લાગતી કેટલીક નિષ્ફળતાઓ સમજાવે છે: બીજે ક્યાંક નિર્દેશિત કસ્ટમ DNS રેકોર્ડ, સાચા એન્ડપોઇન્ટ સરનામા તરફ ફોરવર્ડ કરતું કસ્ટમ ફ્રન્ટએન્ડ, અને કાચા સરનામા પર ફરી લખાયેલી પ્રોફાઇલ. AWS કસ્ટમ-રેકોર્ડ-પ્લસ-ફોરવર્ડિંગ ગોઠવણને તાજેતરના AWS ક્લાયન્ટ સાથે નિષ્ફળતા તરીકે દસ્તાવેજીકરણ કરે છે. તપાસ સાંકડી છે; તે એ ચુકાદો નથી કે દરેક ઉપનામ પ્રતિબંધિત છે.
તે VPN પ્રોટોકોલ વિશેનો સામાન્ય નિયમ પણ નથી. સંખ્યાત્મક remote સામાન્ય OpenVPN ડિપ્લોયમેન્ટમાં સંપૂર્ણ માન્ય છે, અને ઘણા એ રીતે ચાલે છે. મર્યાદા સંચાલિત ગોઠવણમાંથી આવે છે, તેની નીચેના પ્રોટોકોલમાંથી નહીં.
જે સર્ટિફિકેટ ચકાસણી હળવી કરવાને ખોટો પ્રતિક્રિયા બનાવે છે. સરનામું બદલાયા પછી પ્રોફાઇલ નિષ્ફળ જાય તો સર્વર ચકાસણી બંધ કરવાથી રિઝોલ્યુશન કે સરનામા-મેળની શરત સુધારવાને બદલે ભૂલ ખસે છે, અને કંઈપણ પર ભરોસો કરતું ક્લાયન્ટ છોડી દે છે. એક્સપોર્ટ કરેલ CA, સર્વર ચકાસણી અને પરસ્પર પ્રમાણીકરણ સેટિંગ્સ જેમ આવ્યા તેમ જ રાખો.
મંજૂરી યાદી, ઇગ્રેસ અને ખાનગી DNS ત્રણ અલગ સમસ્યાઓ છે
લેપટોપ જોડાય તે પહેલાં ગંતવ્યને મંજૂરી આપવી પડે એવો ફાયરવોલ નિયમ બાહ્ય શ્રોતા વિશે છે. નેટવર્ક માલિકને એન્ડપોઇન્ટ નામ, ટ્રાન્સપોર્ટ અને ગોઠવેલ પોર્ટ આપો, પછી પૂછો કે તેમનું નિયંત્રણ સેવાના DNS વર્તનને અનુસરી શકે છે કે નહીં. એક પકડાયેલું સરનામું રાખતો નિયમ અલિખિત સમાપ્તિવાળો સ્નેપશોટ છે. જો નિયંત્રણ ફક્ત અપરિવર્તનીય ગંતવ્યો સ્વીકારે, તો રોલઆઉટ પહેલાં એ અંતર પૂરો કરો, ચૂપચાપ જવાબ હાર્ડકોડ કરવાને બદલે.
ટનલ ઉપર આવ્યા પછીની વિનંતીઓ માટે નિશ્ચિત સ્રોત સરનામું જોઈતા ભાગીદારની જરૂરિયાત અલગ છે: ઇગ્રેસ. વેબસાઇટ શું જુએ છે તે એપ્લિકેશન રૂટ અને સ્પ્લિટ-ટનલ નીતિ પર આધાર રાખે છે, ક્લાયન્ટ જે સરનામા સાથે જોડાયું તેના પર નહીં. સ્પ્લિટ-ટનલ ટ્રાફિક AWS ને જરાય સ્પર્શે નહીં.
ટનલની અંદરનું ખાનગી DNS ત્રીજું સ્તર છે. ક્લાયન્ટને આપેલો રિઝોલ્વર જોડાણ પછી આંતરિક નામોનો જવાબ આપે છે; ટનલ અસ્તિત્વમાં આવે તે પહેલાં તે જાહેર એન્ડપોઇન્ટ રિઝોલ્વ કરી શકતું નથી. એન્ડપોઇન્ટ રિઝોલ્યુશન નિષ્ફળતા અને આંતરિક એપ્લિકેશન રિઝોલ્યુશન નિષ્ફળતા જુદા જુદા તબક્કે થાય છે, અને તેમને ભેગા કરવાથી તમે ખોટા લોગ પર જાઓ છો.
સરનામા કુટુંબ એ જ યાદીમાં આવે છે. IPv4 જવાબ IPv6 કે ડ્યુઅલ-સ્ટેક એન્ડપોઇન્ટના માન્ય માર્ગ વિશે કંઈ કહેતો નથી, તેથી એક કુટુંબમાં લીધેલો સ્નેપશોટ બીજા માટે પુરાવો નથી.
કંઈ પિન કર્યા વિના કનેક્શન ચકાસો
જેમ એક્સપોર્ટ થઈ તેમ પ્રોફાઇલથી શરૂ કરો અને તે ખરેખર શું માંગે છે તે વાંચો:
grep -nE '^remote|remote-random-hostname' profile.ovpn
dig +short cvpn-endpoint-ID.prod.clientvpn.REGION.amazonaws.com
ss -tnp | grep -E ':(443|1194)'પછી ત્રણ વસ્તુઓની તુલના કરો: પ્રોફાઇલમાં રહેલું એન્ડપોઇન્ટ નામ, નવા પ્રયાસ માટે ક્લાયન્ટ જે સરનામું જણાવે છે, અને નામ અત્યારે શું રિઝોલ્વ થાય છે. રિઝોલ્વ થતું નામ ફક્ત એટલું પુરવાર કરે છે કે રેકોર્ડ જવાબ આપે છે; ટ્રાન્સપોર્ટ અને પ્રમાણીકરણ અલગ છે, અને એન્ડપોઇન્ટને ping નો જવાબ આપવાની જરૂર નથી. મધ્યમ મુદ્દા માટે ક્લાયન્ટનો પોતાનો લોગ એકમાત્ર સ્રોત છે, તેથી તેને પ્રયાસ દરમિયાન કેપ્ચર કરો, પછી નહીં.
| What you see | Usual cause | Next check |
|---|---|---|
| One machine fails, others connect | Pinned address or stale hosts entry on that machine | Diff its profile and hosts file against a working copy |
| Everyone fails at once, no config change | The endpoint address rotated | Confirm the current endpoint configuration with the account owner |
| Tunnel up, internal names fail | Client DNS policy, not endpoint resolution | Inspect the resolver pushed after connection |
આજે જવાબ આપતું સરનામું આજ વિશેનો પુરાવો છે; નામ એ વસ્તુ છે જે સેવા માન્ય રાખે છે. અવલોકન નોંધો, એન્ડપોઇન્ટનો માલિક જે હોય તેને મોકલો, અને પ્રોફાઇલને નામ તરફ નિર્દેશિત રાખો.
બે આદતો છોડો: અટકેલા હેન્ડશેકને પાર કરવા સર્ટિફિકેટ ચકાસણી બંધ કરવી, અને એક ચોંટી જશે એવી આશાએ એન્ડપોઇન્ટ નામ સામે લેબલો થપ્પો કરવા. લેબલ વાઇલ્ડકાર્ડ રેકોર્ડ દ્વારા રિઝોલ્વ થાય છે અથવા સમસ્યા બીજે ક્યાંક છે. યોગ્ય રીતે ગોઠવેલી પ્રોફાઇલ છતાં નિષ્ફળ જાય, તો લાંબુ હોસ્ટનામ નહીં, સચોટ ક્વેરી અને કનેક્શન ઘટના મોકલો.
બંધ કરતાં પહેલાં: પ્રોફાઇલમાં હજુ એક્સપોર્ટ કરેલ એન્ડપોઇન્ટ નામ છે, કોઈ hosts ફાઇલ સરનામું પિન કરતી નથી, ક્લાયન્ટ લોગનું remote વર્તમાન રિઝોલ્યુશન સાથે મેળ ખાય છે, અને ફાયરવોલ નિયમ સરનામાને બદલે એન્ડપોઇન્ટનું નામ કહે છે. આ જ સ્થિતિ આગલી વ્યક્તિને સોંપવાની છે.