Zanim zaczniesz
Narysuj endpoint publiczny, źródło, protokoły i drogę powrotną. Sprawdź uprawnienia do adresów i sieci oraz warunki operatora. Zachowaj ustawienia, zaplanuj przerwę i powrót do poprzedniego stanu przed zmianą współdzielonych tras albo filtrów.
Określ potrzebne zadanie
Czy publikujesz aplikację HTTP, przekazujesz grę TCP/UDP, czy ogłaszasz autoryzowany prefiks? To różne zadania. Ustal też, czy aplikacja musi znać oryginalny adres klienta. Nazwa produktu nie opisuje drogi powrotnej ani dozwolonych usług: najpierw potwierdź topologię oraz odpowiedzialność obu końców, zanim zastosujesz przykład konfiguracji z innego środowiska albo wybierzesz rozwiązanie wyłącznie według możliwości technicznych.
Zrozum tunel GRE
GRE kapsułkuje pakiety między endpointami. W IPv4 używa protokołu IP 47, nie portu TCP 47. Może dostarczać wcześniej przefiltrowany ruch, jeśli oba końce są przygotowane. Sam nie zapewnia szyfrowania ani uwierzytelniania: ogranicz źródła i zabezpiecz endpointy. Kapsułkowanie dodaje bajty i może zmniejszyć użyteczne MTU, dlatego testuj prawdziwe transfery, a nie wyłącznie małe pakiety.
Rozdziel HTTP i proxy transportowe
Reverse proxy HTTP interpretuje żądania HTTP. Inne usługi potrzebują odpowiedniego przekazywania TCP lub UDP, na przykład modułu Stream NGINX, gdy pasuje do konfiguracji. Sprawdź długość sesji, timeouty i UDP. Działająca strona nie potwierdza gry. Zachowanie adresu klienta zależy od mechanizmów faktycznie wspieranych przez źródło; nie zakładaj go tylko z powodu obecności proxy przed aplikacją.
Potwierdź warunki BGP
BGP wymienia informacje o routingu. Ogłaszanie sieci wymaga uprawnionych zasobów, uzgodnień i polityk operatora: przydzielone IP VPS nie jest dowolnie ogłaszanym prefiksem. BGP nie filtruje sam ataków. Chroniony tranzyt łączy routing i filtrację. Omów rozmiary prefiksów, warunki, powrót oraz odpowiedzialność za awarie ogłoszeń i dostępności, zanim uznasz tę technikę za pasującą do projektu.
Sprawdź MTU i oba kierunki
Testuj transfery o reprezentatywnej wielkości, nie tylko drobne pakiety czy pojedynczy port. Błędne MTU może zepsuć pobieranie, mimo że prosty test dostępności przechodzi. Asymetryczne trasy wpływają czasem na elementy śledzące stan połączenia: opisz oba kierunki. Nie zmieniaj globalnego MTU ani routingu bez oceny pozostałych usług i kontrolowanego powrotu do poprzedniej, działającej konfiguracji.
Wybierz rozwiązanie możliwe do utrzymania
Pojedyncza strona ma inne potrzeby niż wiele protokołów lub własna sieć. Uwzględnij monitoring, odzyskiwanie oraz odpowiedzialność za przerwę. Najszersza technika nie musi być najlepsza. Przetestuj aplikacje przed migracją i zapisz połączenia, utratę pakietów, opóźnienie i ograniczenia. Sama nazwa metody nie oznacza wyłącznej przepustowości ani uniwersalnej ochrony aplikacji; porównuj rzeczywistą ofertę i wymagania operacyjne.
Co zrobić w Twojej sytuacji
| Sytuacja | Następny krok |
|---|---|
| Jedna aplikacja HTTP | Rozważ proxy HTTP z regułami źródła i osobnym dostępem administracyjnym. |
| Wiele usług TCP/UDP | Porównaj tunel i przekazywanie transportowe, wliczając MTU, adres klienta i powrót. |
| Własna autoryzowana sieć IP | Uzgodnij BGP i tranzyt. Pojedynczy adres VPS nie wystarcza do ogłoszenia prefiksu. |
Oficjalne źródła
Te źródła opisują wymienione protokoły i ustawienia. Sprawdź dokumentację właściwą dla używanej wersji.