Сокеттик теңдеш же кайра жөнөтүлгөн аталыш: кайсы дарекке ишенүү керек?

Колдонмого келген суроо дарек жөнүндө эки түрдүү далил алып келет: тармактык байланышты ачкан теңдеш жана мурунку кардардын дарегин билдирген 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 тизмени өзүнүн ишенимдүү топтомуна каршы артка жүрүп, өзүнө таандык эмес биринчи даректе токтой алат, жана бул ошол продукттун эрежеси, ар бир фреймворк ээрчүүчү мыйзам эмес. Өз проксиңиздин документтерин ушул эки суроо менен окуңуз: ал кайсы маанини тандайт жана кайсы жөнөтүүчүлөргө ишенет?

Тизмекти жазып алыңыз: секирик тартиби, кайсы секирик талааны коёт жана кайсы секирик кирүүчү көчүрмөлөрдү алып салат. Анан ошол жазууну билетте эмес, прокси конфигурациясынын жанында кармаңыз. Анан аны бекитилген текшерүү процесси аркылуу жасалма аталыш менен суроо жөнөтүп, булак аны этибарга албастыгын ырастоо менен сынаңыз.

Секирик кошкондо, ошол документти кайра карап чыгыңыз. Ишенимдүү проксинин алдына коюлган жаңы жүктөм теңдегичи эч ким колдонмону оңдобостон эле кайсы дарек жеңеэрин өзгөртө алат.

Эки байкоону тең журналда сактаңыз

Диагностикага уруксат берилген жерде байланыштын теңдешин жана нормалдаштырылган кардар дарегин эки өзүнчө талаа катары жазыңыз, жана максатка чындап керек болгон кайра жөнөтүү метаберилиштерин гана кошуңуз. Анан жайгаштырууну эки суроо менен далилдеңиз: экөөнү тең акылга сыярлык жазышы керек прокси аркылуу келген суроо жана булакка түз багытталган, четке кагышы керек аракет.

Бул жуп эмнени билдирерин унутпаңыз. Аталыш сиз ишенүүгө тандаган компонент берген контекстти кошот; теңдеш хостүңүз чындап көргөн жалгыз дарек бойдон калат. Экөө тең жеке инсандыктын далили эмес, жана кайсынысын болбосун далил деп эсептеген долбоор бирөө жөнүндө жаңылат.