Эмне үчүн URL 45000 эмес, 80 же 443 портунан кирүүнү талап кылат

Браузерге хост атын жазыңыз, схема багытталган портту аныктайт: http үчүн 80, https үчүн 443. DNS жообунда эч нерсе муну жокко чыгарбайт жана машинаңыздагы эч бир багыттоо эрежеси провайдердин четине угуучуну ойлоп таба албайт. VPN провайдери сизге 45000 сыяктуу бийик жарыя портун берсе, ачык URL иштейт, тазасы иштебейт. Ажырым кирүү чекитинде, колдонмонун ичинде эмес.

Браузерден процессорго чейинки жолду бир жолу карап чыгыңыз, ошондо үч жарыялоо варианты сырдуу болуп көрүнбөйт.

Сурам чындыгында кайда бараарын караңыз

Браузер атты дарекке чечет, анан URL башка портту атабаса, схеманын демейки порту менен ошол дарекке туташат. Келген туташууга эмне болорун провайдериңиздин чети чечет. Эгер анын багыттоо таблицасы 45000ди гана ички дарегиңизге далдаштаса, 80ге туташуунун барар жери жок жана машинаңыз катышканга чейин эле четке кагылат же ыргытылат.

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

Эмне үчүн жергиликтүү эреже четти оңдой албайт

Колдонмо хостундагы багыттоо же DNAT эрежеси мурун келген пакеттерге таасир этет. Провайдерде 80 портуна жөнөтүлгөн пакеттер эч качан келбейт, ошондуктан эреже эч качан бааланбайт. Бул бүт маселедеги эң көп жоголгон саат.

DNS да портту ташый албайт. HTTP спецификациясы схеманын демейкилерин аныктайт, ал эми A же AAAA жазуусу даректи кайтарат, CNAME болсо башка атты кайтарат. Браузер дагы эле схеманын портун кошот, ошондуктан URLдеги ачык порт гана багытты өзгөртөт.

Биринчи вариант: ачык портту сактоо

Көбүнчө туура жооп көзгө урунбаган вариант болот. Порт менен толук URLди жарыялаңыз, TLSти аны колдогон кирүүдө бүтүрүңүз жана ар бир жаралган шилтеме ошол эле келип чыгууну сактаарына ынаныңыз. Кичине, көзөмөлдөнгөн аудитория үчүн бул толук жана көрүнгөн порт номеринен башка эч нерсе турбайт.

Ошол жерде турганда багыттоолорду жана cookie аймагын текшериңиз, анткени өз хост атын Location аталышына жазган backend бул жөндөөнү жокко чыгарат.

Экинчи вариант: демейки портто чыныгы кирүү алуу

Айрым провайдерлер жана хостинг чечимдери 80 менен 443тү документтелген кызмат катары жалпы же атайын дарекке багыттайт. Жарыя чыгуу дареги каалаган кирүү портторун билдирет деп болжолдоонун ордуна, чындыгында эмне кирерин сураңыз. Атайын чыгуу дареги кирүү багыттоосу жөнүндө эч нерсе айтпайды.

Ээликти жана жеткиликтүүлүктү жазуу жүзүндө ырастаңыз, анын ичинде туннель башка дарек менен кайра туташканда кирүүгө эмне болорун. Туннел менен бирге жылышкан кирүү DNS бузулуштарына окшош тыныгууларды жаратат.

Үчүнчү вариант: алдыга frontend коюу

Жеткиликтүү даректеги тескери прокси 443тө угуу жана TLSти бүтүрүү жана VPN аркылуу backendге өзүнчө туташуу ача алат. Келүүчүлөр frontendдин атын жана демейки портун көрүшөт, ал эми frontend сиздин атыңыздан backendдин бийик порту менен сүйлөшөт. Бул архитектураны өзгөрткөндүктөн иштейт, кирүү чекити менен күрөшпөйт. Анда backendге жарыя интернетте кирүү порту таптакыр керек эмес.

Бул сиз башкарган нерсени да өзгөртөт. frontendге жарыя TLS, кирүү саясаты, журналдар жана жеткиликтүүлүк таандык жана ал backend тандоосун көздөлгөн кызмат менен чектеши керек. frontendден backendге секирик HTTPS колдонсо, ошол секирикте сертификат текшерүүсүн сактаңыз.

Бир келип чыгууну сактаңыз

frontendдин жарыя хост аты, схемасы жана порту келүүчүлөр колдонгон келип чыгууну түзөт, ошондуктан колдонмонун тышкы URLин, багыттоолорун жана cookieлерин ошол келип чыгууга конфигурациялаңыз. Колдонмо абсолюттук шилтемелерди куруса, баштапкы хостту жана жөнөтүлгөн схеманы жөнөтүңүз. Колдонуучуларды жеке атка же бийик портко кайтарган жооп жаңы эле курулган таза кирүүңүздү жокко чыгарат.

Анан аудиторияны ойлоп чечим кабыл алыңыз. Кыска URL башкарылуучу frontendди актай алат жана VPN үчүн гана жасалган жеке кызматты байкабастан жарыя кызматка айландырууга татыбайт.