VPN ચાલુ અને localhost કામ કરવાનું બંધ: નામ, પ્રોક્સી કે બાઇન્ડ?
જ્યારે શોધ પ્રત્યય અથવા પ્રોક્સી નિયંત્રણ લે છે ત્યારે localhost તમારા મશીનનો અર્થ રહેતો નથી. પહેલા નામ સુધારો, પછી રૂટ, પછી સાધનની કનેક્શન સ્ટ્રિંગ.
તમારા ડેવલપમેન્ટ સર્વરે એક મિનિટ પહેલા જવાબ આપ્યો, અને હવે ટનલ ચાલુ હોવાથી વિનંતી એવા હોસ્ટ નામ સાથે સમય સમાપ્ત થાય છે જે તમે ક્યારેય લખ્યું નથી. લગભગ દરેક કિસ્સાને બે મિકેનિઝમ સમજાવે છે, અને બહારથી તે એકસરખા દેખાય છે. શોધ પ્રત્યય ટૂંકા નામને કોર્પોરેટ નામમાં ફેરવે છે, જ્યારે પ્રોક્સી લૂપબેક ટ્રાફિકને એવા હોસ્ટ પર મોકલે છે જે તેને પહોંચી શકતું નથી. બંનેને અલગ કરવા એક ક્વેરીનો ખર્ચ થાય છે અને તમે લખવા જઈ રહ્યા હતા તે ફાયરવોલ નિયમ બચે છે.
જ્યારે localhost કોર્પોરેટ ઝોનમાં ઉકેલાય છે
ટનલ ચાલુ હોય ત્યારે નામ કઈ બાજુ ઉકેલાય છે તે તપાસો, પછી ટનલ બંધ કરીને એ જ ક્વેરી ચલાવો અને બંને જવાબોની સરખામણી કરો. સંકેત એ છે કે જ્યાં તમે 127.0.0.1 ની અપેક્ષા રાખતા હતા ત્યાં કોર્પોરેટ શ્રેણીનું સરનામું મળે. localhost.mycompany.corp જેવું રેકોર્ડ ક્લાયન્ટ દ્વારા એ પ્રત્યય શોધ સૂચિમાં ઉમેરાતાં જ લૂપબેક એન્ટ્રી પર જીતે છે, અને વિનંતી એવા ખાનગી હોસ્ટ પર જાય છે જ્યાં એ પોર્ટ પર કંઈ સાંભળતું નથી. શોધ સૂચિ ધારવાને બદલે વાંચો, કારણ કે ક્લાયન્ટ એક કરતાં વધુ ડોમેન ઉમેરી શકે છે અને ક્રમ નક્કી કરે છે કે કયો ઉમેદવાર પહેલા અજમાવવો:
getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080
એપ્લિકેશન, ડેટાબેઝ ક્લાયન્ટ અથવા નોટબુક URL માં હોસ્ટ નામને શાબ્દિક સરનામાથી બદલો, પછી વિનંતીનું પુનરાવર્તન કરો. જો નિષ્ફળતા અદૃશ્ય થાય તો તમારી પાસે નામકરણની સમસ્યા હતી અને ટનલ ફક્ત ટ્રિગર હતી. જો ચાલુ રહે તો સાંભળનાર અથવા રૂટ આગળનો શંકાસ્પદ છે અને નામ ફક્ત ખોટો સુરાગ હતો.
લૂપબેક પકડતી પ્રોક્સી સેટિંગ્સ
ટનલ ઉપર આવે ત્યારે લાગુ થતી સિસ્ટમ પ્રોક્સી 127.0.0.1 માટેની વિનંતી સ્વીકારશે અને તેને એવી દૂરની પ્રોક્સી પર મોકલશે જેને ખબર નથી કે તમારો અર્થ શું હતો. ખાલી બાયપાસ યાદી સ્થાનિક વિનંતીને દૂરની બનાવે છે, અને ભૂલ સંદેશ આવું ભાગ્યે જ કહે છે. લૂપબેક સરનામાં એક જ આદેશ માટે નહીં પણ આખા સત્ર માટે બાયપાસ યાદીમાં ઉમેરો, પછી નેટવર્ક વિશે કંઈ પણ નિષ્કર્ષ કાઢતાં પહેલાં ખાતરી કરો કે સાધન તેનું પાલન કરે છે.
એપ્લિકેશન ફ્રેમવર્ક તેમના પોતાના એન્વાયર્નમેન્ટ વેરિયેબલ્સ અને ક્યારેક તેમની પોતાની રૂપરેખા ફાઇલ વાંચે છે, તેથી એક સાધન માટે કામ કરતું બાયપાસ આગલા માટે કંઈ સાબિત કરતું નથી. બ્રાઉઝર એક વળાંક ઉમેરે છે: Chromium આધારિત બ્રાઉઝર લૂપબેક માટે પ્રોક્સીને ગર્ભિત રીતે બાયપાસ કરે છે, અને બાયપાસ ટોકન એ વર્તન દૂર કરી શકે છે. ઓપરેટિંગ સિસ્ટમનું સેટિંગ આખી વાર્તા છે એમ માનવાને બદલે અસરકારક પ્રોક્સી નિર્ણય તપાસો. શેલમાંથી શરૂ થતી કોઈપણ વસ્તુ માટે બે આદેશ આ નક્કી કરે છે:
curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool
બાઇન્ડ સરનામું નક્કી કરે છે કોણ જોડાઈ શકે
127.0.0.1 પર શરૂ થતું સર્વર ફક્ત તે મશીનથી જ કનેક્શન સ્વીકારે છે, જે સામાન્ય રીતે ડેવલપમેન્ટ માટે યોગ્ય ડિફોલ્ટ છે. 0.0.0.0 પરનું સર્વર દરેક ઇન્ટરફેસ પર જવાબ આપે છે, VPN એડેપ્ટર સહિત, જે મોટાભાગના લોકો ઇરાદો રાખે તેના કરતાં વધુ એક્સપોઝર છે. જ્યારે શાબ્દિક લૂપબેક સરનામું નિષ્ફળ જાય ત્યારે બીજા કંઈ પહેલાં બાઇન્ડ તપાસો.
સાંભળતા સોકેટ તરફ જુઓ અને જે સરનામા સાથે તે જોડાયેલું છે તે નોંધો, ફક્ત પોર્ટ નહીં. જો બીજા ઉપકરણ અથવા કન્ટેનરને ટનલ દ્વારા સેવા સુધી પહોંચવું હોય તો તે જે ચોક્કસ ઇન્ટરફેસ વાપરશે તેના પર બાઇન્ડ કરો અને એ પોર્ટને જાણી જોઈને મંજૂરી આપો. જો ફક્ત તમારા પોતાના મશીનને તેની જરૂર હોય તો સાંકડું બાઇન્ડ રાખો અને સર્વર વિસ્તારવાને બદલે ક્લાયન્ટ સુધારો. પોર્ટ ફોરવર્ડ અથવા ટનલ સ્તર બંનેને જોડી શકે છે, પણ દરેક એવો ઘટક ઉમેરે છે જેને પછી પોતાનું ડિબગિંગ જોઈશે.
જ્યાં ડિબગિંગ સાધન LAN ની અપેક્ષા રાખે છે
ડિબગિંગ સાધનો એવી ધારણાઓ લઈને ચાલે છે જે ટનલ શાંતિથી તોડે છે. ફોન ડિબગિંગ બ્રિજ પોતાનું ઉપકરણ ગુમાવે છે જ્યારે VPN ઉપકરણનું સબનેટ પકડે છે, તેથી LAN સરનામા અથવા કેબલ દ્વારા ફરી જોડાવું સંઘર્ષ ટાળે છે. બ્રાઉઝર ઓટોમેશન હબ સમય સમાપ્ત થાય છે જ્યારે હબ ફક્ત પ્રોક્સી દ્વારા પહોંચી શકાય છે, અથવા જ્યારે સ્થાનિક ફાયરવોલ તેનો કંટ્રોલ પોર્ટ પડી જવા દે છે. રિમોટ ડિબગર એલિવેશન અને લૂપબેક સરનામાની માંગ કરી શકે છે જ્યાં ક્લાયન્ટે રૂટ ફરીથી લખ્યો છે.
કંટ્રોલ પોર્ટ અને ડેટા પોર્ટ અલગ ઓળખો, કારણ કે ઘણી વાર એક ટકી જાય છે જ્યારે બીજો નહીં. પછી નક્કી કરો કે સુધારો સાધનની રૂપરેખામાં આવે છે, એ સબનેટ માટેના રૂટમાં, કે સ્પ્લિટ ટનલ નિયમમાં. દરેક ડેવલપર મશીન પર hosts ફાઇલ સંપાદિત કરવી સૌથી ખરાબ રીતે સ્કેલ થાય છે અને પહેલા ભૂલાય છે. એ સેટિંગને પસંદ કરો જે પ્રોફાઇલ સાથે રહે છે અને જેને ટનલ ધરાવનાર કોઈ પણ સમીક્ષા કરી શકે.
નિષ્ફળ થતા પહેલા તબક્કે થોભો
ત્રણ તબક્કામાં નીચે ઉતરો: નામ ઉકેલો, શાબ્દિક સરનામા માટે સોકેટ ખોલો, પછી સાધનને પોતાનું કનેક્શન બનાવવા દો. દરેક તબક્કો એક સ્તર દૂર કરે છે, તેથી પ્રથમ નિષ્ફળતા સુધારવાના સ્તરને નામ આપે છે અને તેના પછીનું બધું અપરીક્ષિત રહે છે. કંઈ પણ બદલતાં પહેલાં પરિણામ લખો, કારણ કે માપ પહેલાં લાગુ કરેલો સુધારો નસીબથી અલગ પડતો નથી. જો પ્રથમ પ્રયાસ નિષ્ફળ જાય અને પુનરાવર્તન કામ કરે, તો સાધન શરૂ થયું ત્યારે ટનલ કદાચ તૈયાર નહોતી.
સ્થિર પ્રતીક્ષાને રૂટની રાહ જોતી મર્યાદિત તૈયારી તપાસથી બદલો, અને નિષ્ફળ થતો તબક્કો લોગમાં રાખો જેથી આગલી વ્યક્તિ જોઈ શકે કે ક્યાં અટક્યું. પોતાની જાતે સ્વસ્થ થતું સાધન સુધારેલું નથી, તે નસીબદાર છે, અને નસીબ બીજા કોઈના મશીન પર ખતમ થાય છે. ટનલ સૌથી છેલ્લે બદલો, અને ફક્ત એ તબક્કા માટે જે ખરેખર નિષ્ફળ ગયો. એ ક્રમ પણ કામ કરતા બિલ્ડ તરફ પાછા જવાનો સૌથી ટૂંકો રસ્તો છે, કારણ કે તે તમને એવા ઘટકને ફરી બનાવવાથી રોકે છે જે ક્યારેય સામેલ નહોતો.