Dlaczego Twój URL potrzebuje wejścia na porcie 80 lub 443, a nie 45000
Przeglądarka wybiera 80 lub 443 na podstawie schematu, a nie wysokiego portu Twojego dostawcy. Przejdź ścieżkę wejścia i pochodzenie, które zostawia każda opcja publikacji.
Wpisz nazwę hosta w przeglądarce, a schemat decyduje o porcie docelowym: 80 dla http, 443 dla https. Nic w odpowiedzi DNS tego nie unieważnia, a żadna reguła przekierowania na Twojej maszynie nie może wymyślić nasłuchu na krawędzi dostawcy. Gdy dostawca VPN daje Ci wysoki port publiczny, na przykład 45000, jawny URL działa, a czysty nie. Luka jest na punkcie wejścia, nie wewnątrz aplikacji.
Przejdź raz ścieżkę od przeglądarki do procesu, a trzy opcje publikacji przestaną wyglądać tajemniczo.
Zobacz, dokąd naprawdę trafia żądanie
Przeglądarka rozwiązuje nazwę na adres, a następnie łączy się z tym adresem na domyślnym porcie schematu, chyba że URL wskazuje inny. Krawędź Twojego dostawcy decyduje, co stanie się z przychodzącym połączeniem. Jeśli jego tabela przekierowań mapuje tylko 45000 na Twój adres wewnętrzny, połączenie na 80 nie ma dokąd trafić i jest odrzucane lub porzucane, zanim Twoja maszyna w ogóle weźmie w tym udział.
To odrzucenie dzieje się na krawędzi, dlatego logi Twojej aplikacji nie pokazują niczego. Brak logów jest dowodem na to, gdzie zatrzymał się pakiet, a nie dowodem, że aplikacja jest zepsuta.
Dlaczego reguła lokalna nie naprawi krawędzi
Przekierowanie lub reguła DNAT na hoście aplikacji działa na pakiety, które już dotarły. Pakiety wysłane na port 80 u dostawcy nigdy nie dotrą, więc reguła nigdy nie zostanie oceniona. To najczęściej zmarnowana godzina w całym problemie.
DNS też nie może przenosić portu. specyfikacja HTTP definiuje wartości domyślne schematu, a rekord A lub AAAA zwraca adres, podczas gdy CNAME zwraca inną nazwę. Przeglądarka nadal dokleja port schematu, więc tylko jawny port w URL zmienia cel.
Opcja pierwsza: zachować jawny port
Często poprawna odpowiedź jest ta nieefektowna. Opublikuj pełny URL z portem, zakończ TLS na wejściu, które to obsługuje, i upewnij się, że każde wygenerowane łącze zachowuje to samo pochodzenie. Dla małej, kontrolowanej publiczności to wystarcza i nie kosztuje nic poza widocznym numerem portu.
Sprawdź przekierowania i zakres plików cookie, póki tam jesteś, bo backend, który zapisuje własną nazwę hosta w nagłówku Location, psuje całe rozwiązanie.
Opcja druga: zdobyć prawdziwe wejście na porcie domyślnym
Niektórzy dostawcy i rozwiązania hostingowe przekazują 80 i 443 na współdzielonym lub dedykowanym adresie jako udokumentowaną usługę. Zapytaj, co jest faktycznie w cenie, zamiast zakładać, że publiczny adres wyjściowy oznacza dowolne porty przychodzące. Dedykowany adres wychodzący nic nie mówi o przekierowaniu przychodzącym.
Potwierdź własność i dostępność na piśmie, w tym co dzieje się z wejściem, gdy tunel ponownie łączy się z innym adresem. Wejście, które przesuwa się razem z tunelem, powoduje przerwy wyglądające jak awarie DNS.
Opcja trzecia: postawić frontend z przodu
Odwrotne proxy na osiągalnym adresie może nasłuchiwać na 443 i zakończyć TLS i otworzyć osobne połączenie z backendem przez VPN. Odwiedzający widzą nazwę i domyślny port frontendu, a frontend rozmawia z wysokim portem backendu w Twoim imieniu. To działa, bo zmienia architekturę zamiast walczyć z punktem wejścia. Backend nie potrzebuje wtedy żadnego portu przychodzącego w publicznym internecie.
Zmienia się też to, czym zarządzasz. Frontend posiada publiczny TLS, politykę dostępu, logi i dostępność, i musi ograniczać wybór backendu do zamierzonej usługi. Jeśli skok z frontendu do backendu używa HTTPS, zachowaj walidację certyfikatu na tym skoku.
Zachowaj jedno pochodzenie
Publiczna nazwa hosta, schemat i port frontendu tworzą pochodzenie używane przez odwiedzających, więc skonfiguruj zewnętrzny URL aplikacji, przekierowania i pliki cookie dla tego pochodzenia. Wysyłaj oryginalny host i przekazany schemat, jeśli aplikacja buduje łącza absolutne. Odpowiedź, która odsyła użytkowników do prywatnej nazwy lub wysokiego portu, psuje czyste wejście, które właśnie zbudowałeś.
Potem zdecyduj, mając na uwadze publiczność. Krótki URL może uzasadniać zarządzany frontend i nie warto przypadkiem zamienić prywatnej usługi tylko dla VPN w publiczną.