Zergatik behar du zure URLak 80 edo 443 portuko sarrera bat, eta ez 45000

Idatzi ostalari-izen bat nabigatzailean eta eskemak erabakitzen du helmugako portua: 80 http-rako, 443 https-rako. DNS erantzuneko ezerk ez du hori gainidazten, eta zure makinako birbidaltze-arau batek ere ezin du entzule bat asmatu hornitzailearen ertzean. VPN hornitzaile batek 45000 bezalako portu publiko altu bat ematen dizunean, URL esplizitu batek funtzionatzen du eta garbi batek ez. Arrakala sarrera-puntuan dago, ez aplikazioaren barruan.

Ibili nabigatzailetik prozesurako bidea behin, eta hiru argitalpen-aukerek misteriotsuak izateari utziko diote.

Begiratu nora joaten den eskaera benetan

Nabigatzaileak izena helbide bihurtzen du, eta gero helbide horretara konektatzen da eskemaren lehenetsitako portuan, URLak beste bat aipatzen ez badu. Zure hornitzailearen ertzak erabakitzen du iristen den konexioarekin zer gertatzen den. Bere birbidaltze-taulak 45000 baino ez badu mapatzen zure barne-helbidera, 80rako konexioak ez du nora joan eta ukatu edo baztertu egiten da zure makinak parte hartu aurretik.

Ukapen hori ertzean gertatzen da, eta horregatik zure aplikazioaren erregistroek ez dute ezer erakusten. Erregistroen absentzia paketea non gelditu zen adierazten duen froga da, ez aplikazioa hondatuta dagoen froga.

Zergatik ezin duen arau lokal batek ertza konpondu

Aplikazioaren ostalarian birbideratze batek edo DNAT arau batek jada iritsitako paketeetan eragiten du. Hornitzailean 80 portura bidalitako paketeak ez dira inoiz iristen, beraz araua ez da inoiz ebaluatzen. Arazo osoan galdutako ordurik ohikoena da.

DNSek ere ezin du portua eraman. HTTP zehaztapena eskemaren lehenetsitako balioak definitzen ditu, eta A edo AAAA erregistro batek helbide bat itzultzen du, CNAME batek beste izen bat itzultzen duen bitartean. Nabigatzaileak eskemako portua gehitzen jarraitzen du, beraz URLan portu esplizitu batek bakarrik aldatzen du helmuga.

Lehen aukera: portu esplizitua mantentzea

Askotan erantzun zuzena distirarik gabekoa da. Argitaratu URL osoa portuarekin, amaitu TLS hori onartzen duen sarrera batean, eta ziurtatu sortutako esteka bakoitzak jatorri bera mantentzen duela. Audientzia txiki eta kontrolatu baterako hau osoa da, eta ez du ezer kostatzen portu-zenbaki ikusgai bat baino harago.

Egiaztatu birbideratzeak eta cookieen irismena han zauden bitartean, zeren bere ostalari-izena Location goiburu batean idazten duen backend batek akordioa baliogabetzen baitu.

Bigarren aukera: benetako sarrera bat lortzea lehenetsitako portuan

Hornitzaile batzuek eta ostalaritza-egiturek 80 eta 443 birbidaltzen dituzte helbide partekatu edo dedikatu batean zerbitzu dokumentatu gisa. Galdetu zer dagoen benetan barne, irteerako helbide publiko batek edozein sarrera-portu suposatzen duela pentsatu beharrean. Irteerako helbide dedikatu batek ez du ezer esaten sarrerako birbidaltzeari buruz.

Berretsi jabegoa eta eskuragarritasuna idatziz, tunelak beste helbide batekin berriz konektatzen denean sarrerari zer gertatzen zaion barne. Tunelarekin mugitzen den sarrera batek DNS hutsegiteak diruditen etendurak sortzen ditu.

Hirugarren aukera: frontend bat aurrera jartzea

Helbide irisgarri batean proxy alderantzizko batek 443an entzun eta TLS amaitu eta VPNaren bidez backendarekiko konexio bereizi bat ireki dezake. Bisitariek frontendaren izena eta portu lehenetsia ikusten dituzte, frontendak zure izenean backendaren portu altuarekin hitz egiten duen bitartean. Honek funtzionatzen du arkitektura aldatzen duelako sarrera-puntuaren aurka borrokatu beharrean. Backendak orduan ez du sarrera-porturik behar internet publikoan.

Gainera, eragiketak aldatzen ditu. Frontendak TLS publikoa, sarbide-politika, erregistroak eta eskuragarritasuna ditu, eta backendaren hautaketa zerbitzu aurreikusira mugatu behar du. Frontendetik backendera jauzia HTTPS bada, mantendu ziurtagirien baliozkotzea jauzi horretan.

Mantendu jatorri bakarra

Frontendaren ostalari-izen publikoa, eskema eta portua bisitariek erabiltzen duten jatorria osatzen dute, beraz konfiguratu aplikazioaren kanpoko URLa, birbideratzeak eta cookieak jatorri horretarako. Bidali jatorrizko ostalaria eta birbidalitako eskema aplikazioak esteka absolutuak eraikitzen baditu. Erabiltzaileak izen pribatu batera edo portu altu batera itzultzen dituen erantzun batek eraiki berri duzun sarrera garbia baliogabetzen du.

Ondoren erabaki audientzia kontuan hartuta. URL labur batek kudeatutako frontend bat justifika dezake, eta ez da merezi VPNerako soilik den zerbitzu pribatu bat nahi gabe publiko bihurtzea.