Неге 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

Рұқсат етілген сыртқы сұранысты фронтенд пен бэкенд жазбаларының екеуімен де салыстырып, бас тартуы тиіс ереженің әлі де бас тартатынын және рұқсат етуі тиіс ереженің әлі де рұқсат ететінін растаңыз. Егер журнал жолы дұрыс болса, бірақ ереже әлі де бәрін жергілікті деп ұстаса, ереже сіз түзеткен өрістен басқа өрісті оқиды.

Телімдеу тізбегін орналастыру жазбаларына жазумен аяқтаңыз: қай тыңдаушы, қай қайта жіберуші, қай тақырыпша немесе салыстыру және қай бэкенд оған сенуге конфигурацияланған. Журнал жолын оқитын келесі адамға төртеуі де қажет болады, ал сол жазбаның болмауы бір жылдан кейін сол билеттің қайта ашылуының себебі. Оны чат ағынында емес, конфигурацияның қасында ұстаңыз.