VPN પર Dante SOCKS: સંપૂર્ણ ટનલ સામે સ્રોત-આધારિત રાઉટિંગ

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

બે ડિઝાઇન, બે જુદી નુકસાનની ત્રિજ્યા

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

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

આ સાંકડાઈ એ જ મર્યાદા છે: ડિઝાઇન ત્યારે જ કામ કરે છે જ્યારે પ્રોક્સીના બહાર જતા પેકેટ ખરેખર તે સરનામું વહન કરે.

Dante નું external સેટિંગ શું કરે છે

external સેટિંગ તે સરનામાંઓ પસંદ કરે છે જે પ્રોક્સી બહાર જતા જોડાણો માટે વાપરે છે; તે કર્નલની રાઉટિંગ નીતિને સ્પર્શતું નથી. એ જ અલગતા બીજી ડિઝાઇનને શક્ય બનાવે છે, અને અહીં જ લોકો દસ્તાવેજીકરણ ખોટું વાંચે છે. external ને ટનલ સરનામા પર દોરવાથી પ્રોક્સી તેના જોડાણો તે સરનામાંથી ઉત્પન્ન કરે છે, અને પછી રાઉટિંગ ટેબલ નક્કી કરે છે કે તે પેકેટ ક્યાં જાય.

શ્રોતા અલગ બાબત છે. internal ને ફક્ત તે ક્લાયન્ટ સુધી મર્યાદિત રાખો જેમણે પ્રોક્સી વાપરવું જોઈએ, પ્રમાણીકરણ જરૂરી બનાવો અને પોર્ટને ફાયરવૉલથી બંધ કરો, કારણ કે ખુલ્લો શ્રોતા VPN નિકાસનું લક્ષણ નથી.

ખાતરી કરો કે ગોઠવેલું સરનામું પ્રોક્સીના નેટવર્ક નામસ્થાનમાં ખરેખર ટનલનું છે.

સ્રોત-આધારિત ટેબલ બનાવવું

10.90.0.2/24 ના TUN સરનામા સાથે, 10.90.0.1 પર પહોંચી શકાય તેવા પીઅર સાથે, અને એવા ટેબલ નંબર સાથે જે બીજું કંઈ વાપરતું નથી, ગોઠવણ આવી દેખાય છે:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

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

આ મૂલ્યો એક ટોપોલોજીનું વર્ણન કરે છે. પોઈન્ટ-ટુ-પોઈન્ટ પીઅર, net30 એડ્રેસિંગ અને અલગ પ્રીફિક્સ આપતા ક્લાયન્ટને પોતાના રૂટની જરૂર હોય છે, તેથી સરનામાં નહીં, આકાર નકલ કરો.

સ્રોત નિયમ ક્યાં લીક થાય છે

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

DNS બીજું લીક છે. રિઝોલ્વર સોકેટ જરૂરી નથી કે પ્રોક્સીના external ડેટા-જોડાણ સ્રોતનો ઉપયોગ કરે, તેથી નામ-શોધ હજી પણ WAN દ્વારા બહાર જઈ શકે. જોડાણ સ્થાપવાથી અલગ રીતે રિઝોલ્યુશન ચકાસો, અને નક્કી કરો કે તે પરિણામ સ્વીકાર્ય છે કે નહીં.

IPv6 ને પોતાના નિયમો અને રૂટની જરૂર છે, કારણ કે IPv4 ની ગોઠવણ તેના વિશે કંઈ સાબિત કરતી નથી.

તમે સહન કરી શકો તે નિષ્ફળતા પ્રમાણે પસંદ કરો

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

તમે જે પણ પસંદ કરો, બંને બાજુથી ચકાસો: પ્રોક્સી દ્વારા એક વિનંતી અને હોસ્ટથી સીધી વિનંતી, દરેક માટે જોવા મળેલું નિકાસ સરનામું નોંધીને.

જો ટનલ પડી જાય, તો અગાઉથી નક્કી કરો કે પ્રોક્સીએ નિષ્ફળ થવું જોઈએ કે પાછું ફરવું જોઈએ, અને રાઉટિંગ ટેબલને તે નિર્ણય વ્યક્ત કરવા દો.