Proč vaše URL potřebuje vstup na portu 80 nebo 443, a ne 45000

Zadejte do prohlížeče název hostitele a schéma rozhodne o cílovém portu: 80 pro http, 443 pro https. Nic v odpovědi DNS to nepřebíjí a žádné pravidlo přesměrování na vašem stroji nemůže na okraji poskytovatele vymyslet naslouchající proces. Když vám poskytovatel VPN přidělí vysoký veřejný port, například 45000, explicitní URL funguje a čistá ne. Mezera je na vstupním bodě, ne uvnitř aplikace.

Projděte cestu od prohlížeče k procesu jednou a tři možnosti publikování přestanou vypadat záhadně.

Podívejte se, kam požadavek skutečně jde

Prohlížeč přeloží název na adresu a poté se k této adrese připojí na výchozím portu schématu, pokud URL neuvádí jiný. O tom, co se stane s příchozím spojením, rozhoduje okraj vašeho poskytovatele. Pokud jeho přesměrovávací tabulka mapuje na vaši interní adresu jen 45000, spojení na 80 nemá kam jít a je odmítnuto nebo zahozeno dřív, než se vaše zařízení vůbec zapojí.

Toto odmítnutí probíhá na okraji, a proto vaše protokoly aplikace neukazují nic. Nepřítomnost protokolů je dokladem o tom, kde se paket zastavil, ne dokladem, že aplikace je rozbitá.

Proč lokální pravidlo okraj nespraví

Přesměrování nebo pravidlo DNAT na hostiteli aplikace působí na pakety, které už dorazily. Pakety odeslané na port 80 u poskytovatele nikdy nedorazí, takže se pravidlo nikdy nevyhodnotí. To je nejčastěji promarněná hodina v celém problému.

Ani DNS nemůže port přenášet. specifikace HTTP definuje výchozí hodnoty schématu a záznam A nebo AAAA vrací adresu, zatímco CNAME vrací jiné jméno. Prohlížeč stále připojuje port schématu, takže cíl mění jen explicitní port v URL.

Možnost první: zachovat explicitní port

Často je správná odpověď ta neokázalá. Zveřejněte plnou URL s portem, ukončete TLS na vstupu, který to podporuje, a zajistěte, aby každý generovaný odkaz zachoval stejný původ. Pro malé, kontrolované publikum je to úplné a nestojí to nic kromě viditelného čísla portu.

Zkontrolujte přesměrování a rozsah cookies, dokud jste tam, protože backend, který zapisuje své vlastní jméno hostitele do hlavičky Location, celé uspořádání ruší.

Možnost druhá: získat skutečný vstup na výchozím portu

Někteří poskytovatelé a hostingová uspořádání přeposílají 80 a 443 na sdílené nebo vyhrazené adrese jako dokumentovanou službu. Zeptejte se, co je skutečně zahrnuto, místo abyste předpokládali, že veřejná výstupní adresa znamená libovolné příchozí porty. Vyhrazená výstupní adresa nic neříká o příchozím přeposílání.

Potvrďte vlastnictví a dostupnost písemně, včetně toho, co se stane se vstupem, když se tunel znovu připojí s jinou adresou. Vstup, který se pohybuje s tunelem, vytváří výpadky, které vypadají jako poruchy DNS.

Možnost třetí: postavit dopředu frontend

Reverzní proxy na dostupné adrese může naslouchat na 443 a ukončit TLS a otevřít samostatné spojení s backendem přes VPN. Návštěvníci vidí jméno a výchozí port frontendu, zatímco frontend mluví s vysokým portem backendu vaším jménem. Funguje to, protože to mění architekturu, místo aby to bojovalo se vstupním bodem. Backend pak na veřejném internetu nepotřebuje žádný příchozí port.

Mění to také to, co provozujete. Frontend vlastní veřejné TLS, přístupovou politiku, protokoly a dostupnost a musí omezit výběr backendu na zamýšlenou službu. Pokud skok z frontendu na backend používá HTTPS, ponechte na tomto skoku ověřování certifikátu.

Zachovejte jeden původ

Veřejné jméno hostitele, schéma a port frontendu tvoří původ, který návštěvníci používají, takže nakonfigurujte externí URL aplikace, přesměrování a cookies pro tento původ. Posílejte původní hostitele a přeposlané schéma, pokud aplikace vytváří absolutní odkazy. Odpověď, která uživatele odrazí na soukromé jméno nebo vysoký port, ruší čistý vstup, který jste právě postavili.

Poté se rozhodněte s ohledem na publikum. Krátká URL může ospravedlnit spravovaný frontend a nestojí za to omylem proměnit soukromou službu jen pro VPN ve veřejnou.