ગેટવે કે ફોરવર્ડ કરેલ ક્લાયન્ટ? સ્રોત સરનામું વાંચવું

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

ગંતવ્ય ખરેખર શું જુએ છે

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

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

અનુવાદની સ્થિતિ ગંતવ્ય માટે દૃશ્યમાન નથી

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

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

conntrack -L -s 198.51.100.10
tcpdump -ni eth0 host 198.51.100.10

TTL અને ફિંગરપ્રિન્ટ સુરાગ છે, પુરાવા નહીં

IPv4 માં TTL પ્રેષક પસંદ કરે તે પ્રારંભિક મૂલ્ય અને પેકેટે પાર કરેલા હોપની સંખ્યા પર આધાર રાખે છે. બંને તથ્યો વિના, કોઈ મૂલ્ય સાબિત કરી શકતું નથી કે VPN હોપ થયો છે. જાણીતો વધારાનો રાઉટ થયેલ હોપ પણ LAN રાઉટર, ટનલ માર્ગ કે બીજી ફોરવર્ડિંગ ગોઠવણીને અલગ કરી શકતો નથી. TTL તફાવતને પ્રશ્ન તરીકે લો, નિષ્કર્ષ તરીકે નહીં.

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

સરનામા દ્વારા નહીં, ઓળખ દ્વારા અધિકૃત કરો

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

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

અવલોકનની તારીખ અને તેને ઉત્પન્ન કરનાર સિસ્ટમ નોંધો. આરોપણ વગરનો લોગ અંશ પછી બચાવવો મુશ્કેલ છે.