Redsocks લૂપબેક પર સાંભળે છે પણ VPN ટ્રાફિક કદી પહોંચતો નથી

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

રીડાયરેક્ટ થયેલું પેકેટ ખરેખર ક્યાં ઉતરે છે

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

તેથી અપસ્ટ્રીમ ઓળખપત્રોને સ્પર્શ કરતા પહેલા બે હકીકતો સ્થાપિત કરો: નિયમ કયા સ્થાનિક સરનામા પર ફરીથી લખે છે, અને પ્રોક્સી સોકેટ કયા સરનામા પર બંધાયેલું છે.

શ્રોતા અને રીડાયરેક્ટ નિયમ સાથે વાંચો

સોકેટ ટેબલ અને nat નિયમો એક જ પાસમાં છાપો, કારણ કે જે પોર્ટનો કોઈ માલિક નથી તે તરફ ઇશારો કરતો નિયમ ખોટા સરનામા તરફ ઇશારો કરતા નિયમ જેવો જ દેખાય છે. sudo ss -ltnp | grep redsocks બાઇન્ડ સરનામું અને માલિક પ્રક્રિયા બતાવે છે. sudo iptables -t nat -S PREROUTING REDIRECT લક્ષ્ય બતાવે છે, અને sudo iptables -t nat -L PREROUTING -v -n બતાવે છે કે કંઈ તેની સાથે મેળ ખાધું કે નહીં.

REDSOCKS નામની વપરાશકર્તા શૃંખલામાં કૂદકો કંઈ જ સિદ્ધ કરતો નથી જ્યાં સુધી તે શૃંખલા અસ્તિત્વમાં ન હોય અને ઇચ્છિત બાકાતો તથા REDIRECT ક્રિયા ન ધરાવે. નામ જ કામ કરે છે એમ માનવાને બદલે sudo iptables -t nat -S REDSOCKS વડે જે શૃંખલામાં તે કૂદે છે તે વાંચો.

પછી બે મૂલ્યોની સરખામણી કરો. જો નિયમ પોર્ટ 12345 પર ગેટવે સરનામા તરફ રીડાયરેક્ટ કરે અને શ્રોતા 127.0.0.1:12345 જાણ કરે, તો અસંગતિ વધુ નિદાન વિના નિષ્ફળતા સમજાવે છે.

સાંકડી રીતે બાંધો, પછી તે સુધી શું પહોંચી શકે તે મર્યાદિત કરો

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

જાહેર ઇન્ટરફેસ પર પોર્ટ ખોલવો રીડાયરેક્ટ થયેલા VPN ટ્રાફિક માટે કદી જરૂરી નથી, કારણ કે ફરીથી લખ્યા પછી કનેક્શન સ્થાનિક રીતે સમાપ્ત થાય છે. સ્થાનિક રીડાયરેક્ટ કામ કરે તે માટે પ્રોક્સીને ઇન્ટરનેટ પર ખુલ્લું ન રાખો.

ક્લાયન્ટથી નવા કનેક્શન સાથે તે સાબિત કરો

ગેટવે પરના શેલમાંથી નહીં, વાસ્તવિક VPN ક્લાયન્ટથી નવા TCP કનેક્શન સાથે પરીક્ષણ કરો. ક્લાયન્ટ પર curl -sS -o /dev/null -w '%{http_code}\n' http://example.com રીડાયરેક્ટ થયેલો માર્ગ શરૂઆતથી અંત સુધી ચલાવે છે.

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

અંતે યાદ રાખો કે આ માર્ગ શું આવરી લેતો નથી. સામાન્ય redsocks TCP રીડાયરેક્ટ UDP, QUIC કે DNS ને SOCKS ટ્રાફિકમાં ફેરવતું નથી, અને ખાનગી ગંતવ્યોને સામાન્ય રીતે સ્પષ્ટ બાકાતોની જરૂર પડે છે. સફળ સ્થાનિક પરીક્ષણ ફક્ત એ લૂપબેક માર્ગ સાબિત કરે છે જે કદી સમસ્યા ન હતો.