Zakaj vaš URL potrebuje vstop na vratih 80 ali 443, ne na 45000

V brskalnik vpišite ime gostitelja in shema odloči o ciljnih vratih: 80 za http, 443 za https. Nič v odgovoru DNS tega ne razveljavi in nobeno pravilo posredovanja na vašem računalniku ne more na robu ponudnika izmisliti poslušalca. Ko vam ponudnik VPN dodeli visoka javna vrata, na primer 45000, eksplicitni URL deluje, čisti pa ne. Vrzel je na vstopni točki, ne znotraj aplikacije.

Prehodite pot od brskalnika do procesa enkrat in tri možnosti objave ne bodo več videti skrivnostne.

Poglejte, kam zahteva v resnici gre

Brskalnik ime razreši v naslov in se nato poveže s tem naslovom na privzetih vratih sheme, razen če URL navaja druga. Rob vašega ponudnika odloči, kaj se zgodi s prihajajočo povezavo. Če njegova tabela posredovanja preslika samo 45000 na vaš notranji naslov, povezava na 80 nima kam iti in je zavrnjena ali zavržena, preden je vaš računalnik sploh vključen.

Ta zavrnitev se zgodi na robu, zato vaši dnevniški zapisi aplikacije ne kažejo ničesar. Odsotnost zapisov je dokaz o tem, kje se je paket ustavil, ne dokaz, da je aplikacija pokvarjena.

Zakaj lokalno pravilo ne more popraviti roba

Preusmeritev ali pravilo DNAT na gostitelju aplikacije deluje na pakete, ki so že prispeli. Paketi, poslani na vrata 80 pri ponudniku, nikoli ne prispejo, zato pravilo ni nikoli ovrednoteno. To je najpogosteje zapravljena ura v celotnem problemu.

Tudi DNS ne more prenašati vrat. specifikacija HTTP določa privzete vrednosti sheme, zapis A ali AAAA pa vrne naslov, medtem ko CNAME vrne drugo ime. Brskalnik še vedno pripne vrata sheme, zato cilj spremeni le eksplicitna vrata v URL.

Možnost prva: obdržati eksplicitna vrata

Pogosto je pravi odgovor tisti nebleščeči. Objavite celoten URL z vrati, zaključite TLS na vstopu, ki to podpira, in poskrbite, da vsaka ustvarjena povezava ohrani isti izvor. Za majhno, nadzorovano občinstvo je to popolno in ne stane ničesar razen vidne številke vrat.

Medtem ko ste tam, preverite preusmeritve in obseg piškotkov, ker backend, ki v glavo Location zapiše svoje ime gostitelja, razveljavi ureditev.

Možnost druga: pridobiti pravi vstop na privzetih vratih

Nekateri ponudniki in gostiteljske rešitve posredujejo 80 in 443 na skupnem ali namenskem naslovu kot dokumentirano storitev. Vprašajte, kaj je v resnici vključeno, namesto da predpostavljate, da javni izhodni naslov pomeni poljubna vhodna vrata. Namenski izhodni naslov ne pove ničesar o vhodnem posredovanju.

Lastništvo in razpoložljivost potrdite pisno, vključno s tem, kaj se zgodi z vstopom, ko se tunel znova poveže z drugim naslovom. Vstop, ki se premika s tunelom, povzroča prekinitve, ki so videti kot okvare DNS.

Možnost tretja: spredaj postaviti frontend

Povratni proxy na dosegljivem naslovu lahko poslušati na 443 in zaključiti TLS in odpre ločeno povezavo z backendom prek VPN. Obiskovalci vidijo ime in privzeta vrata frontenda, medtem ko se frontend v vašem imenu pogovarja z visokimi vrati backenda. To deluje, ker spremeni arhitekturo, namesto da bi se boril z vstopno točko. Backend potem na javnem internetu sploh ne potrebuje vhodnih vrat.

Spremeni se tudi, kaj upravljate. Frontend ima javni TLS, politiko dostopa, dnevnike in razpoložljivost ter mora izbiro backenda omejiti na predvideno storitev. Če skok s frontenda na backend uporablja HTTPS, obdržite preverjanje potrdila na tem skoku.

Obdržite en izvor

Javno ime gostitelja, shema in vrata frontenda tvorijo izvor, ki ga obiskovalci uporabljajo, zato nastavite zunanji URL aplikacije, preusmeritve in piškotke za ta izvor. Pošljite izvirnega gostitelja in posredovano shemo, če aplikacija gradi absolutne povezave. Odgovor, ki uporabnike vrne na zasebno ime ali visoka vrata, razveljavi čisti vstop, ki ste ga pravkar zgradili.

Nato se odločite z mislijo na občinstvo. Kratek URL lahko upraviči upravljani frontend in ni vredno, da bi po nesreči zasebno storitev samo za VPN spremenili v javno.