WireGuard દ્વારા એક એપ: બાઇન્ડિંગ એ રાઉટિંગ નથી

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

આ મિકેનિઝમના બે ભાગ છે: એક રાઉટિંગ ટેબલ જે ફક્ત ટ્યુનલનો ટ્રાફિક વાપરવો જોઈએ, અને એક નિયમ જે મેળ ખાતા સ્રોતને ત્યાં મોકલે છે.

બાઇન્ડિંગ સ્રોત સરનામું સેટ કરે છે, તેનાથી વધુ નહીં

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

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

ટ્યુનલને તેનું પોતાનું ટેબલ આપો

wg-quick પ્રોફાઇલ કહે ત્યાં રૂટ ઇન્સ્ટોલ કરે છે. [Interface] હેઠળ Table = 40 ઉમેરવાથી તે મુખ્ય ટેબલને બદલે ટેબલ 40 માં જાય છે. ઇન્ટરફેસ ઉપર લો અને તે પહોંચ્યા છે તેની ખાતરી કરો: ip -4 route ls table 40 એ ટ્યુનલના રૂટ બતાવવા જોઈએ, અને ip -4 route get 10.66.127.142 એ બતાવે છે કે કર્નલ હમણાં તેમાંથી એકને કેવી રીતે ઉકેલે છે. રૂટ તેમના પોતાના ટેબલમાં હોવાથી મુખ્ય ટેબલ બાકીના બધા માટે કામ કરતું રહે છે.

IPv6 માટે પણ એ જ કરો, પહોળા પ્રીફિક્સ સાથે મેળ કરવાને બદલે. ip -6 rule add from fd00::2/128 lookup 40 એક સરનામું પિન કરે છે; fc00::/8 હોસ્ટ પરના અન્ય ઇન્ટરફેસ સાથે અથડાઈ શકે છે અને ઇચ્છિત કરતાં વધુ મેળ ખાતો નિયમ બનાવી શકે છે.

સ્રોત નિયમ ઉમેરો અને કાઉન્ટર જુઓ

પછી બે ભાગ જોડો: ip -4 rule add from 10.66.127.142/32 lookup 40, તે જ સરનામું WireGuard ઇન્ટરફેસ સાથે જોડેલું રાખીને. બંને નિયમ PostUp માં મૂકો જેથી ફરી કનેક્ટ થવાથી તેઓ પાછા આવે. સેટિંગને બદલે વાસ્તવિક વિનંતીથી ચકાસો: ip route get 1.1.1.1 from 10.66.127.142 એ ટ્યુનલ ઉપકરણનું નામ આપવું જોઈએ, અને curl --interface wg0 ifconfig.me એ ઘરના સરનામાને બદલે ટ્યુનલનું સરનામું જણાવવું જોઈએ.

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

ઊલટો કિસ્સો: SSH ને ટ્યુનલની બહાર રાખો

વિરુદ્ધ સમસ્યા પણ એટલી જ સામાન્ય છે: wg-quick ડિફોલ્ટ રૂટનું માલિક છે અને સર્વરનું SSH સેશન વચ્ચેમાં જ મરી જાય છે. તેના નિયમો નીચા પ્રાયોરિટી નંબર પર બેસે છે, તેથી અપવાદનું મૂલ્યાંકન તેમનાથી પહેલાં થવું જોઈએ. ip rule add dport 22 ipproto tcp table main priority 123 તાજેતરના iproute2 પર એ કરે છે; જ્યાં સિલેક્ટર ઉપલબ્ધ નથી ત્યાં nftables માં ફ્લોને માર્ક કરો અને તેના બદલે માર્ક સાથે મેળ કરો.

જવાબનો માર્ગ પણ તપાસો. જે SSH સેશન સ્થપાય છે અને પછી શાંત થઈ જાય છે તેમાં સામાન્ય રીતે અસમમિત રાઉટિંગ હોય છે: એક દિશા ટ્યુનલ દ્વારા અને બીજી ભૌતિક ઇન્ટરફેસ દ્વારા બહાર જાય છે. સર્વર સરનામા માટે ip route get કહે છે કે જવાબ કઈ દિશામાં જશે.

ટેબલ નંબર, સ્રોત નિયમ અને અપવાદ પ્રોફાઇલમાં જ નોંધો. ત્રણેય એક જ ડિઝાઇનના છે અને સાથે સંપાદિત થશે.