Kodėl jūsų URL reikia įėjimo per 80 arba 443 prievadą, o ne 45000

Įveskite prieglobos vardą naršyklėje, ir schema nusprendžia paskirties prievadą: 80 http, 443 https. Niekas DNS atsakyme to nepanaikina, ir jokia peradresavimo taisyklė jūsų kompiuteryje negali išrasti klausytojo teikėjo krašte. Kai VPN teikėjas duoda jums aukštą viešą prievadą, pavyzdžiui, 45000, aiškus URL veikia, o tvarkingas ne. Spraga yra įėjimo taške, o ne programos viduje.

Pereikite kelią nuo naršyklės iki proceso vieną kartą, ir trys publikavimo parinktys nustos atrodyti paslaptingai.

Pažiūrėkite, kur užklausa iš tikrųjų eina

Naršyklė išsprendžia vardą į adresą, tada jungiasi prie to adreso schemos numatytuoju prievadu, jei URL nenurodo kito. Jūsų teikėjo kraštas nusprendžia, kas nutinka atvykstančiam ryšiui. Jei jo peradresavimo lentelė tik 45000 susieja su jūsų vidiniu adresu, ryšys į 80 neturi kur eiti ir atmetamas arba numetamas dar prieš jūsų kompiuteriui įsitraukiant.

Tas atmetimas įvyksta krašte, todėl jūsų programos žurnalai nieko nerodo. Žurnalų nebuvimas yra įrodymas, kur paketas sustojo, o ne įrodymas, kad programa sugedusi.

Kodėl vietinė taisyklė negali sutvarkyti krašto

Peradresavimas arba DNAT taisyklė programos priegloboje veikia jau atvykusius paketus. Paketai, išsiųsti į 80 prievadą pas teikėją, niekada neatvyksta, todėl taisyklė niekada nevertinama. Tai dažniausiai prarandama valanda visoje problemoje.

DNS taip pat negali pernešti prievado. HTTP specifikacija apibrėžia schemos numatytąsias reikšmes, o A arba AAAA įrašas grąžina adresą, tuo tarpu CNAME grąžina kitą vardą. Naršyklė vis tiek prijungia schemos prievadą, todėl tik aiškus prievadas URL pakeičia paskirties vietą.

Pirmoji parinktis: palikti aiškų prievadą

Dažnai teisingas atsakymas yra neįmantrus. Paskelbkite visą URL su prievadu, užbaikite TLS įėjime, kuris tai palaiko, ir įsitikinkite, kad kiekviena sugeneruota nuoroda išlaiko tą pačią kilmę. Mažai, kontroliuojamai auditorijai to pakanka, ir tai nieko nekainuoja, išskyrus matomą prievado numerį.

Patikrinkite peradresavimus ir slapukų apimtį, kol ten esate, nes backend, kuris į Location antraštę įrašo savo prieglobos vardą, panaikina šią tvarką.

Antroji parinktis: gauti tikrą įėjimą numatytuoju prievadu

Kai kurie teikėjai ir prieglobos sprendimai peradresuoja 80 ir 443 bendru arba dedikuotu adresu kaip dokumentuotą paslaugą. Paklauskite, kas iš tikrųjų įtraukta, o ne darykite prielaidos, kad viešas išėjimo adresas reiškia savavališkus įeinančius prievadus. Dedikuotas išėjimo adresas nieko nesako apie įeinantį peradresavimą.

Patvirtinkite nuosavybę ir prieinamumą raštu, įskaitant tai, kas nutinka įėjimui, kai tunelis vėl prisijungia kitu adresu. Įėjimas, kuris juda kartu su tuneliu, sukelia sutrikimus, kurie atrodo kaip DNS gedimai.

Trečioji parinktis: priekyje pastatyti frontend

Atvirkštinis proxy pasiekiamu adresu gali klausytis 443 ir užbaigti TLS ir atidaryti atskirą ryšį su backend per VPN. Lankytojai mato frontend vardą ir numatytąjį prievadą, o frontend jūsų vardu kalba su backend aukštu prievadu. Tai veikia, nes keičia architektūrą, o ne kovoja su įėjimo tašku. Tada backend visai nereikia įeinančio prievado viešajame internete.

Tai keičia ir tai, ką valdote. Frontend valdo viešą TLS, prieigos politiką, žurnalus ir prieinamumą, ir jis turi apriboti backend pasirinkimą numatytąja paslauga. Jei šuolis nuo frontend iki backend naudoja HTTPS, išlaikykite sertifikato tikrinimą tame šuolyje.

Išlaikykite vieną kilmę

Viešas frontend prieglobos vardas, schema ir prievadas sudaro kilmę, kurią naudoja lankytojai, todėl sukonfigūruokite programos išorinį URL, peradresavimus ir slapukus tai kilmei. Siųskite originalų prieglobos vardą ir persiųstą schemą, jei programa kuria absoliučias nuorodas. Atsakymas, kuris nukreipia naudotojus į privatų vardą ar aukštą prievadą, panaikina ką tik sukurtą tvarkingą įėjimą.

Tada nuspręskite atsižvelgdami į auditoriją. Trumpas URL gali pateisinti valdomą frontend, ir neverta atsitiktinai paversti privataus tik VPN skirto serviso viešu.