Dedykowany IP VPN nie publikuje Twojej witryny
Dedykowany adres wyjściowy nic nie mówi o dostarczaniu ruchu przychodzącego. Sprawdź umowę przekierowania, dokończ stronę źródła, a potem opublikuj wysoki port.
Kupno dedykowanego IP u dostawcy VPN przypomina kupno drzwi wejściowych. Adres jest stały, tunel działa, a witryna nadal nie ładuje się nikomu z zewnątrz. To, co kupiłeś, to przydział adresu, a nie reguła przekierowania ruchu przychodzącego. Oba sprzedaje się w tym samym sklepie i konfiguruje w zupełnie innych miejscach.
Adres to przydział, a nie reguła przekierowania
Zapisz przychodzący adres publiczny lub nazwę hosta, dozwolony transport, przydzielony port zewnętrzny i cel po stronie klienta, do którego dostarcza dostawca. Następnie potwierdź, że wybrany serwer, protokół i funkcja konta rzeczywiście obsługują przekierowanie oraz że dostawca pozwala na hostowanie na nim.
Słowo dedykowany opisuje przydział adresu. Nie oznacza, że dozwolony jest niechciany ruch przychodzący, a różne dodatki tego samego operatora mogą mieć różne możliwości. Dedykowany adres i produkt dedykowanego serwera to dwie etykiety najczęściej mylone, a strony pomocy zwykle wyjaśniają, która z nich przekierowuje.
| What you have | What it gives you | What it does not |
|---|---|---|
| Dedicated exit address | A stable source address for outbound traffic | Any inbound delivery at all |
| Port-forwarding add-on | A provider-side mapping to your session | Permanence across reconnects |
| Local DNAT rule | Handling for packets that arrive | Making packets arrive |
Przykładowa umowa wygląda tak: dostawca dostarcza TCP 203.0.113.60:45000 do usługi HTTPS podłączonego urządzenia na porcie 8443. To opis mapowania skonfigurowanego przez kogoś innego, a nie reguła, którą możesz utworzyć na ich krawędzi, wpisując ją we własnym firewallu.
Dokończ stronę źródła
Jeśli aplikacja webowa działa na samym kliencie VPN, potrzebuje nasłuchu na dostarczonym porcie i ograniczonego uprawnienia do lokalnego wejścia na tym porcie. Jeśli klient przekierowuje zmapowane połączenie na inny host, potrzebuje tłumaczenia celu, polityki przekierowania i ścieżki odpowiedzi, która przetrwa drogę tam i z powrotem.
Projektuj reguły dostępu wokół adresu źródłowego, który ścieżka dostawcy naprawdę przedstawia. To nie zawsze pierwotny odwiedzający i nie zawsze serwer VPN, co ma znaczenie, gdy piszesz regułę, do której pasowałby tylko jeden z tych adresów.
Tłumaczenie portów również nie zamienia HTTP na HTTPS. Port publiczny i lokalny port aplikacji mogą się swobodnie różnić, ale schemat, tożsamość certyfikatu i przekierowania nadal muszą pasować do usługi, do której ludzie faktycznie docierają. Jeśli certyfikat wskazuje publicznego hosta, zachowaj tę nazwę na każdym etapie. Niezgodność tutaj objawia się ostrzeżeniem przeglądarki, a nie błędem routingu, co wysyła ludzi na godzinę do niewłaściwych logów.
Opublikuj wysoki port uczciwie
Jeśli odwiedzający łączą się bezpośrednio, a dostawca przydzielił wysoki port, podaj im pełny URL. Zwykły rekord adresu DNS nie może dodać portu do żądania HTTPS, które domyślnie używa 443, i żadne dostrajanie TTL tego nie zmieni.
Frontend webowy może to rozwiązać, przyjmując odwiedzających na zwykłym porcie i tworząc własne połączenie do przekierowanego portu źródła. Domyślne porty proxy Cloudflare to jednak zdefiniowana lista, a dowolnie przydzielony port nie staje się obsługiwanym portem brzegowym tylko dlatego, że dodano rekord DNS z proxy.
Zmiana portu docelowego źródła to inna operacja niż zmiana portu odwiedzającego. Origin Rules Cloudflare dokumentują nadpisanie portu docelowego dla połączenia z backendem, ograniczone do obsługiwanej reguły, schematu i nazwy hosta. Nadpisanie portu nie jest uniwersalnym przekaźnikiem dla dowolnego UDP ani innych protokołów.
Gdy frontend kończy TLS, zweryfikuj oba etapy: certyfikat od przeglądarki do frontendu i połączenie od frontendu do źródła. Etap VPN nie zastępuje żadnej z tych kontroli, a wyciek adresu wewnętrznego do przekierowań lub plików cookie to zwykły znak, że tylko jeden z dwóch skonfigurowano z myślą o publicznej nazwie.
Utrzymaj mapowanie przy życiu
Niektórzy dostawcy przydzielają inny port po ponownym połączeniu, a dzierżawione mapowanie może wymagać odnowienia przez działanie po stronie dostawcy. Śledź mechanizm dokumentowany przez dostawcę i aktualizuj nasłuch, reguły lokalne, DNS lub regułę frontendu tylko tam, gdzie wymaga tego obecna umowa.
Statyczny adres publiczny nie czyni dzierżawy portu statyczną. Adres i port nadal widoczne w panelu nie dowodzą, że aktywna sesja posiada mapowanie, dlatego testem jest świeże żądanie z zewnątrz, a nie zrzut ekranu.
Następnie powtórz przypadki, których oczekujesz: normalne ponowne połączenie i utratę VPN. Jeśli utrata ma uczynić źródło niedostępnym, nie pozwól aktualizatorowi po cichu ponownie opublikować bezpośredniej ścieżki ISP w tle. A jeśli umowa przekierowania nie może spełnić wymagań stabilności witryny, wybierz inny sposób publikacji, zamiast kupować kolejną etykietę adresu i mieć nadzieję, że zachowa się jak serwer.