Сокеттік теңдес немесе қайта жіберілген тақырып: қай мекенжайға сену керек?

Сокеттік теңдес пен қайта жіберілген тақырып — екі түрлі дәлел. Әрқайсысы нені дәлелдейтінін салыстырыңыз, ал тақырыпқа тек өзіңіз басқаратын прокси тізбегі арқылы сеніңіз.

Қолданбаңызға келетін сұрау мекенжай туралы екі түрлі дәлел әкеледі: желілік қосылымды ашқан теңдес және бұрынғы клиенттің мекенжайын мәлімдейтін HTTP өрісі. Олар әртүрлі сұрақтарға жауап береді. Сокеттік теңдес бақыланады, ал тақырыпты оны жазған адам мәлімдейді, және ешқайсысы журналда немесе қатынау ережесінде екіншісін үнсіз алмастырмауы керек. Төмендегі салыстыру оларды бөлек ұстайды, содан кейін тақырып пайдалы болатын жалғыз құрылымды көрсетеді.

Бірдеңені салыстырмас бұрын жолды сипаттаңыз:

Client -> approved reverse proxy -> application origin

Бұл құрылымда түпнұсқаның сокеттік теңдесі әдетте прокси болады, ал қайта жіберу тақырыбы проксидің клиент туралы мәлімдемесін тасымалдай алады. Оның құндылығы сол проксимен бақыланатын қатынастан келеді, тақырыптың атынан емес.

Мекенжай туралы екі түрлі дәлел

Сокеттік теңдес — бір TCP қосылымы туралы факт: бірдеңе сол мекенжайдан қол алысуды аяқтады. Ол міндетті түрде сізге қымбат адам, құрылғы немесе аккаунт емес, өйткені VPN немесе Tor шығуы қызмет бақылайтын көз бола алады. Бірақ ол хосттың өзі растаған жалғыз мекенжай болып қалады, және оның бүкіл құндылығы осында.

Қайта жіберу өрісі — тізбек туралы метадеректер. X-Forwarded-For, X-Real-IP және стандартталған өріс Forwarded оларды қайтаратын соңғы нүктеге жеткен кез келген клиент жаза алады, сондықтан олардың сенімділігі оларды орнатуға кімге рұқсат берілгеніне толығымен байланысты.

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

Тақырып қосылымды ешқашан қайта бағыттамайды

Қайта жіберу өрісіне мекенжай жазу серверге келетін TCP қосылымының көзін өзгертпейді және жолдың ешбір жерінде маршруттауды өзгертпейді. Кәдімгі VPN маршруттауы немесе көз NAT трафикті ешқандай HTTP тақырыбынсыз жеткізеді. Сол сияқты, транзиттік қақпа TLS соңғы нүктесінің құрылымын өзгертпей дұрыс қорғалған HTTPS алмасуын қайта жазбайды.

Кері қате де сондай жиі: HTTPS клиент берген қайта жіберу тақырыбын шындыққа айналдырмайды. Ол жалған мәлімдемені тасымалдауды шынайыдан кем қорғамайды.

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

Мәлімдеуге рұқсат берілген проксиді атаңыз

Екі ереже қайта жіберу өрісін пайдалы етеді, және екеуі де код емес, конфигурация. Шет сырттан келетіннің бәрін сол өрістер үшін өзінің құжатталған мінез-құлқына сәйкес қалыпқа келтіреді немесе тастайды. Содан кейін түпнұсқа ауыстыру мекенжайын сіз атаған прокси жолынан алады, басқа жерден емес. Екінші ереже клиенттер түпнұсқаға басқа жолмен жете алмағанша ғана күшінде, өйткені тікелей де, прокси арқылы да келетін сұрауларға жауап беретін түпнұсқа қайсысына қызмет етіп жатқанын білмейді.

NGINX-тің нақты IP модулі бөлінуді анық көрсетеді. set_real_ip_from мәлімдемесі есепке алынатын жіберушілерді атайды, және real_ip_header қай өріс оны тасымалдайтынын айтады; біріншісі сенімді жүзеге асырады, екіншісі тек қайда қарауды айтады.

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

Тек тақырып таңдау нұсқаулығы өздігінен мәнді кім жібергені туралы әлі ештеңе орнатпайды.

Тасымал қауіпсіздігі сіз сенетін компоненттер арасында бүкіл жолды жүруі керек. Дұрыс қалыпқа келтіретін шет сол құндылықты төмендегі қорғалмаған секіріс біреуге мәлімдемені жолда өңдеуге мүмкіндік берген сәтте жоғалтады.

Көп секірісті тізбектерді әдейі басқарыңыз

Бірнеше прокси айқын тізбек моделін қажет етеді. Қандай да бір блог жазбасы солай істеді деп үтірмен бөлінген ең сол немесе ең оң мәнді алмаңыз; проксилеріңіздің қайсысы қосатынын, қайсысы алмастыратынын және қайсысы кіріс өрісін сақтайтынын анықтаңыз. Мысалы, NGINX тізімді өзінің сенімді жиынына қарсы кері жүріп, өзіне тиесілі емес бірінші мекенжайда тоқтай алады, және бұл сол өнімнің ережесі, әр фреймворк ұстанатын заң емес. Өз проксиіңіздің құжаттамасын дәл осы екі сұрақпен оқыңыз: ол қай мәнді таңдайды және қай жіберушілерге сенеді?

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

Секіріс қосқанда, сол құжатты қайта қарап шығыңыз. Сенімді проксидің алдына қойылған жаңа жүктеме теңгергіші ешкім қолданбаны өңдемей-ақ қай мекенжай жеңетінін өзгерте алады.

Екі бақылауды да журналда сақтаңыз

Диагностикаға рұқсат берілген жерде қосылым теңдесін және қалыпқа келтірілген клиент мекенжайын екі бөлек өріс ретінде жазыңыз, және мақсатқа шынымен қажет қайта жіберу метадеректерін ғана қосыңыз. Содан кейін орналастыруды екі сұраумен дәлелдеңіз: екеуін де ақылға қонымды жазуы тиіс прокси арқылы келген сұрау және түпнұсқаға тікелей бас тартылуы тиіс әрекет.

Бұл жұптың нені білдіретінін есте сақтаңыз. Тақырып сіз сенуге таңдаған компонент беретін контекстті қосады; теңдес хостыңыз шын мәнінде көрген жалғыз мекенжай болып қалады. Екеуі де жеке тұлғаның сәйкестігін дәлелдеу емес, және қайсысын да дәлел деп санайтын дизайн біреу туралы қателеседі.

Қатысты мақалалар