UID નિયમો સાથે એક Linux એપને VPN સાથે જોડવાની રીત

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

નિર્ણય પહેલાં એકાઉન્ટને માર્ગ આપો

માલિક-મેળ એક પ્રશ્નનો જવાબ આપે છે: આ UID સાથે જોડાયેલા સ્થાનિક સોકેટે પેકેટ બનાવ્યું છે? તે ઇન્ટરફેસ પસંદ કરતું નથી, અને મુખ્ય કોષ્ટક જે ટ્રાફિક પહેલેથી ભૌતિક NIC દ્વારા મોકલે છે તેને ખસેડી શકતું નથી. તેથી મેળ ખાતા માર્ગ વગરનો UID નિયમ પ્રોગ્રામને વાળવાને બદલે અવરોધે છે.

એકાઉન્ટને પહેલાં તેના પોતાના કોષ્ટકમાંથી પસાર કરો, પછી ફાયરવોલને પરિણામની પુષ્ટિ કરવા દો. આ એવા હોસ્ટ પર કામ કરે છે જેનું iproute2 uidrange સમજે છે, જે ip rule help એક લીટીમાં જણાવે છે. કોષ્ટક 100 ટનલ દ્વારા ડિફોલ્ટ રૂટ રાખે છે, અને નિયમ ફક્ત UID 1000 ને તે કોષ્ટકમાં મોકલે છે. બાકીનું બધું મુખ્ય કોષ્ટક પર રહે છે અને ભૌતિક કડીનો ઉપયોગ ચાલુ રાખે છે.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

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

કેમ loopback અપવાદ ટનલને મારી નાખે છે

નિયમની મોટાભાગની નકલ કરેલી આવૃત્તિઓ loopback દ્વારા ન નીકળતું દરેક પેકેટ ફેંકી દે છે. ટનલ loopback નથી, તેથી તે સ્વરૂપ ટનલનો ટ્રાફિક પણ ફેંકી દે છે, અને પરિણામ ફાયરવોલની ભૂલને બદલે મૃત VPN જેવું લાગે છે.

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

loopback હજી પણ DROP ઉપર પોતાનું ACCEPT લાયક છે, કારણ કે પ્રોગ્રામનું પહેલું DNS પેકેટ lo દ્વારા સ્થાનિક સ્ટબ તરફ જાય છે. બે નિયમો આ ક્રમમાં મૂકો, અને એકાઉન્ટ સ્ટબ સુધી પહોંચે છે, પછી ટનલ સુધી, અને બીજે ક્યાંય નહીં.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 અલગ નિયમ-સમૂહ છે, અને ફક્ત v4 માટેની જોડી ip6tables ને અસ્પૃશ્ય રાખે છે. AAAA રેકોર્ડને પ્રાધાન્ય આપતો પ્રોગ્રામ ત્યારે DROP સુધી ક્યારેય પહોંચ્યા વિના ભૌતિક કડી દ્વારા બહાર જશે. બંને નિયમો ip6tables માં પ્રતિબિંબિત કરો, અથવા જ્યારે ટનલ કોઈ v6 સરનામું ન વહે ત્યારે હોસ્ટ પર IPv6 બંધ કરો. હાથે ઉમેરેલા નિયમો પણ રીબૂટ પર અદૃશ્ય થાય છે, તેથી તેમને netfilter-persistent save થી સાચવો અથવા તે જ તર્કને બૂટ યુનિટ દ્વારા લોડ થતા nftables કોષ્ટક તરીકે ફરી બનાવો.

DNS જવાબો બીજી પ્રક્રિયામાંથી આવે છે

પ્રોગ્રામની પૂછપરછ 127.0.0.53 ને loopback ACCEPT પસાર કરે છે, અને ત્યાં જ UID મેળ અટકે છે. સ્ટબ રિઝોલ્વર તેના પોતાના સેવા-એકાઉન્ટમાંથી ઉપર તરફ ફોરવર્ડ કરે છે, તેથી vpnapp સાથે જોડાયેલો નિયમ બીજી પૂછપરછ ક્યારેય જોતો નથી. જો રિઝોલ્વર કડી માટે LAN સર્વર પસંદ કરે, તો જવાબો ભૌતિક NIC દ્વારા પાછા આવે છે જ્યારે પ્રોગ્રામના પોતાના પેકેટ ટનલમાં રહે છે. દૃશ્યમાન પરિણામ એ તૂટેલા નામો સાથે કામ કરતી ટનલ છે, અથવા તમે પસંદ ન કરેલા સર્વર દ્વારા જવાબ મળેલા નામો છે.

નામ-ઉકેલ ટનલ કડી પર સુધારો, એપ પર નહીં. ટનલ પ્રોફાઇલને DNS સર્વર અને રૂટિંગ ડોમેન આપો, પછી resolvectl query અને resolvectl status tun0 થી ખાતરી કરો કે રિઝોલ્વર મહત્ત્વના નામો માટે તેનો ઉપયોગ કરે છે. નેટવર્ક નામસ્થાનની અંદર સમસ્યા અદૃશ્ય થાય છે, કારણ કે નામસ્થાનનું રિઝોલ્વર ફક્ત ટનલ જાણે છે.

એકાઉન્ટમાંથી જ નિયમ ચકાસો

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

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

કાઉન્ટર દર્શાવે છે કે નિયમ ક્યારેય ચાલ્યો કે નહીં. ચલાવો iptables -vnL OUTPUT, દરેક નિયમની બાજુમાં પેકેટ-ગણતરી વાંચો, અને વાસ્તવિક ટ્રાફિક પછી DROPની બાજુમાં શૂન્યને મેળની ભૂલ ગણો.

ફોરવર્ડ થયેલો ટ્રાફિક આ ડિઝાઇનની બહાર છે. બ્રિજ પાછળનું કન્ટેનર કે VM પાસે vpnapp ની માલિકીનું સ્થાનિક સોકેટ નથી, તેથી માલિક-મેળ ક્યારેય ચાલતો નથી અને તે પેકેટો FORWARD નીતિ અનુસરે છે. જો તે કાર્યભાર આવરી લેવો હોય, તો તેને અલગથી ચકાસો અને બ્રિજ કે કન્ટેનર-સરનામા સાથે જોડાયેલી નીતિ લખો. ડિઝાઇન ત્યારે ટકે છે જ્યારે કોષ્ટક, ઇન્ટરફેસ અપવાદ, રિઝોલ્વર અને v6 નિયમો બધા એક જ દિશા દર્શાવે; તેમાંથી કોઈ પણ એક છોડી દો અને એકાઉન્ટ ક્યાં તો લીક થાય છે કે કનેક્ટિવિટી ગુમાવે છે.