dnsmasq પોર્ટ 53 બાઇન્ડ કરી શકતું નથી: જે સોકેટ તેને ધરાવે છે તે શોધો

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

આ ક્રમમાં પાંચ પગલાં: ભૂલ ફરી ઉત્પન્ન કરો, લિસનર્સની યાદી બનાવો, wildcard સમજો, કામ સોંપો, પછી ચકાસો.

પગલું 1: ભૂલ ફરી ઉત્પન્ન કરો અને વાંચો

dnsmasq ને સેવા જે કન્ફિગરેશન વાપરે છે તે જ કન્ફિગરેશન સાથે ફોરગ્રાઉન્ડમાં શરૂ કરો, જેથી ભૂલ અનુમાન કરવા પડે એવા લોગને બદલે તમારા ટર્મિનલમાં દેખાય. સંદેશમાં સરનામા પરિવાર અને સ્થાનિક સરનામું ધ્યાનમાં લો. ચોક્કસ સરનામા પર બાઇન્ડ અને wildcard પર બાઇન્ડ એ જુદા જુદા માલિકો સાથેની જુદી જુદી નિષ્ફળતાઓ છે.

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

પગલું 2: માલિકોની યાદી બનાવો

પહેલા સોકેટ્સની યાદી બનાવો. સ્રોત પોર્ટ 53 પરનું ફિલ્ટર જોવાની સત્તા હોય ત્યારે બંને ટ્રાન્સપોર્ટ અને માલિક પ્રોસેસ બતાવે છે:

ss -lntup 'sport = :53'

આઉટપુટ કૉલમમાં વાંચો: ટ્રાન્સપોર્ટ, સ્થાનિક સરનામું, પોર્ટ, પ્રોસેસ. TCP લિસનર અને UDP લિસનર અલગ સોકેટ્સ છે, તેથી એક બંધ કરવાથી બીજું મુક્ત થતું નથી. wildcard સરનામું દરેક ઇન્ટરફેસને આવરી લે છે, એટલે કે VPN સરનામું પહેલેથી જ ધરાવાયેલું છે, ભલે કોઈ લીટી તેનું નામ ન લે. અને પ્રોસેસનું નામ જણાવે છે કે આ ડિસ્ટ્રિબ્યુશન-સંચાલિત રિઝોલ્વર છે, કન્ટેનર છે, કે અગાઉના પ્રયોગે ચાલુ રાખેલું કંઈક છે.

પગલું 3: wildcard ની જાળ

bind-interfaces વિકલ્પ નક્કી કરે છે કે dnsmasq wildcard સોકેટ બાઇન્ડ કરે છે કે દરેક કન્ફિગર કરેલા ઇન્ટરફેસ માટે એક સોકેટ, જેમ dnsmasq સંદર્ભ વર્ણવે છે. તેના વિના dnsmasq wildcard બાઇન્ડ કરીને તેના બદલે ઇન્ટરફેસ પ્રમાણે વિનંતીઓ ફિલ્ટર કરી શકે છે, જે બીજો ડેમન wildcard ધરાવે ત્યારે તરત જ નિષ્ફળ જાય છે. Linux bind-dynamic ઉમેરે છે, જે સ્ટાર્ટ પછી બનેલા ઇન્ટરફેસ સંભાળે છે, જે VPN ઇન્ટરફેસ ફક્ત કનેક્ટ વખતે દેખાય ત્યારે સાચી ચિંતા છે.

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

પગલું 4: કામ સોંપો

નક્કી કરો કે કયો ડેમન VPN ક્લાયન્ટ્સને જવાબ આપે છે અને કયો હોસ્ટને. ટનલ સરનામા પર સાંભળીને ઉપર તરફ ફોરવર્ડ કરતું એક રિઝોલ્વર સામાન્ય ગોઠવણી છે; બે રિઝોલ્વર જેમાંનું દરેક ધારે છે કે તે પોર્ટ 53 ધરાવે છે તે જરાય ગોઠવણી નથી.

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

પગલું 5: સોકેટ ચકાસો, પછી માર્ગ

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

અલગ રાખવા જેવા ત્રણ પરિણામ: સોકેટ છે, ક્લાયન્ટ તેને પહોંચે છે, જવાબ સાચો છે.

શું ન કરવું

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

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