VPN એગ્રેસ પાછળ પોર્ટ સ્કેનના પરિણામો કેમ બદલાય છે?
એગ્રેસ બદલો અને સેવા ખસ્યા વિના પોર્ટ જુદી રીતે જવાબ આપી શકે છે. પથના નિરીક્ષણને તમને ખરેખર જરૂરી ઇન્વેન્ટરીથી અલગ કરો.
એક જ પોર્ટ તપાસ ઓફિસ લાઇન પરથી અને VPN એગ્રેસ પરથી ચલાવો, અને બે જવાબો એવા સરનામા વિશે અસહમત થઈ શકે છે જે કોઈએ બદલ્યું નથી. આ તફાવત રૂટમાંથી અને કયા હોસ્ટે જવાબ આપ્યો તેમાંથી આવે છે, સેવા ચાલુ છે કે બંધ તેમાંથી નહીં. ત્રણ પ્રશ્નો આ સમજૂતીઓને અલગ કરે છે: પ્રોબે ખરેખર શું પૂછ્યું, કયા હોસ્ટે તેનો જવાબ આપ્યો, અને તમારા પોતાના સર્વરે શું નોંધ્યું. તેમને એ જ ક્રમમાં પૂરા કરો અને આગળ વધતા પહેલા દરેક જવાબ લખો.
બે રનની સરખામણી કરતા પહેલા પ્રોબ સુધારો
સ્થિતિ-શબ્દની સરખામણી બીજા સ્થિતિ-શબ્દ સાથે ત્યારે જ થઈ શકે છે જ્યારે બંને એક જ પ્રયોગમાંથી આવ્યા હોય. પાંચ ક્ષેત્રો તેને સ્થિર કરે છે: દૂરના છેડાએ જોયેલું સ્રોત સરનામું, ઉકેલાયેલું ગંતવ્ય, પોર્ટ, સ્કેનનો પ્રકાર અને સમય. તેમાંથી કોઈપણ બદલો અને તમે પ્રથમને બે વાર માપવાને બદલે બીજો પ્રયોગ કર્યો છે.
બીજા કંઈપણ પહેલા સ્રોત તપાસો, કારણ કે VPN ક્લાયન્ટ ચાલુ હોઈ શકે જ્યારે ટ્રાફિક હજી ભૌતિક ઇન્ટરફેસમાંથી નીકળતો હોય. દૂરના છેડાને પૂછો કે તે શું જુએ છે, પછી કર્નલને પૂછો કે તેણે કયું ઇન્ટરફેસ પસંદ કર્યું:
curl -s https://ifconfig.me
ip route get 203.0.113.20જુદા નેટવર્ક પરના બે સરનામાંનો અર્થ છે કે સમજૂતી પહેલેથી જ હાથમાં છે, અને બાકીની તપાસો ફક્ત તેની પુષ્ટિ કરશે. જ્યારે તેઓ સંમત થાય, ત્યારે પ્રોબને કારણ-ફ્લેગ ચાલુ સાથે કેપ્ચર કરો, જેથી સ્થિતિ ફક્ત નગ્ન શબ્દ તરીકે ઊભી રહેવાને બદલે સમજૂતી સાથે જોડાયેલી પાછી આવે. સ્કેનનો પ્રકાર પણ તે રેકોર્ડમાં આવે છે, કારણ કે તે શું માંગવામાં આવ્યું તે વર્ણવે છે, શું પાછું આવ્યું તે નહીં. સ્રોત, પદ્ધતિ અને ટાઇમસ્ટેમ્પ વિનાની સ્થિતિને કશાથી સરખાવી શકાતી નથી:
nmap -sT -p 443,8443 --reason 203.0.113.20તે આઉટપુટને રેકોર્ડની બાજુમાં રાખો, એવા સ્ક્રોલબેક બફરમાં નહીં જે આગલી વ્યક્તિ જોઈ શકે નહીં. અસહમત થતા બે પ્રામાણિક સ્કેન ફક્ત ત્યારે જ વિવાદ છે જ્યારે કોઈએ શરતો લખી ન હોય. શરતો સ્થિર થાય ત્યારે કાં તો પરિણામો મળે છે અને પ્રશ્ન બંધ થાય છે, અથવા તેઓ જુદા પડે છે અને તફાવત પથ વિશેની હકીકત છે.
કયા હોસ્ટે હેન્ડશેક પૂરો કર્યો તે શોધો
પૂર્ણ થયેલો હેન્ડશેક સાબિત કરે છે કે કોઈક હોસ્ટે તેને પૂરો કર્યો, અને તે હોસ્ટ તમારા ધ્યાનમાં રહેલી પ્રક્રિયા હોવી જરૂરી નથી. લોડ બેલેન્સર, રિવર્સ પ્રોક્સી અથવા SYN પ્રોક્સી વાસ્તવિક સર્વર સામેલ થાય તે પહેલા જવાબ આપી શકે છે, જે સામાન્ય ડિઝાઇન છે, લક્ષણ નહીં. અપેક્ષિત નામ માટે માન્ય પ્રમાણપત્ર પણ આને સાંકડું કરતું નથી, કારણ કે પ્રમાણપત્ર સેવા-સંબંધનું વર્ણન કરે છે અને કઈ મશીને કનેક્શન સમાપ્ત કર્યું તે વિશે કંઈ કહેતું નથી.
Nmap પોર્ટ-સ્થિતિ સંદર્ભ આને પાયાનું માને છે: સ્થિતિ નોંધે છે કે પ્રોબે કયાંથી મોકલાયો ત્યાંથી શું જોઈ શક્યું, પોર્ટની મિલકત નહીં. સ્થિતિ-શબ્દ આ રીતે વાંચો અને અસહમત થયેલા બે રન વિરોધાભાસીને બદલે સુસંગત લાગવા લાગે છે, જ્યારે પ્રશ્ન પોર્ટ ખુલ્લો છે કે નહીં તેમાંથી તેની સામે કોણ ઊભું હતું ત્યાં ખસે છે.
બીજા પ્રશ્નનો જવાબ બેકએન્ડમાં આપો, બહારથી નહીં. જે ફ્રન્ટએન્ડ કનેક્શન સ્વીકારે છે અને પછી તેના અપસ્ટ્રીમ સુધી પહોંચતું નથી તે ધીમી એપ્લિકેશન સાથે સ્વસ્થ સેવાનું બરાબર બાહ્ય ચિત્ર બનાવે છે. ફક્ત અપસ્ટ્રીમનો પોતાનો રેકોર્ડ બે કિસ્સાઓને અલગ કરે છે:
tail -n 5 /var/log/nginx/access.log
ss -ltnp 'sport = :443'લોગ લાઇન એ ક્લાયન્ટ સરનામું બતાવે છે જે એપ્લિકેશને ખરેખર જોયું, અને બીજો આદેશ બતાવે છે કે પોર્ટ 443 ધરાવતી પ્રક્રિયા તમારી એપ્લિકેશન છે કે તેની સામે કંઈક. જો તે બંને કયું સરનામું જોડાયું તે વિશે અસહમત હોય, તો તમે એક વિનંતીના બે પગ જોઈ રહ્યા છો અને ટિકિટે તે કહેવું જોઈએ.
ટનલને દોષ આપતા પહેલા તમારા પોતાના નિયમો તપાસો
ઇરાદાપૂર્વકની નીતિ એ સૌથી સામાન્ય કારણ છે કે પોર્ટ એક નેટવર્ક પર જવાબ આપે છે અને બીજા પર નહીં, અને તે ઉપલબ્ધ સમજૂતીઓમાં સૌથી ઓછી રસપ્રદ છે. એક્સેસ નિયમો એક સ્રોતને પરવાનગી આપવા અને બાકીના કાઢી નાખવા માટે અસ્તિત્વમાં છે, તેથી એગ્રેસમાં ફેરફાર એ બરાબર એ જ ઘટના છે જેના માટે તેઓ લખાયા હતા. તેથી VPN દ્વારા અલગ સ્થિતિ એ સાબિત કરતી નથી કે પ્રદાતા ટ્રાફિકની તપાસ કરે છે. તે બતાવે છે કે તમારું સ્રોત સરનામું હવે અલગ છે, જે ઘણું નાનું નિવેદન છે.
તે નિયમો સર્વર પર વાંચી શકાય છે, તેથી નેટવર્કની મધ્ય વિશે અનુમાન કરવાને બદલે તેમને વાંચો. બેમાંથી કોઈપણ સરનામા શ્રેણીનો ઉલ્લેખ કરતા ફિલ્ટર નિયમોની સૂચિ બનાવો, પછી તપાસો કે કનેક્શન ડેમન સુધી પહોંચ્યું છે કે નહીં:
nft list ruleset | grep -n -e 203.0.113 -e 198.51.100
journalctl -u sshd -n 50 | grep 203.0.113ખાલી બીજું પરિણામ માહિતીપ્રદ છે, કારણ કે ડેમન સુધી કંઈ પહોંચ્યું નથી અને પ્રશ્ન ફિલ્ટર, સિક્યોરિટી ગ્રુપ અથવા પથનો પોતાનો છે. હિટનો અર્થ છે કે સેવાએ તમારો સ્રોત જોયો અને તેનો જવાબ પસંદ કર્યો, અને તે નિર્ણય સામાન્ય રીતે એવા નિયમમાં લખેલો હોય છે જે તમે વાંચી શકો. બંમાંથી કોઈ પરિણામ પ્રદાતા વિશેની વાર્તાને સમર્થન આપતું નથી, અને બંનેને પેકેટ કેપ્ચર કરતાં સસ્તાઈમાં ચકાસી શકાય છે.
ટ્રાન્સપોર્ટ, પ્રમાણપત્ર અને પ્રતિભાવ અલગ વાંચો
ત્રણ સ્તરો ત્રણ નિરીક્ષણો ઉત્પન્ન કરે છે, અને તેમાંથી એકની પરીક્ષા કરતો પ્રોબ બાકીના બે વિશે અહેવાલ આપી શકતો નથી. તેમને રેકોર્ડમાં અલગ લાઇન તરીકે રાખો, એક જ ચુકાદામાં વાળવાને બદલે, કારણ કે દરેક લાઇન પોતાની રીતે નિષ્ફળ જાય છે અને નિષ્ફળતાની રીત જણાવે છે કે આગળ ક્યાં જોવું.
| Observation | What it settles | What it leaves open |
|---|---|---|
| Connection completed | A host on the path accepted the handshake | Which host, and whether its upstream is reachable |
| Certificate valid for the name | The endpoint holds a credential for that name | Whether the process behind it is the one you meant |
| Expected response body | The application handled the request | Anything about other ports or other paths |
| Connection refused | A host replied and nothing was listening | Whether a filter sits ahead of the refused port |
| Timeout | No reply arrived before the deadline | Drop, blackhole route or an overloaded host |
એક આદેશ તમે નિયંત્રિત કરો છો તેવી સેવા સામે પ્રથમ ત્રણ પંક્તિઓ ઉત્પન્ન કરે છે. તેનું આઉટપુટ ચેટ સંદેશમાં નહીં, સ્કેનની બાજુમાં રેકોર્ડમાં મૂકો:
curl -v --resolve office.example:443:203.0.113.20 https://office.example/આઉટપુટ ક્રમમાં વાંચો: હેન્ડશેક ટ્રાન્સપોર્ટ પ્રશ્નનો જવાબ આપે છે, પ્રમાણપત્રનો વિષય નામના પ્રશ્નનો જવાબ આપે છે, અને પ્રતિભાવનું શરીર એપ્લિકેશનના પ્રશ્નનો જવાબ આપે છે. જ્યારે હેન્ડશેક લાઇન સફળ થાય અને પ્રતિભાવ લાઇન ન થાય, ત્યારે તમારી પાસે તૂટેલા અપસ્ટ્રીમ સાથેનું ફ્રન્ટએન્ડ છે, બ્લોક થયેલો પોર્ટ નહીં. તે તમે ખોલેલી ટિકિટ કરતાં અલગ ટિકિટ છે, અને તે સ્પષ્ટ કહેવા જેવું છે.
ટિકિટમાં ચાર હકીકતો લખીને પૂરું કરો: સ્રોત સરનામું, સ્કેનનો પ્રકાર, જવાબ આપનાર હોસ્ટ અને સમય. પછીથી સરખામણી માટે જે કંઈ જોઈએ તે એ ચારમાં જ રહે છે, અને આગળ કેસ ઉપાડનાર પાસે તમારો ટર્મિનલ ઇતિહાસ હશે નહીં. જો તમે ચારેય ભરી શકતા નથી, તો રન પૂરો થયો નથી.