Эмне үчүн 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
Уруксат берилген тышкы сурамды фронтенд жана бэкенд жазууларынын экөө менен салыштырып, баш тартышы керек эреже дагы эле баш тартарын жана уруксат бериши керек эреже дагы эле уруксат берерин ырастаңыз. Эгер журнал сабы туура болсо, бирок эреже дагы эле бардыгын жергиликтүү деп кармаса, эреже сиз оңдогон талаадан башка талааны окуйт.
Жайгаштыруу жазууларына каттоо чынжырын жазуу менен бүтүрүңүз: кайсы угуучу, кайсы кайра жиберүүчү, кайсы аталыш же карталоо жана кайсы бэкенд ага ишенүүгө конфигурацияланган. Журнал сабын окуган кийинки адамга төртөө тең керек болот, ал эми ошол жазуунун жоктугу бир жылдан кийин ошол эле билеттин кайра ачылышынын себеби. Аны чат агымында эмес, конфигурациянын жанында сактаңыз.