VPN પર Nmapનું રો સ્કેન નિષ્ફળ, પણ -sT કનેક્શન કામ કરે છે?

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

ક્ષમતાને ટનલથી અલગ કરો

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

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

બંનેમાંથી કોઈ પરિણામ દૂરસ્થ સેવાનું વર્ણન કરતું નથી. બન્ને એક પદ્ધતિ હેઠળ એક માર્ગનું વર્ણન કરે છે, તેથી પદ્ધતિને નિષ્કર્ષ સાથે જોડેલી રાખો.

કનેક્શન તપાસ એક મંજૂર હોસ્ટ પર ચલાવો

તમારું કાર્ય જે એક હોસ્ટને આવરી લે છે તે પસંદ કરો, પછી એ મોડ વાપરો જેને કાચી એક્સેસની જરૂર નથી. અહીં ઉદાહરણ લક્ષ 198.51.100.24 છે, આ પ્રકારના ઉદાહરણ માટે અનામત દસ્તાવેજી જગ્યા.

એક લીટી, એક હોસ્ટ, એક પોર્ટ, કોઈ શોધ તબક્કો નહીં:

nmap -sT -Pn -p 443 --unprivileged 198.51.100.24

-sT પૂર્ણ TCP કનેક્શન પસંદ કરે છે, તેથી તે એ જ કર્નેલ માર્ગ વાપરે છે જે એપ્લિકેશન વાપરે છે અને તેને કૅપ્ચર ડ્રાઇવરની જરૂર નથી. -Pn હોસ્ટ શોધ છોડી દે છે; nmap સ્થાનિક સેગમેન્ટના લક્ષો માટે લિંક-લેયર રિઝોલ્યુશન હજી કરે છે, તેથી આ ફ્લેગ શૂન્ય પ્રારંભિક ટ્રાફિકનું વચન નથી. --unprivileged nmapને કહે છે કે ધારો કે તેની પાસે કોઈ રો કે સૂંઘવાના અધિકારો નથી, જે પદ્ધતિ બદલે છે અને કંઈ આપતું નથી.

દરેક ફ્લેગને એક ફેરફાર તરીકે વાંચો, સમારકામ તરીકે નહીં

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

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

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

પરિવહન પરિણામ પર થોભો, પછી સેવા ચકાસો

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

તેને સેવાના પોતાના ક્લાયન્ટ સાથે આગળ વધારો જેથી TLS ઓળખ અને એપ્લિકેશન વર્તન અલગ તથ્યો તરીકે જોવાય:

openssl s_client -connect 198.51.100.24:443 -servername staging.example.net </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
curl -sS -o /dev/null -w '%{http_code}\n' https://staging.example.net/health

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

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