કેમ Port-Share બધા વેબસાઇટ મુલાકાતીઓને localhost જેવા દેખાય છે

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

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

લોગ લાઇન નહીં, બે કનેક્શનને અનુસરો

Port-Share એક TCP શ્રોતા પર બે પ્રોટોકોલ મલ્ટિપ્લેક્સ કરે છે. OpenVPN આવતા કનેક્શનના પ્રથમ બાઇટ્સ તપાસે છે, જ્યારે તે પોતાના પ્રોટોકોલ જેવું લાગે ત્યારે તેને રાખે છે, અને બાકીનું બધું બીજા ગંતવ્યને સોંપે છે. એ ગંતવ્ય સામાન્ય રીતે એ જ હોસ્ટ પરનું વેબ સર્વર હોય છે, તેથી વેબ સર્વરના સ્વીકૃત સોકેટનો સાથી OpenVPN પ્રક્રિયા હોય છે.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

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

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

ટ્રાન્સપોર્ટ ફોરવર્ડિંગ એ હેડર ઇન્જેક્શન નથી

ફોરવર્ડર બાઇટ્સ ખસેડે છે. તે HTTP પાર્સ કરતું નથી, તેથી જે વિનંતીને કદી વિનંતી તરીકે વાંચતું નથી તેમાં હેડર દાખલ કરી શકતું નથી, અને જે TLS સ્ટ્રીમને અસ્પૃષ્ટ પસાર કરે છે તેમાં કંઈ ઉમેરી શકતું નથી. પ્રોક્સી હેડરની અપેક્ષા રાખતું મોડ્યુલ એવી હેડરની રાહ જોતું રહેશે જે કોઈ ઘટક ઉત્પન્ન કરતું નથી.

બે મિકેનિઝમ મૂળ સરનામું લઈ જઈ શકે છે, અને બંનેને બંને છેડે સંમતિની જરૂર છે. PROXY પ્રોટોકોલ કનેક્શનની શરૂઆતમાં નાનું હેડર ઉમેરે છે, અને બેકએન્ડ તેની અપેક્ષા રાખવા માટે ગોઠવાયેલું હોવું જોઈએ; જે બેકએન્ડ તેની અપેક્ષા રાખતું નથી તે એ બાઇટ્સને વિનંતીની શરૂઆત ગણશે અને ગૂંચવણભરી રીતે નિષ્ફળ જશે. X-Forwarded-For જેવા વિશ્વસનીય પ્રોક્સી હેડર ત્યારે કામ કરે છે જ્યારે HTTP સમજતું પ્રોક્સી તેમને સેટ કરે અને બેકએન્ડને કહેવામાં આવે કે કયા સાથીઓ તેમનો દાવો કરી શકે.

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

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

વૈકલ્પિક સ્રોત-મેપિંગ ડિરેક્ટરી

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

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

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

સરનામાની ગેરંટી કયો ઘટક આપે તે નક્કી કરો

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

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

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

નિયમની કસોટી કરો, પૃષ્ઠની નહીં

લોડ થતું પૃષ્ઠ સાબિત કરે છે કે ફોરવર્ડિંગ માર્ગ કામ કરે છે અને એટ્રિબ્યુશન વિશે કંઈ કહેતું નથી. સરનામાના ઉપભોક્તાની કસોટી કરો: એક્સેસ નિયમ, દર મર્યાદા, ઓડિટ એન્ટ્રી, ભૌગોલિક શોધ.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

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

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