OpenWrt પોલિસી રાઉટિંગ: જે ચેઇન સ્થાનિક DNS પકડે છે

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

બે ફ્લો, એક રિઝોલ્વર સરનામું

પહેલો ફ્લો એ છે જે લોકો કલ્પે છે. ક્લાયન્ટ રાઉટરના રિઝોલ્વરને પૂછે છે, રિઝોલ્વર ઉપર તરફ ફોરવર્ડ કરે છે, અને તે ફોરવર્ડ થયેલું પેકેટ બહાર જતાં રાઉટરમાંથી પસાર થાય છે. તે પેકેટ ફોરવર્ડ થયેલા ટ્રાફિકને જોતી કોઈપણ વસ્તુ માટે દૃશ્યમાન છે.

બીજો ફ્લો ક્યારેય ક્યાંથી આવતો નથી. રાઉટર તેને બનાવે છે, તેથી કોઈ આવનારું પેકેટ નથી અને મેળવવા માટે કોઈ ફોરવર્ડિંગ પગલું નથી.

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

ફોરવર્ડ થયેલા અને સ્થાનિક રીતે બનેલા પેકેટ અલગ રીતે પ્રવેશે છે

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

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

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

આઉટપુટ ચેઇન પસંદ કરો, પછી મેળ સાંકડો કરો

ઉપાય એ છે કે એ જ ઉદ્દેશ આઉટપુટ ચેઇન સાથે પણ જોડવો, અથવા જ્યારે રાઉટરની પોતાની ક્વેરી તમારા માટે મહત્વની હોય ત્યારે નિયમને ત્યાં ખસેડવો. પોલિસી રાઉટિંગ પેકેજ પર બનેલા OpenWrt સેટઅપમાં તેનો અર્થ છે નિયમની ચેઇન સેટિંગમાં preroutingને બદલે output પસંદ કરવું. બંને વસ્તીને આવરણની જરૂર હોય તો બંને નિયમ રાખો.

પછી નિયમ શું મેળવે છે તે સાંકડું કરો. રિઝોલ્વર ખરેખર જે પોર્ટ વાપરે છે તેના પરના ગંતવ્ય રિઝોલ્વર સરનામાં, રાઉટર જે બનાવે છે તે બધું ટનલમાં મોકલવા કરતાં ઘણો નાનો નિર્ણય છે.

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

ટનલનું પોતાનું ટ્રાન્સપોર્ટ નિયમની બહાર રાખો

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

મેનેજમેન્ટ ઍક્સેસ બીજો ભોગ છે. રાઉટરથી ઉદ્ભવતા વહીવટી સત્રો, અથવા તેમના જવાબો, વધુ પડતા પહોળા સ્થાનિક નિયમ દ્વારા ટનલમાં ખેંચાઈ શકે છે અને LANથી પહોંચી શકાય તેવા બની શકતા નથી.

ટનલના અંતિમ બિંદુને મેળમાંથી બાકાત રાખો, અને નિયમને રિઝોલ્વર સરનામાં સુધી મર્યાદિત રાખો. તે DNS જરૂરિયાત માટે પૂરતું છે અને તેના વિશે વિચારવા પૂરતું નાનું છે.

બંને વસ્તીની કસોટી કરો, એકની નહીં

રાઉટર પોતાની ક્વેરી કરે તે જુઓ અને નોંધો કે કયા ઇન્ટરફેસે તેને વહન કર્યું. LAN હોસ્ટથી લુકઅપનું પુનરાવર્તન કરો અને નોંધો કે તેણે કયો માર્ગ લીધો. પોલિસી નિયમોના કાઉન્ટર અનુમાન વિના બંને જવાબ દૃશ્યમાન કરે છે.

પરિણામોને બે અલગ શોધ તરીકે ગણો. ટનલ દ્વારા રિઝોલ્વ કરતો ક્લાયન્ટ રાઉટર વિશે કંઈ કહેતો નથી, અને યોગ્ય રીતે રિઝોલ્વ કરતું રાઉટર બીજા લિસનર પરના ક્લાયન્ટ વિશે કંઈ કહેતું નથી. તેમને ફેરફાર રેકોર્ડમાં અલગ લીટી તરીકે લખો.

પોર્ટ પણ તપાસો: ગંતવ્ય પોર્ટ 53 મેળવતો નિયમ 853 પર DNS over TLS અથવા HTTPS અંતિમ બિંદુ દ્વારા પહોંચાતા રિઝોલ્વરને ચૂકી જાય છે. કન્ફિગર કરેલો અપસ્ટ્રીમ ખરેખર જે ટ્રાન્સપોર્ટ વાપરે છે તે મેળવો, અને લીક યોગ્ય કારણથી બંધ થાય છે.