Miksi URL-osoitteesi tarvitsee merkinnän porttiin 80 tai 443, ei porttiin 45000

Kirjoita selaimiin isäntänimi, ja skeema päättää kohdeportin: 80 http:lle, 443 https:lle. Mikään DNS-vastauksessa ei ohita sitä, eikä mikään edelleenohjaussääntö koneellasi voi keksiä kuuntelijaa palveluntarjoajan reunalla. Kun VPN-palveluntarjoaja antaa sinulle korkean julkisen portin kuten 45000, eksplisiittinen URL toimii ja puhdas ei. Aukko on sisääntulopisteessä, ei sovelluksen sisällä.

Käy polku selaimesta prosessiin kerran läpi, niin kolme julkaisuvaihtoehtoa lakkavat näyttämästä salaperäisiltä.

Katso, mihin pyyntö oikeasti menee

Selain selvittää nimen osoitteeksi ja yhdistää sitten siihen osoitteeseen skeeman oletusportilla, ellei URL nimeä toista. Palveluntarjoajasi reuna päättää, mitä saapuvalle yhteydelle tapahtuu. Jos sen edelleenohjaustaulukko kuvaa vain 45000:n sisäiseen osoitteeseesi, yhteydellä porttiin 80 ei ole minne mennä, ja se hylätään tai pudotetaan ennen kuin koneesi on edes mukana.

Tuo hylkäys tapahtuu reunalla, minkä vuoksi sovelluksesi lokit eivät näytä mitään. Lokien puuttuminen on todiste siitä, mihin paketti pysähtyi, ei todiste siitä, että sovellus on rikki.

Miksi paikallinen sääntö ei voi korjata reunaa

Uudelleenohjaus tai DNAT-sääntö sovelluksen isännässä vaikuttaa paketteihin, jotka ovat jo saapuneet. Palveluntarjoajalla porttiin 80 lähetetyt paketit eivät koskaan saavu, joten sääntöä ei koskaan arvioida. Tämä on koko ongelman yleisin hukattu tunti.

DNS ei voi kuljettaa porttia myöskään. HTTP-määrittely määrittelee skeeman oletukset, ja A- tai AAAA-tietue palauttaa osoitteen, kun taas CNAME palauttaa toisen nimen. Selain liittää yhä skeeman portin, joten vain URL:ssa oleva eksplisiittinen portti muuttaa kohdetta.

Vaihtoehto yksi: pidä eksplisiittinen portti

Usein oikea vastaus on tylsä. Julkaise täysi URL portin kanssa, lopeta TLS merkinnässä, joka tukee sitä, ja varmista, että jokainen luotu linkki säilyttää saman alkuperän. Pienelle, valvotulle yleisölle tämä on täydellinen, eikä se maksa mitään näkyvän portinumeron lisäksi.

Tarkista uudelleenohjaukset ja evästeiden laajuus siellä ollessasi, koska backend, joka kirjoittaa oman isäntänimensä Location-otsakkeeseen, kumoaa järjestelyn.

Vaihtoehto kaksi: hanki oikea oletusportin merkintä

Jotkin palveluntarjoajat ja hosting-järjestelyt välittävät 80:n ja 443:n jaetussa tai omistetussa osoitteessa dokumentoituna palveluna. Kysy, mitä todella sisältyy, sen sijaan että olettaisit julkisen lähtöosoitteen tarkoittavan mielivaltaisia saapuvia portteja. Omistettu lähtöosoite ei kerro mitään saapuvasta välityksestä.

Vahvista omistus ja saatavuus kirjallisesti, mukaan lukien mitä merkinnälle tapahtuu, kun tunneli yhdistyy uudelleen eri osoitteeseen. Tunnelissa mukana liikkuva merkintä aiheuttaa katkoksia, jotka näyttävät DNS-vioilta.

Vaihtoehto kolme: laita frontend eteen

Käänteinen proxy saavutettavassa osoitteessa voi kuunnella portissa 443 ja päättää TLS ja avata erillisen yhteyden backendiin VPN:n yli. Vierailijat näkevät frontendin nimen ja oletusportin, kun taas frontend puhuu backendin korkealle portille puolestasi. Tämä toimii, koska se muuttaa arkkitehtuuria sen sijaan että taistelisi sisääntulopistettä vastaan. Backend ei silloin tarvitse lainkaan saapuvaa porttia julkisessa internetissä.

Se muuttaa myös sitä, mitä ylläpidät. Frontend omistaa julkisen TLS:n, käyttöoikeuskäytännön, lokit ja saatavuuden, ja sen on rajoitettava backendin valinta aiottuun palveluun. Jos hyppy frontendista backendiin käyttää HTTPS:ää, pidä varmenteen vahvistus siinä hypyssä.

Pidä yksi alkuperä

Frontendin julkinen isäntänimi, skeema ja portti muodostavat alkuperän, jota vierailijat käyttävät, joten määritä sovelluksen ulkoinen URL, uudelleenohjaukset ja evästeet sille alkuperälle. Lähetä alkuperäinen isäntä ja välitetty skeema, jos sovellus rakentaa absoluuttisia linkkejä. Vastaus, joka pomppaa käyttäjät yksityiseen nimeen tai korkeaan porttiin, kumoaa juuri rakentamasi puhtaan merkinnän.

Päätä sitten yleisö mielessäsi. Lyhyt URL voi perustella hallinnoidun frontendin, eikä kannata vahingossa muuttaa yksityistä vain VPN:lle tarkoitettua palvelua julkiseksi.