એક પોર્ટને VPNની બહાર રાખવા માટે પોલિસી રાઉટિંગ જરૂરી છે

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

સાદો રૂટ પોર્ટ સાથે કેમ મેળ ખાઈ શકતો નથી

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

આધુનિક iproute2 અને કર્નલ નિયમનો સિલેક્ટર પહોળો કરે છે: ipproto, sport અને dport સ્વીકારવામાં આવે છે, તેથી ip rule add ipproto tcp dport 22 table 100 ઇરાદો એક જ લીટીમાં વ્યક્ત કરે છે. વાસ્તવિક હોસ્ટ પર ip rule add help ચલાવો અને જુઓ કે તમારું બિલ્ડ dport સૂચિબદ્ધ કરે છે કે નહીં. જો કરે, તો એક જ આદેશમાં કામ પૂરું; જો ન કરે, તો નીચેનો માર્ક માર્ગ સમકક્ષ છે.

કોઈ પણ રીતે નિયમ ફક્ત સંકેત છે. કોષ્ટક 100ને હજી રૂટની જરૂર છે, અને લોકો એ ભાગ ભૂલી જાય છે.

ત્રણ ભાગ, કે એક

આધુનિક સ્વરૂપ ઉપરનો એક નિયમ અને વૈકલ્પિક કોષ્ટકમાં એક રૂટ છે. ક્લાસિક સ્વરૂપ વચ્ચે netfilter ઉમેરે છે: પેકેટને માર્ક કરો, પછી નિયમમાં માર્ક મેળવો. બંને એક જ લુકઅપ પર પૂરા થાય છે; ફરક એ છે કે પોર્ટ ક્યાં વંચાય છે.

માર્ક પદ્ધતિ એટલા માટે છે કારણ કે netfilter ટ્રાન્સપોર્ટ હેડર જુએ છે અને રાઉટિંગ કોડ ઐતિહાસિક રીતે જોતો ન હતો. આખી કાર્યવિધિ આ જ છે, અને એ સમજાવે છે કે વૈકલ્પિક માર્ગ એક ચતુર આદેશ નહીં, પણ ત્રણ સહયોગી ભાગ કેમ છે.

ત્રણ ભાગ ક્રમમાં

પહેલાં, જે ફ્લો ફેરવવા છે તેને માર્ક કરો, એવી ચેનમાં જે રૂટ નિર્ણય પહેલાં માર્ક હાજર થાય એટલી વહેલી ચાલે:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

બીજું, માર્ક કરેલા પેકેટને અલગ કોષ્ટકમાં મોકલો:

ip rule add fwmark 0x1/0x1 table 100

ત્રીજું, એ કોષ્ટકને ભૌતિક લિંક દ્વારા ડિફોલ્ટ રૂટ આપો. સરનામાં ઉદાહરણ છે; તમારાં પોતાનાં મૂકો:

ip route add default via 192.168.1.1 dev wlan0 table 100

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

પહેલા પેકેટ પછી પણ તેને ચાલુ શું રાખે છે

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

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

ટનલનું પોતાનું ટ્રાન્સપોર્ટ માર્ક કરશો નહીં. WireGuard કે UDP OpenVPN ટનલ TCP 22 નથી, તેથી ઉપરની રીત સલામત છે, પણ ટનલ ગંતવ્ય સિવાય બાકી બધું એમ લખાયેલો અપવાદ એન્ક્રિપ્ટેડ પેકેટ પકડી શકે છે અને ટનલને રાઉટિંગ લૂપ જેવી રીતે તોડી શકે છે.

ધારવાને બદલે ચકાસો

કર્નલને પૂછો કે તે કયો માર્ગ લેશે, ગંતવ્ય અને પોર્ટ માટે, પછી વાસ્તવિક ટ્રાન્સફર ચલાવો:

ip route get 203.0.113.10
ip rule show
nft list ruleset

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

આ ક્યારે ખોટું સાધન છે

પોર્ટ-આધારિત અપવાદો સ્વભાવે નાજુક છે. સેવાઓ પોર્ટ બદલે છે, HTTP/3 UDP 443 તરીકે આવે છે, અને એક એપ્લિકેશન વિવિધ પ્રકારના અનેક ફ્લો ખોલી શકે છે. ખરી જરૂરિયાત આ પ્રોગ્રામ સામાન્ય લિંક વાપરે એ હોય, તો રાઉટિંગ સ્તર ખોટું સ્થાન છે; નેટવર્ક નેમસ્પેસ કે દરેક એપ્લિકેશન માટે પ્રોક્સી વધુ યોગ્ય છે.

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

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