WireGuard DNS DNAT: જવાબનો માર્ગ ચાલુ રાખો

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

10.77.0.0/24 માં અધિકૃત ક્લાયન્ટ wg0 પરથી આવે છે, જાહેર કરેલા સરનામા 10.77.0.1 ની પૂછપરછ કરે છે અને 203.0.113.53 પર રિઝોલ્વરની જરૂર છે — આ ઉદાહરણ લો. અપસ્ટ્રીમ સરનામું દસ્તાવેજીકરણ માટેનું પ્લેસહોલ્ડર છે, કાર્યરત સેવા નથી.

ક્વેરી રીડાયરેક્ટ કરવાથી ફક્ત તેનું ગંતવ્ય બદલાય છે

PREROUTING માં ગંતવ્ય-NAT નિયમ રાઉટિંગ નિર્ણય લેતા પહેલાં સરનામું ફરીથી લખે છે, તેથી પેકેટ પછી જૂના ગંતવ્યને બદલે નવા ગંતવ્ય તરફ રાઉટ થાય છે. ક્લાયન્ટનું સ્રોત સરનામું તે ક્રિયાથી અડ્યા વગર રહે છે. તેથી જ પૂર્ણ દેખાતો નિયમ પણ મૌન ઉત્પન્ન કરી શકે છે: વિનંતી હવે એવા રિઝોલ્વર પર જાય છે જેણે ક્લાયન્ટની ખાનગી શ્રેણી વિશે કદી સાંભળ્યું નથી. ગેટવેએ એક ક્ષેત્રનું ભાષાંતર કર્યું અને બીજી સમસ્યા વારસામાં મળી.

બંને DNS પરિવહનને મેળ ખાતા નિયમોની જરૂર છે, કારણ કે જવાબ કાપવામાં આવે ત્યારે ક્લાયન્ટ TCP પર પાછો ફરે છે.

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p udp --dport 53 -j DNAT --to-destination 203.0.113.53:53
iptables -t nat -A PREROUTING -i wg0 -s 10.77.0.0/24 -d 10.77.0.1 -p tcp --dport 53 -j DNAT --to-destination 203.0.113.53:53

જવાબનો માર્ગ અલગ નિર્ણય છે

બે ગોઠવણો જવાબને પાછો આવવા દે છે, અને એકને વહેલી પસંદ કરવાથી ડિબગિંગ સત્ર બચે છે. કાં તો અપસ્ટ્રીમ રિઝોલ્વરની આ ગેટવે દ્વારા 10.77.0.0/24 તરફ પાછી રૂટ છે, અથવા ગેટવે એગ્રેસ પર સ્રોતનું ભાષાંતર કરે છે જેથી જવાબ એવા સરનામે પહોંચે જે અપસ્ટ્રીમ પહેલેથી જાણે છે. બંને કામ કરે છે; ફક્ત એક જ અપસ્ટ્રીમ પર તમારા નિયંત્રણ સાથે મેળ ખાય છે.

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

તે ભાષાંતરને રીડાયરેક્ટ જેટલું જ કડક રાખો, નહીં તો નિયમ તેની સાથે સંજોગવશાત્ મેળ ખાતી કોઈપણ વસ્તુ માટે સામાન્ય હેતુનું NAT બની જશે:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -d 203.0.113.53 -o eth0 -p tcp --dport 53 -j MASQUERADE

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

કાર્ય જેટલું દેખાય તેના કરતાં વધુ સાંકડા નિયમો લખો

ફોરવર્ડિંગ પરવાનગી એ જ અવકાશની છે. બોક્સ પરનું દરેક DNAT કનેક્શન સ્વીકારવાને બદલે ક્લાયન્ટ-થી-રિઝોલ્વર પ્રવાહ અને conntrack પહેલેથી ઓળખે છે તેવા પરત ટ્રાફિકને મંજૂરી આપો. વ્યાપક સ્વીકૃતિ એ પોર્ટ ફોરવર્ડને પણ અધિકૃત કરે છે જેનો DNS સાથે કોઈ સંબંધ નથી.

ગેટવેનું પોતાનું રિઝોલ્વર એ અલગ કોડ પાથ છે. સ્થાનિક રીતે જારી કરાયેલી ક્વેરી OUTPUT માંથી પસાર થાય છે, તેથી ગેટવે શેલમાંથી પરીક્ષણ PREROUTING નિયમ કે ફોરવર્ડિંગ નીતિ બંનેમાંથી એકેયનો અભ્યાસ કરતું નથી. તેથી જ સ્થાનિક પરીક્ષણ પાસ થઈ શકે છે જ્યારે દરેક ક્લાયન્ટ નિષ્ફળ જાય છે, અને ઊંધું પણ એટલું જ સામાન્ય છે.

અહીં કંઈ પણ પોર્ટ 443 પર HTTPS ઉપર DNS અથવા પોર્ટ 853 પર TLS ઉપર DNS આવરી લેતું નથી, અને કંઈ પણ IPv6 આવરી લેતું નથી. IPv6 રિઝોલ્વર ગોઠવેલો હોય તેવો ક્લાયન્ટ આખી ગોઠવણને આનંદથી અવગણશે.

નવી ક્વેરી શું સાબિત કરે છે

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

dig @10.77.0.1 example.com A +short
conntrack -L -p udp --dport 53 | head

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

કંઈપણ રીડાયરેક્ટ કરતા પહેલાં ખાતરી કરો કે રિઝોલ્વર તમે અપેક્ષા રાખો છો તે નામો જાણે છે. જાહેર નામોનો જવાબ આપતો પણ તમારા ખાનગી ઝોનનો નહીં એવો વિકલ્પ કાર્યરત શોધને NXDOMAIN માં ફેરવે છે જે તૂટેલી ટનલ જેવું લાગે છે. ક્લાયન્ટ માર્ગ સંકળાય તે પહેલાં ગેટવેથી સીધું રિઝોલ્વરનું પરીક્ષણ કરો. અને iptables એક્સ્ટેન્શન સંદર્ભ તે DNAT અને masquerade અર્થશાસ્ત્રનું દસ્તાવેજીકરણ કરે છે જેના પર આ નિયમો આધાર રાખે છે.