WireGuard ટનલની બહાર એક Linux પ્રોસેસ કેવી રીતે ચલાવવી

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

તમે રૂટ સંપાદિત કરીને કોઈ પ્રોગ્રામને સંપૂર્ણ ટનલવાળા WireGuard હોસ્ટમાંથી મુક્ત કરી શકતા નથી. રૂટ લક્ષ્ય પ્રમાણે માર્ગ પસંદ કરે છે, અને તમે મુક્ત કરવા માંગો છો તે પ્રોસેસ છે, તેથી કર્નેલ પાસે સરખાવવા જેવું કંઈ નથી. કામ કરી શકે તેવો અભિગમ એ છે કે તે પ્રોસેસને તેનું પોતાનું નેટવર્ક સંદર્ભ આપવું: પોતાનું ઇન્ટરફેસ, સરનામાં અને ડિફોલ્ટ રૂટ ધરાવતું નેમસ્પેસ, જે veth જોડી દ્વારા હોસ્ટ સાથે જોડાયેલું હોય. મેં આ Ubuntu 24.04 પર wireguard-tools 1.0.20210914 સાથે ચલાવ્યું, અને નેમસ્પેસ ક્યારેય સમસ્યા નહોતું — હોસ્ટની ફોરવર્ડિંગ નીતિ અને ટનલના માર્કિંગ નિયમો સમસ્યા હતા.

પહેલા તમને કયા પ્રકારનું સંદર્ભ જોઈએ તે પસંદ કરો

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

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

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

બીજું સંદર્ભ બનાવો અને તેને હોસ્ટ સાથે જોડો

એક દૃષ્ટાંતરૂપ ગોઠવણ: હોસ્ટ પાસે ડિફોલ્ટ રૂટ વહન કરતું WireGuard ઇન્ટરફેસ છે, અનેclearnet નામનું નેટવર્ક નેમસ્પેસ છે, જે veth જોડી દ્વારા હોસ્ટ સાથે જોડાયેલું છે. નીચેનાં સરનામાં ઉદાહરણો છે.

ip netns add clearnet
ip link add veth-clear-out type veth peer name veth-clear-in
ip addr add 192.168.100.1/24 dev veth-clear-out
ip link set veth-clear-out up
ip link set veth-clear-in netns clearnet
ip netns exec clearnet ip addr add 192.168.100.2/24 dev veth-clear-in
ip netns exec clearnet ip link set veth-clear-in up
ip netns exec clearnet ip route add default via 192.168.100.1

આ નેમસ્પેસ હવે હોસ્ટ સુધી પહોંચી શકે છે અને બીજે ક્યાંય નહીં. હોસ્ટે ટ્રાફિક ફોરવર્ડ કરવો પડે અને સ્રોત સરનામું ફરી લખવું પડે, કારણ કે 192.168.100.0/24 ખાનગી છે અને અપસ્ટ્રીમ રાઉટર પાસે તેમાં પાછા જવાનો કોઈ રૂટ નથી:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o <wan-interface> -j MASQUERADE

આગળ વધતા પહેલા નેમસ્પેસની બાજુ ખાતરી કરો.ip netns exec clearnet ip route એ veth રૂટ અને 192.168.100.1 દ્વારા ડિફોલ્ટ રૂટ બતાવવો જોઈએ, અને તે સરનામાં પરનો ping જવાબ આપવો જોઈએ. જો હોસ્ટના સરનામાં પરનો ping નિષ્ફળ જાય, તો સરનામાં કે લિંકની સ્થિતિ ખોટી છે અને કોઈ ફાયરવોલ નિયમ મદદ કરશે નહીં.

જ્યારે નામ ઉકેલાય પણ કંઈ પાછું ન આવે, ત્યારે FORWARD વાંચો

ઉત્તમ ક્ષતિ રૂટિંગ બગ જેવી લાગે છે: નેમસ્પેસ નામ ઉકેલે છે, પેકેટ બહાર જાય છે, અને કોઈ જવાબ ક્યારેય આવતો નથી. જે હોસ્ટમાં FORWARD નીતિ DROP હોય છે — ઘણા ડિસ્ટ્રિબ્યુશન અને મોટાભાગની કઠોર ઇમેજ એમ કરે છે — ત્યાં પેકેટ રસ્તામાં જ ફેંકાઈ જાય છે, અને એપ્લિકેશન જે ભૂલ છાપે છે તે ફિલ્ટરિંગ વિશે કંઈ કહેતી નથી.

કંઈ ઉમેરતા પહેલા સાંકળ વાંચો:

iptables -S FORWARD
nft list chain inet filter forward

પછી બંને દિશામાં ટ્રાફિકને મંજૂરી આપો, કાઉન્ટરો સાથે, જેથી ખબર પડે કે નિયમ ક્યારેય મેળ ખાધો છે કે નહીં:

iptables -A FORWARD -i veth-clear-out -o <wan-interface> -j ACCEPT
iptables -A FORWARD -i <wan-interface> -o veth-clear-out -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
watch -n1 'iptables -L FORWARD -v -n'

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

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

