libvirt મહેમાનનું DNS માર્ક-આધારિત VPN ફાયરવોલ દ્વારા અવરોધાયેલું સુધારો

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

ટનલ ઉપર આવે તે ક્ષણે જ મહેમાનો DNS ગુમાવે છે

કંઈપણ બદલતા પહેલાં આકારની પુષ્ટિ કરો. ટનલ નીચે ઉતારો, મહેમાનમાંથી dig @192.168.122.1 example.com ચલાવો, અને તે જવાબ આપે છે તે જુઓ. ટનલ ઉપર લો, પુનરાવર્તન કરો, અને તેનો સમય પૂરો થાય છે તે જુઓ. પરિણામોની આ જોડી એક જ પગલામાં તૂટેલા libvirt નેટવર્ક, ખોટા રિઝોલ્વર સરનામા અને મૃત dnsmasq ને બાકાત કરે છે.

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

પછીની શૃંખલામાંનો accept નિયમ કેમ ક્યારેય સક્રિય થતો નથી

માર્ક-આધારિત VPN ફાયરવોલ પેકેટ માર્ક કે કનેક્શન માર્ક જોઈને નિર્ણય લે છે, તમારા સ્રોત સરનામાને જોઈને નહીં. અપેક્ષિત માર્ક વિના ભૌતિક ઇન્ટરફેસ પર આવતું કંઈપણ નકારવામાં આવે છે, અને તે નકાર માર્ક પરીક્ષણ ધરાવતા નિયમ-સમૂહમાં થાય છે. પછીની કોઈ શૃંખલામાં ઉમેરાયેલી ip saddr 192.168.122.0/24 accept લાઇન તે પેકેટ માટે ક્યારેય ધ્યાનમાં લેવાતી નથી, તેથી સ્પષ્ટ નિયમ સાચો લાગે છે અને કંઈપણ બદલતો નથી.

કંઈક કામ કરે ત્યાં સુધી તેને પહોળું કરવું બીજો જાળ છે. હોસ્ટના ઇનપુટ માર્ગમાં આખું libvirt સબનેટ સ્વીકારવું મહેમાનો માટે હોસ્ટની દરેક સેવા ખોલે છે, જ્યારે વાસ્તવિક જરૂરિયાત એક પોર્ટ છે.

સાંકડા અપવાદને શક્ય બનાવતી પદ્ધતિ કનેક્શન ટ્રેકિંગ છે. જ્યારે તમે પેકેટ પર ct mark સેટ કરો છો, ત્યારે મૂલ્ય ફક્ત પેકેટ પર નહીં પણ conntrack એન્ટ્રી પર સંગ્રહાય છે, તેથી તે કનેક્શનના દરેક પેકેટ પછી તેને વહે છે, હોસ્ટથી મહેમાન તરફનો જવાબ પણ સહિત. આખી યુક્તિ એ છે: વિનંતીને એક વાર માર્ક કરો, અને પરત માર્ગ પહેલેથી માર્ક થયેલો છે.

VPN ટેબલ તેને જોવાના પહેલાં ક્વેરીને માર્ક કરો

અપવાદને તેના પોતાના ટેબલમાં મૂકો જેથી પછીનો વાચક VPN નિયમોનું પૃથ્થકરણ કર્યા વિના તેને શોધી શકે:

table inet allowedLocal {
  chain guest_dns {
    type filter hook input priority mangle; policy accept;
    ip saddr 192.168.122.0/24 meta l4proto { tcp, udp } \
      th dport 53 ct mark set 0x00000f41
  }
}

priority mangle ઋણ છે, જે આ શૃંખલાને VPN પેકેજ શૂન્ય અગ્રતા પર સ્થાપિત કરતી સામાન્ય ફિલ્ટર શૃંખલાઓ પહેલાં મૂકે છે. હૂકનો ક્રમ જ નિયમને અસરકારક બનાવે છે; VPN શૃંખલા પછી ગોઠવાતી શૃંખલામાં એ જ નિયમ માત્ર શણગાર છે.

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

છિદ્રને પોર્ટ 53 ની પહોળાઈમાં રાખો

જેમ લખાયું છે તેમ, આ libvirt સબનેટથી હોસ્ટ સુધી TCP અથવા UDP પોર્ટ 53 પર DNS ની મંજૂરી આપે છે અને બીજું કંઈ નહીં. તે મહેમાનોને ટનલની બહાર ઇન્ટરનેટ સુધી પહોંચવા દેતું નથી, અને હોસ્ટને મહેમાનો તરફ કનેક્શન ખોલવા દેતું નથી. જો મહેમાનને પછીથી બીજી હોસ્ટ સેવાની જરૂર પડે, તો આ નિયમને ઢીલો કરવાને બદલે તે ગંતવ્ય પોર્ટનું નામ આપતો અલગ નિયમ ઉમેરો.

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

તેને રીબૂટમાં ટકી રહેવા દો અને બંને અર્ધને સાબિત કરો

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

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

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