પોર્ટ ફોરવર્ડ વિરુદ્ધ VPN ઍક્સેસ: પેકેટ ખરેખર ક્યાં જાય છે

પોર્ટ ફોરવર્ડ ગંતવ્યને ફરીથી લખે છે અને ત્યાં જ અટકે છે; VPN પહેલાં પેકેટને લપેટે છે. જુઓ કયું કયું સ્તર બદલે છે અને HTTPS માટે તેનો અર્થ શું છે.

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

DNAT નિયમ ગંતવ્યને ફરીથી લખે છે અને ત્યાં જ અટકે છે

Linux ગેટવે પર, સેવા પ્રકાશિત કરવાનો અર્થ nat ટેબલની PREROUTING શૃંખલામાં નિયમ, અથવા nftables માં તેના સમકક્ષ. નિયમ જાહેર સરનામા અને પોર્ટ સાથે મેળ ખાય છે, પછી ગંતવ્યને એપ્લિકેશનના ખાનગી સરનામા પર ફરીથી લખે છે. સ્રોત સરનામું, સ્રોત પોર્ટ અને પેલોડ અસ્પર્શ રહે છે, અને conntrack મેપિંગ નોંધે છે જેથી જવાબો બહાર જતી વખતે ફરીથી લખાય. આ વર્તન RFC 3022 માં વર્ણવેલ પરંપરાગત સરનામા અનુવાદ મોડેલ છે.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

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

નિયમ પછીથી મળતી નિષ્ફળતાની રીતો પણ નક્કી કરે છે. જો ગેટવે ફોરવર્ડ કરે પણ એપ્લિકેશનના હોસ્ટ પાસે ક્લાયન્ટ તરફ પાછા જવાનો કોઈ માર્ગ ન હોય, તો જવાબો ખોટા સ્રોત સાથે નીકળે છે અને હેન્ડશેક અટકી જાય છે. જો બીજો નિયમ પહેલાં મેળ ખાય, તો ક્રમ પરિણામ નક્કી કરે છે, અને iptables -t nat -L -n -v તે કાઉન્ટર બતાવે છે જે સાબિત કરે છે કે કયા નિયમે પેકેટ લીધું.

ટનલ શ્રોતા જોવ તે પહેલાં પેકેટને લપેટે છે

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

ટનલની અંદર અંદરનું પેકેટ ખાનગી સરનામાં રાખે છે: ક્લાયન્ટનું ટનલ સરનામું, કહો 10.8.0.6, અને એપ્લિકેશન 10.20.30.40 પર. તેથી શ્રોતા ટનલ પૂલમાંથી સ્રોત જુએ છે, અને દરેક ક્લાયન્ટ તે ગેટવેને પોતાના આગલા હોપ તરીકે વહેંચે છે. VPN પાછળના ઍક્સેસ લોગ ઘણી વાર વપરાશકર્તાને બદલે ગેટવે બતાવે છે તેનું કારણ બરાબર આ જ છે, સિવાય કે ગેટવે મૂળ સ્રોત સાચવે.

લપેટવું હેડર જગ્યા ખર્ચે છે, અને આ જ માપી શકાય તેવા પરિણામ સાથેનો એકમાત્ર મિકેનિઝમ-સ્તરનો તફાવત છે. બહારનું IP હેડર વત્તા UDP વત્તા WireGuardનું પોતાનું હેડર માર્ગના MTU માંથી ખાય છે, તેથી મોટા પેકેટને વિભાજિત કરવા પડે અથવા અંદરના TCP સ્ટેકે તેનું MSS મર્યાદિત કરવું પડે. ફોરવર્ડ કરેલા માર્ગ પર કામ કરતું ટ્રાન્સફર ટનલ પર અટકી શકે છે જ્યારે મધ્યસ્થ ઉપકરણ નાના MTU નો સંકેત આપતું ICMP છોડી દે છે.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

એક્સપોઝર પ્રવેશદ્વાર પર નક્કી થાય છે, સાઇફરથી નહીં

બંને ડિઝાઇન એક જ TLS શ્રોતા પર પૂરી થાય છે, તેથી બંને એક જ પ્રમાણપત્ર, એક જ પ્રોટોકોલ આવૃત્તિઓ અને એક જ એપ્લિકેશન લોગિન વારસામાં મેળવે છે. જે બદલાય છે તે એ છે કે કોને હેન્ડશેક શરૂ કરવાની પરવાનગી છે. જાહેર ફોરવર્ડ સાથે, 203.0.113.10:443 સુધી પહોંચતું કોઈપણ હોસ્ટ તમારી એપ્લિકેશન ઓથોરાઇઝેશન જોવાય તે પહેલાં જ TCP હેન્ડશેક અને TLS ClientHello મેળવે છે. ફક્ત ટનલ ઍક્સેસ સાથે, શ્રોતા ફક્ત તે સરનામાંથી પહોંચી શકાય છે જે ગેટવે ટનલમાં રૂટ કરે છે, અને અજાણ્યાનું SYN ગેટવે નીતિ પર મરી જાય છે.

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

શ્રોતા અને નીતિ અલગ-અલગ તપાસો, કારણ કે બંનેમાંથી કોઈપણ તમે ધારો છો તેના કરતાં વિશાળ હોઈ શકે:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

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

માર્ગ માપો, લેબલ નહીં

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

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

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

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

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

સંબંધિત લેખો