ટનલના માર્કિંગ નિયમોને નવા રસ્તાથી દૂર રાખો

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

બે ઉમેરા રસ્તાઓને અલગ કરે છે. નેમસ્પેસ સબનેટ માટે mangle સાંકળમાં વહેલા પાછા ફરો, અને સ્રોત-આધારિત નિયમ ઉમેરો જે તે સબનેટને મુખ્ય ટેબલમાં મૂકે છે:

iptables -t mangle -I PREROUTING -s 192.168.100.0/24 -j RETURN
ip rule add from 192.168.100.0/24 lookup main priority 100

મારા હોસ્ટ પર પ્રાયોરિટી 100 ટનલ નિયમો પહેલા ક્રમમાં આવે છે, તેથી તે સ્રોત માટે સામાન્ય ટેબલ નક્કી કરે છે. આંકડો આંધળા થઈને કોપી ન કરો: જે પ્રાયોરિટીઓનેwg-quick ઇન્સ્ટોલ કરે છે તે આવૃત્તિઓ અને IPv4 તથા IPv6 સેટઅપ વચ્ચે અલગ પડે છે, તેથી ચલાવોip rule show અને એવી પ્રાયોરિટી પસંદ કરો જે તમારા મશીન પર ટનલ નિયમો પહેલા પડે.

ભરોસો કરવાને બદલેસ્રોત-વિશિષ્ટ શોધ વડે ચકાસો:

ip route get 1.1.1.1 from 192.168.100.2
ip netns exec clearnet ip route get 1.1.1.1

જો પહેલો આદેશ WireGuard ઇન્ટરફેસ જણાવે, તો નવો નિયમ હજી ટનલ નીતિ પહેલા નથી. જો તે WAN ઇન્ટરફેસ જણાવે જ્યારે બીજો હજી veth ડિફોલ્ટ બતાવે, તો હોસ્ટ અને નેમસ્પેસ સહમત નથી અને તમારે બંને રૂટિંગ ટેબલ ફરી વાંચવા જોઈએ.

કનેક્શન ખોલતી પ્રોસેસ શરૂ કરો

આદેશ શરૂ કરવો એક લીટી છે, પણ જે પ્રોસેસ ખરેખર સોકેટ બનાવે છે તે શરૂ કરો.ip netns exec clearnet curl -s https://ifconfig.me એ સૌથી નાનું પ્રામાણિક પરીક્ષણ છે: તે નેમસ્પેસ વિશ્વને જે સરનામું રજૂ કરે છે તે બતાવે છે, હોસ્ટ જે વાપરે તે નહીં.

સેવા માટે, નેમસ્પેસને પાથ દ્વારા જોડો જેથી પ્રોસેસ તેના આખા જીવનકાળ દરમિયાન તેમાં જ રહે:

[Service]
NetworkNamespacePath=/run/netns/clearnet

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

readlink /proc/$(pgrep -f clearnet-profile | head -1)/ns/net
readlink /run/netns/clearnet

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

નામ ઉકેલવા માટે પોતાનો નિર્ણય જોઈએ. નેમસ્પેસ બનાવવાથી તેને રિઝોલ્વર ગોઠવણી મળતી નથી; નેમસ્પેસ દીઠ ફાઇલો/etc/netns/<name>/resolv.conf દ્વારા સપોર્ટેડ છે, અને તેના વિના તમે એવું વર્તન વારસામાં લો છો જે સહેલાઈથી ખોટું વંચાય. IPv6 ને પણ એ જ વ્યવહાર જોઈએ: જો નેમસ્પેસ પાસે v6 ડિફોલ્ટ રૂટ ન હોય જ્યારે એપ્લિકેશન v6 પસંદ કરે, તો વિનંતીઓ પાછી પડતા પહેલા અટકી શકે છે, જે તૂટેલી ટનલ જેવું લાગે છે.

ફ્રેમિંગ તપાસો, ફક્ત બહાર નીકળવાનું સરનામું નહીં

કામ કરતું જાહેર સરનામું રૂટ સાબિત કરે છે, આખી જરૂરિયાત નહીં. બાકીનું આ ક્રમમાં કરો:

  • ip netns exec clearnet ip route get 1.1.1.1 veth ડિફોલ્ટ બતાવે છે, WireGuard ઇન્ટરફેસ નહીં.
  • વિનંતી ચાલતી હોય ત્યારે બંને નિયમોના FORWARD કાઉન્ટર વધે છે.
  • એપ્લિકેશન પ્રોસેસ તમે અપેક્ષા રાખો તે નેમસ્પેસ inode જણાવે છે.
  • રીબૂટ પછી સેવા શરૂ થાય તે પહેલા નેમસ્પેસ અસ્તિત્વમાં છે; વહેલું ચાલતું unit નિષ્ફળ જાય છે, અથવા વધુ ખરાબ, નેમસ્પેસની બહાર ચાલે છે.

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

સંબંધિત લેખો