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

Upišite ime hosta u preglednik i shema 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čunalu ne može izmisliti slušatelja na rubu davatelja. Kada vam VPN davatelj dodijeli visoki javni port poput 45000, eksplicitan URL radi, a čist ne. Praznina je na ulaznoj točki, a ne unutar aplikacije.

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

Pogledajte kamo zahtjev zapravo ide

Preglednik razrješava ime u adresu, zatim se povezuje s tom adresom na zadanom portu sheme, osim ako URL navodi drugi. Rub vašeg davatelja odlučuje što se događa s dolaznom vezom. Ako njegova tablica prosljeđivanja preslikava samo 45000 na vašu internu adresu, veza na 80 nema kamo otići i biva odbijena ili odbačena prije nego što vaše računalo uopće sudjeluje.

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

Zašto lokalno pravilo ne može popraviti rub

Preusmjeravanje ili DNAT pravilo na hostu aplikacije djeluje na pakete koji su već stigli. Paketi poslani na port 80 kod davatelja 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 sheme, a A ili AAAA zapis vraća adresu dok CNAME vraća drugo ime. Preglednik i dalje spaja port sheme, pa samo eksplicitan port u URL-u mijenja odredište.

Opcija prva: zadržite eksplicitan port

Često je toč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 podrijetlo. Za malu, kontroliranu publiku to je potpuno i ne košta ništa osim vidljivog broja porta.

Provjerite preusmjeravanja i obuhvat 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 davatelji i hosting rješenja prosljeđuju 80 i 443 na dijeljenoj ili namjenskoj adresi kao dokumentiranu uslugu. Pitajte što 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 pisanom obliku, uključujući što se događa s unosom kada se tunel ponovno 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. Posjetitelji 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 podrijetlo

Javno ime hosta, shema i port frontenda čine podrijetlo koje posjetitelji koriste, pa konfigurirajte vanjski URL aplikacije, preusmjeravanja i kolačiće za to podrijetlo. Pošaljite originalni host i proslijeđenu shemu 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.