VPN ક્લાયંટ માટે NGINX કયું સ્રોત સરનામું લોગ કરશે?
એક જ હોસ્ટ પર OpenVPNની બાજુમાં NGINX શું જુએ છે તે નક્કી કરો: આંતરિક ટનલ સરનામું, જાહેર બહાર જવાનું સરનામું કે ફોરવર્ડ કરેલ પીઅર, લીધેલા માર્ગના આધારે.
એક જ હોસ્ટ પર NGINX અને OpenVPN સેટઅપમાં ત્રણ ક્લાયંટ સરનામાં દેખાય છે, જેમાંથી દરેક વિનંતી લઈ શકે તેવા એક માર્ગ માટે એક. ટનલ સરનામે પહોંચતું બ્રાઉઝર, જાહેર સરનામે પહોંચતું બ્રાઉઝર અને ગેટવેના ઇન્ટરનેટ માર્ગેથી નીકળતો પ્રોગ્રામ, બધા સાંભળતા સોકેટ પર અલગ દેખાય છે. લોગ લીટી અર્થઘટન કરતા પહેલાં નક્કી કરો કે તમે કયો માર્ગ જોઈ રહ્યા છો. નિર્ણય ક્લાયંટે વાપરેલા લક્ષ્ય પર, બહારના VPN એન્ડપોઇન્ટ માટે તેની પાસેના અપવાદ પર અને માર્ગમાં કંઈ પેકેટનું ભાષાંતર કરે છે કે નહીં તેના પર આધાર રાખે છે.
લક્ષ્ય પ્રમાણે નિર્ણય કરો, વપરાશકર્તા કોણ છે તે પ્રમાણે નહીં
જે સરનામે વિનંતી મોકલાઈ હતી તેનાથી શરૂ કરો, કારણ કે તે સરનામું માર્ગ પસંદ કરે છે. હોસ્ટના ટનલ સરનામે વિનંતી ટનલ ઇન્ટરફેસ પર ક્લાયંટના આંતરિક સરનામા સાથે સ્રોત તરીકે આવે છે. હોસ્ટના જાહેર સરનામે વિનંતી સામાન્ય રીતે ઇન્ટરનેટ તરફના ઇન્ટરફેસ પર ક્લાયંટના જાહેર સરનામા સાથે આવે છે, જ્યારે એ જ લેપટોપ પર તે ક્ષણે ટનલ સ્થાપિત હોય ત્યારે પણ. તેથી VPN પૂલમાં સભ્યપદ પેકેટના માર્ગની લાક્ષણિકતા છે, વપરાશકર્તાને અનુસરતી લાક્ષણિકતા નહીં.
| Path the request took | Source the site normally records |
|---|---|
| Client reaches the site at its tunnel address, 10.24.0.1 | Client inner address, 10.24.0.20 |
| Client reaches another internet site through the gateway | Gateway public egress address, 192.0.2.44 |
| Client reaches the gateway's public address through the endpoint exception | Client's own public access address |
જ્યારે લોગમાં ટનલ સાથે કોઈ સંબંધ ન હોય તેવા સરનામા સાથે VPN વપરાશકર્તા દેખાય ત્યારે પહેલાં આ ત્રીજી હરોળ ચકાસવા લાયક છે. તે એ પણ સમજાવે છે કે એક જ પ્રોફાઇલ પરના બે વપરાશકર્તા અલગ એન્ટ્રી કેમ બનાવી શકે: તેમના પોતાના એક્સેસ નેટવર્ક અલગ છે, અને ટનલમાં કંઈ તેના પર ફરી લખતું નથી.
બહારનું એન્ડપોઇન્ટ બીજો જાહેર માર્ગ કેમ બનાવે છે
ક્લાયંટે ટનલ સ્થાપિત કરવા માટે ગેટવેના જાહેર સરનામે પહોંચવું પડે, તેથી તે સરનામા તરફનો માર્ગ ટનલની બહાર હોવો જોઈએ. જ્યારે ક્લાયંટ બધો ટ્રાફિક અંદર તરફ વાળે છે, ત્યારે સમજદાર અમલ સર્વરના જાહેર સરનામા માટે સ્પષ્ટ હોસ્ટ રૂટ રાખે છે જેથી પોતાના પર આધારિત ટનલ ટાળી શકાય. તે અપવાદ સેવાઓ અંગે પસંદગી કરતો નથી, તેથી એ જ જાહેર સરનામે જતી કોઈપણ વિનંતી તેને અનુસરે છે, ગેટવે પર હોસ્ટ કરેલી સાઇટ માટે બ્રાઉઝરની વિનંતી પણ સહિત.
આ ક્ષેત્રની મોટાભાગની ગૂંચવણભરી આંકડાઓ પાછળની પ્રક્રિયા આ છે, અને તે સર્વરને બદલે ક્લાયંટના અમલ પર આધાર રાખે છે. તેથી એક સરખી પ્રોફાઇલ ધરાવતા બે ક્લાયંટ અલગ વર્તી શકે છે. લોગ »સુધારવા« માટે અપવાદ દૂર કરવાથી ટનલ પણ સાથે પડી જાય છે, તેથી તેને રાખો અને તેની આસપાસ રચના કરો.
સોકેટ, ટેબલ અને લોગ ફોર્મેટ સાથે વાંચો
ત્રણ અવલોકનો નક્કી કરે છે કે તમે કયો માર્ગ જોઈ રહ્યા છો: સોકેટ ક્યાં સાંભળે છે, કયું ઇન્ટરફેસ લક્ષ્યનો જવાબ આપે છે અને લોગ ફોર્મેટ ખરેખર શું નોંધે છે. જો શ્રોતા ફક્ત ટનલ સરનામા સાથે જ બંધાયેલો હોય, તો જાહેર વિનંતી ત્યાં પહોંચી જ શકતી નથી, જે તરત જ બે હરોળ કાઢી નાખે છે. જો ક્લાયંટ માટેની શોધ ટનલ ઉપકરણ પરત કરે છે, તો વિનંતી આંતરિક સ્રોત સાથે આવી છે અને લોગ તે દર્શાવવો જોઈએ.
ss -lntp 'sport = :443'
ip route get 10.24.0.20
ip route get 192.0.2.44પછી લીટીને બદલે ફોર્મેટ વાંચો. ફોરવર્ડ કરેલ હેડરથી ભરાતું ક્ષેત્ર દાવો નોંધે છે, સોકેટ પીઅર નહીં, અને દાવો ત્યારે જ મહત્વનો છે જ્યારે તાત્કાલિક પીઅર વિશ્વસનીય પ્રોક્સી હોય. બંને મૂલ્યો લોગમાં લખવાથી પછીના વિવાદો નક્કી થાય છે, કારણ કે તાત્કાલિક પીઅર અને બદલાયેલું સરનામું અલગ તથ્યો છે અને તેમાંથી એક જ નેટવર્કમાંથી આવ્યું છે.
log_format tunneled '$remote_addr $realip_remote_addr $request $status';
grep -n 'log_format' /etc/nginx/nginx.confતમારું ઇચ્છિત પ્રવેશ બિંદુ પસંદ કરો અને DNS સહમત કરાવો
જો સાઇટ ફક્ત ટનલ દ્વારા હોવાની હોય, તો તેને એવું નામ આપો જે VPN ક્લાયંટ માટે ટનલ સરનામે ઉકેલાય અને સાંભળતા સોકેટ પર નીતિ લાગુ કરો. આંતરિક નામ માટે 10.24.0.1 પરત કરતો વિભાજિત DNS જવાબ નામ-ઉકેલની વિગતના વેશમાં માર્ગ નક્કી કરવાનો નિર્ણય છે. જો સાઇટ જાહેર પણ હોવી જોઈએ, તો બે નામ કે બે પોર્ટ રાખો અને લોગને કહેવા દો કે કયું વિનંતીને સેવા આપી.
પરવાનગીના નિયમો એ જ તર્કને અનુસરે છે. ટનલ પૂલને પરવાનગી આપવાથી જાહેર વિનંતીને અધિકાર મળતો નથી, અને ઇન્ટરનેટ દ્વારા આવેલા જોડાણ પર આંતરિક સરનામું ભરતું નથી. બંને પ્રવેશ બિંદુઓને એક નામ નીચે ભેગા કરવાથી નોંધાયેલો સ્રોત ડિઝાઇન પસંદગીને બદલે ક્લાયંટ માર્ગની આડઅસર બની જાય છે.
માર્ગ ચકાસો, પછી નીતિ
ગેટવે પર કેપ્ચર અને તમે નિયંત્રિત કરો તે વિનંતીથી માર્ગની પુષ્ટિ કરો. ટનલ ઉપકરણ પરનું કેપ્ચર અને જાહેર ઇન્ટરફેસ પરનું એક દર્શાવે છે કે કયું બાઇટ લઈ ગયું, અને પેકેટનો ક્રમ કહે છે કે તેમની વચ્ચે ભાષાંતર થયું કે નહીં.
tcpdump -ni tun0 port 443 -c 5
tcpdump -ni eth0 port 443 -c 5પછી બંને દિશામાં પ્રવેશ ચકાસો: ઇચ્છિત નામવાળું પ્રવેશ બિંદુ ઇચ્છિત ક્લાયંટ માટે કામ કરે છે, અને મંજૂર ન કરેલો જાહેર માર્ગ ફક્ત ધીમો હોવાને બદલે નકારવામાં આવે છે. સામાન્ય IP-પડઘા સાઇટ ગેટવેના ઇન્ટરનેટ નિકાસ વિશે કંઈક સાબિત કરે છે અને એ જ હોસ્ટ પરની આ સાઇટ વિશે કંઈ નહીં. જ્યારે પૃષ્ઠ અને WebSocket સહમત ન થાય, ત્યારે સર્વર રૂપરેખાંકનને સ્પર્શ કરતા પહેલાં તેમના URL, સરનામા કુટુંબો અને DNS જવાબોની તુલના કરો.