Od wyboru serwera i regionu przez podstawowe zabezpieczenia, instalację proxy, uwierzytelnianie i porty, aż po konfigurację klienta, weryfikację i kolejność diagnostyki.
Wybór serwera i regionu
Sam serwer proxy zużywa bardzo mało CPU i pamięci, więc te parametry nie są najważniejsze przy wyborze konfiguracji.
Na początku nie trzeba kupować mocnej maszyny. Pakiety typu lekki serwer aplikacyjny, obejmujące stałe pasmo i miesięczny limit transferu, zwykle wystarczą do prywatnego proxy dla jednego lub kilku kont i są niedrogie. Dopiero gdy potrzebujesz wielu instancji albo masz konkretne wymagania dotyczące przepustowości, warto rozważyć instancje ogólnego przeznaczenia z zasobami konfigurowanymi oddzielnie.
Region jest ważniejszy niż parametry sprzętowe, ponieważ adres wyjściowy IP należy do lokalizacji, w której działa węzeł. Zasada jest prosta: węzeł powinien znajdować się na rynku, dla którego używane jest konto. Wiele osób wybiera lokalizację na podstawie szybkości dostępu. Węzeł w Hongkongu może być szybki z Chin kontynentalnych, ale jeśli profil konta wskazuje Stany Zjednoczone, a wyjście znajduje się w Azji, ta niespójność jest ważniejsza niż szybkość. Szybkość jest drugorzędna; najważniejsza jest spójność.
Przepustowość dobieraj do rzeczywistego użycia. Do przeglądania paneli i codziennej administracji wystarczy niewielkie pasmo; praca z obrazami i filmami wymaga więcej; im więcej kont jest jednocześnie online, tym większe jest zapotrzebowanie. Jeśli nie masz pewności, zacznij od najmniejszego pakietu, obserwuj zużycie przez miesiąc i dopiero potem zwiększ parametry.
Wykonaj te kroki po uruchomieniu serwera
Wybierz obraz systemu Linux. Takie dystrybucje zazwyczaj mają SSH domyślnie, więc nie trzeba dodatkowo konfigurować zdalnego dostępu. Przy zakupie wygodnie jest ustawić własne hasło zamiast pliku klucza, ponieważ później podczas konfiguracji proxy odpada jeden etap konwersji.
Po otrzymaniu serwera zapisz cztery informacje: publiczny adres IP, nazwę użytkownika (domyślnie root w Linux), hasło oraz port SSH (domyślnie 22). To właśnie te dane wpiszesz później w kliencie.
Następnie skonfiguruj podstawowe zabezpieczenia. Zmiana domyślnego portu 22 ogranicza dużą część automatycznych prób skanowania. Jeśli dostawca obsługuje logowanie kluczem, skonfiguruj je, a potem wyłącz logowanie hasłem. W grupie bezpieczeństwa i zaporze systemowej otwórz tylko naprawdę potrzebne porty, a pozostałe zamknij. Zajmuje to kilka minut, a ogranicza stały szum skanów i prób użycia przejętych danych logowania.
Dwa sposoby uruchomienia usługi proxy
Pierwszy to bezpośredni tunel SSH. Na serwerze nie trzeba nic instalować: klient wykorzystuje istniejącą usługę SSH do przekazywania ruchu, używając portu 22 i danych logowania serwera. Wadą jest przeciętna wydajność; długotrwała praca lub większa liczba równoczesnych połączeń może być obciążająca, więc rozwiązanie lepiej nadaje się do użytku tymczasowego albo niewielkiej liczby kont.
Drugi sposób to instalacja dedykowanej usługi proxy na serwerze. Najczęściej instaluje się ją jednym poleceniem, a następnie samodzielnie ustawia metodę uwierzytelniania i port. Daje to lepszą wydajność i większą kontrolę oraz lepiej nadaje się do stałego użycia. Po instalacji włącz automatyczny start wraz z systemem, inaczej po restarcie serwera proxy przestanie działać.
Uwierzytelnianie i porty
Można wyróżnić trzy poziomy uwierzytelniania, o rosnącym poziomie bezpieczeństwa: nazwa użytkownika i hasło są najprostsze, ale wyciek hasła praktycznie oddaje dostęp do proxy; hasło plus lista dozwolonych źródłowych adresów IP zwykle wystarcza do codziennego użycia; uwierzytelnianie kluczem lub certyfikatem jest najbezpieczniejsze, choć wymaga więcej konfiguracji i warto je stosować dla kont używanych długoterminowo.
W przypadku portów nie wystarczy ustawić portu nasłuchiwania samej usługi. Ten sam port trzeba osobno otworzyć w zaporze systemowej i w grupie bezpieczeństwa dostawcy. To dwa niezależne mechanizmy, a otwarcie tylko jednego z nich jest częstą przyczyną braku połączenia. Adres nasłuchiwania nie powinien też być związany wyłącznie z lokalnym interfejsem loopback. Jeśli test na samym serwerze działa, a połączenie z zewnątrz nie, jest to prawdopodobna przyczyna.
Podłączenie klienta i weryfikacja
W narzędziu do zarządzania środowiskami utwórz nowe środowisko, nadaj mu nazwę i opis — warto uwzględnić przeznaczenie konta oraz region docelowy, co ułatwia pracę przy większej liczbie kont — a następnie w ustawieniach proxy wpisz zgodnie z typem proxy adres serwera, port, nazwę użytkownika i hasło. Uruchom test. Komunikat powodzenia oznacza, że ścieżka sieciowa działa. Dokładne nazwy pól zależą od interfejsu narzędzia.
Przejście testu to dopiero pierwszy krok. Otwórz środowisko i sprawdź trzy rzeczy.
Po pierwsze, adres wyjściowy IP powinien być publicznym adresem IP serwera. Otwórz stronę pokazującą bieżący adres IP; dopiero wyświetlenie adresu serwera potwierdza, że ruch przechodzi przez proxy.
Po drugie, sprawdź, czy DNS również przechodzi przez proxy. Jeśli DNS nadal jest rozwiązywany lokalnie, ujawniane informacje geograficzne mogą nie zgadzać się z adresem wyjściowym IP, a ustawiony region konta traci znaczenie.
Po trzecie, strefa czasowa i język powinny odpowiadać regionowi wyjścia. Amerykański adres IP połączony z chińską strefą czasową i językiem chińskim to łatwo zauważalna niespójność.
Dopiero po przejściu wszystkich trzech kontroli środowisko można uznać za gotowe.
Gdy nie ma połączenia, sprawdzaj w tej kolejności
Jeśli test proxy od razu kończy się niepowodzeniem, zacznij od łączności: sprawdź, czy port jest otwarty zarówno w grupie bezpieczeństwa, jak i w zaporze systemowej. Następnie upewnij się, że usługa proxy działa, szczególnie po restarcie serwera. Potem sprawdź nazwę użytkownika, hasło i poprawność adresu serwera. Pomylenie publicznego i prywatnego adresu IP zdarza się często.
Jeśli test przechodzi, ale strony się nie otwierają, problem zwykle leży po stronie środowiska. Sprawdź, czy przypisano właściwe proxy i czy DNS nie został z powrotem ustawiony na lokalne rozwiązywanie.
Jeśli połączenie jest wolne, najpierw ustal, czy winna jest odległość czy przepustowość. Wejdź na stronę docelową bezpośrednio z serwera. Jeśli sam serwer działa wolno, przyczyną jest region węzła lub trasa sieciowa; jeśli serwer jest szybki, a klient wolny, najczęściej brakuje pasma albo zbyt wiele kont jest online jednocześnie.
Skalowanie przy rosnącej liczbie kont
Wiele kont na jednym serwerze obniża koszty, ale wszystkie współdzielą ten sam adres wyjściowy IP. Jeśli platforma rozpoznaje powiązania na podstawie zakresów IP, konta nadal mogą być ze sobą kojarzone. Jeden serwer na jedno konto kosztuje więcej, ale całkowicie rozdziela środowiska i jest bardziej solidnym rozwiązaniem dla wartościowych kont.
Za pomocą narzędzia do zarządzania środowiskami takiego jak PurpleMark można niezawodniej przypisać osobne wyjście do każdego konta niż prowadzić ręczną tabelę powiązań. Przy typowych cenach lekkich serwerów osobne wyjście dla każdego konta jest w wielu przypadkach akceptowalne kosztowo i może oszczędzić późniejszego odtwarzania kont z powodu powiązań. Warto też mieć osobny serwer testowy. Nie umieszczaj wszystkich kont na jednej maszynie, bo pojedyncza awaria może dotknąć je wszystkie naraz.
