Zašto vašem URL-u treba unos na portu 80 ili 443, a ne 45000

Upišite ime hosta u preglednik i šema odlučuje odredišni port: 80 za http, 443 za https. Ništa u DNS odgovoru to ne poništava, a nijedno pravilo prosljeđivanja na vašem računaru ne može izmisliti slušaoca na ivici provajdera. Kada vam VPN provajder dodijeli visoki javni port kao što je 45000, eksplicitan URL radi, a čist ne. Praznina je na ulaznoj točki, a ne unutar aplikacije.

Prođite putem od preglednika do procesa jednom i tri opcije objavljivanja prestaju izgledati tajanstveno.

Pogledajte kuda zahtjev zapravo ide

Preglednik razrješava ime u adresu, zatim se povezuje s tom adresom na zadanom portu šeme, osim ako URL navodi drugi. Ivica vašeg provajdera odlučuje šta se događa s dolaznom vezom. Ako njena tablica prosljeđivanja preslikava samo 45000 na vašu internu adresu, veza na 80 nema kuda otići i biva odbijena ili odbačena prije nego što vaš računar uopšte sudjeluje.

To odbijanje se događa na ivici, zato vaši zapisi aplikacije ne pokazuju ništa. Odsustvo zapisa dokaz je o tome gdje se paket zaustavio, a ne dokaz da je aplikacija pokvarena.

Zašto lokalno pravilo ne može popraviti ivicu

Preusmjeravanje ili DNAT pravilo na hostu aplikacije djeluje na pakete koji su već stigli. Paketi poslani na port 80 kod provajdera nikada ne stižu, pa se pravilo nikada ne evaluira. To je najčešće izgubljeni sat u cijelom problemu.

Ni DNS ne može nositi port. Specifikacija HTTP-a definira zadane vrijednosti šeme, a A ili AAAA zapis vraća adresu dok CNAME vraća drugo ime. Preglednik i dalje spaja port šeme, pa samo eksplicitan port u URL-u mijenja odredište.

Opcija prva: zadržite eksplicitan port

Često je tačan odgovor onaj neugledni. Objavite puni URL s portom, završite TLS na ulazu koji to podržava i pazite da svaka generirana veza zadrži isto porijeklo. Za malu, kontroliranu publiku to je potpuno i ne košta ništa osim vidljivog broja porta.

Provjerite preusmjeravanja i obim kolačića dok ste tamo, jer backend koji upisuje vlastito ime hosta u Location zaglavlje poništava dogovor.

Opcija druga: nabavite pravi unos na zadanom portu

Neki provajderi i hostinška rješenja prosljeđuju 80 i 443 na dijeljenoj ili namjenskoj adresi kao dokumentiranu uslugu. Pitajte šta je zapravo uključeno umjesto da pretpostavljate da javna izlazna adresa podrazumijeva proizvoljne ulazne portove. Namjenska izlazna adresa ne govori ništa o ulaznom prosljeđivanju.

Potvrdite vlasništvo i dostupnost u pisanoj formi, uključujući šta se događa s unosom kada se tunel ponovo poveže s drugom adresom. Unos koji se kreće s tunelom stvara prekide koji izgledaju kao DNS kvarovi.

Opcija treća: stavite frontend ispred

Obrnuti proxy na dostupnoj adresi može slušati na 443 i završiti TLS i otvoriti zasebnu vezu s backendom preko VPN-a. Posjetioci vide ime i zadani port frontenda, dok frontend razgovara s visokim portom backenda u vaše ime. To funkcionira jer mijenja arhitekturu umjesto da se bori s ulaznom točkom. Backend tada uopće ne treba ulazni port na javnom internetu.

To mijenja i ono što upravljate. Frontend posjeduje javni TLS, politiku pristupa, zapise i dostupnost i mora ograničiti odabir backenda na predviđenu uslugu. Ako skok od frontenda do backenda koristi HTTPS, zadržite provjeru certifikata na tom skoku.

Zadržite jedno porijeklo

Javno ime hosta, šema i port frontenda čine porijeklo koje posjetioci koriste, pa konfigurirajte vanjski URL aplikacije, preusmjeravanja i kolačiće za to porijeklo. Pošaljite originalni host i proslijeđenu šemu ako aplikacija gradi apsolutne veze. Odgovor koji vraća korisnike na privatno ime ili visoki port poništava čist ulaz koji ste upravo napravili.

Zatim odlučite imajući publiku na umu. Kratak URL može opravdati upravljani frontend i nije vrijedno slučajno pretvoriti privatnu uslugu samo za VPN u javnu.