Praktyczna kolejność przygotowania serwera dla własnego adresu IP proxy: najpierw sprawdzenie dostępu SSH, potem zmiana portu i logowanie kluczem, podstawowe utwardzenie, instalacja usługi proxy i otwarcie portu, a na końcu podłączenie oraz weryfikacja klienta.
Przy zakupie serwera w chmurze do roli proxy problem rzadko dotyczy samej łączności. Częściej chodzi o kolejność przygotowania strony serwerowej. Jeśli wykonasz kroki we właściwej kolejności, klient zwykle połączy się za pierwszym razem; jeśli kolejność będzie chaotyczna, będziesz ciągle wracać do terminala i zmieniać ustawienia.
Ten materiał dotyczy wyłącznie strony serwerowej: pierwszego logowania, ograniczenia dostępu, uruchomienia usługi proxy, otwarcia portów, połączenia klienta oraz warstwowego diagnozowania problemów, gdy połączenie nie działa.
Przy pierwszym logowaniu najpierw sprawdź dostęp
Po utworzeniu instancji zaloguj się najpierw przez terminal WWW w konsoli dostawcy, zamiast od razu polegać na lokalnym narzędziu. Na tym etapie chodzi tylko o potwierdzenie, że maszyna działa i sieć jest osiągalna.
Po zalogowaniu przełącz się na root, wykonując sudo -i i naciskając Enter. Gdy znak zachęty zmieni się z $ na #, podniesienie uprawnień zakończyło się powodzeniem. Kolejne operacje wykonuj z tą tożsamością.
Zapisz cztery informacje: publiczny adres IP, nazwę użytkownika logowania (domyślnie root w Linux), hasło i port SSH (domyślnie 22). Klient potrzebuje dokładnie tych czterech wartości; brak jednej z nich uniemożliwi połączenie.
Zmień domyślny port, a potem przejdź na logowanie kluczem
Port 22 jest codziennie skanowany niezliczoną liczbę razy, a automatyczne próby logowania są czymś normalnym. Zmiana portu nie wzmacnia serwera sama w sobie, ale odfiltrowuje większość zautomatyzowanego szumu.
Zmiany wprowadza się w /etc/ssh/sshd_config. Otwórz plik w vi, naciśnij i, aby wejść w tryb edycji, ustaw linie PermitRootLogin i PasswordAuthentication na yes, a następnie po Esc wpisz :wq, aby zapisać i wyjść. Jeśli dostawca obsługuje logowanie kluczem, bezpieczniejszym rozwiązaniem jest dodanie lokalnego klucza publicznego do authorized_keys na serwerze, a następnie ustawienie PasswordAuthentication na no, aby akceptować wyłącznie klucze.
Nie zamykaj bieżącej sesji od razu po zmianie konfiguracji. Najpierw otwórz drugie okno terminala, zaloguj się raz przy użyciu nowego portu i nowej metody, upewnij się, że wszystko działa, a dopiero potem zamknij stare okno. W przeciwnym razie błąd konfiguracji może odciąć dostęp i pozostanie tylko odzyskiwanie przez konsolę dostawcy.
Port SSH ustawia się w linii Port. Po zmianie uruchom ponownie usługę SSH, aby konfiguracja zaczęła obowiązywać. W systemach Debian i Ubuntu możesz wykonać /etc/init.d/ssh restart.
Wykonaj podstawowe utwardzenie już pierwszego dnia
Poza zmianą portu i użyciem kluczy warto pierwszego dnia wykonać jeszcze dwie drobne czynności. Po pierwsze, ustaw dla root wystarczająco długie losowe hasło poleceniem passwd root, zamiast używać łatwej do odgadnięcia kombinacji. Po drugie, wyłącz nieużywane usługi i porty. Im mniej działa na maszynie, tym mniejsza powierzchnia ataku; zapora systemowa powinna przepuszczać tylko porty rzeczywiście potrzebne.
Jeśli serwer będzie przez dłuższy czas używany tylko z kilku stałych lokalizacji źródłowych, ogranicz w grupie zabezpieczeń adresy źródłowe do tych miejsc. To znacznie bezpieczniejsze niż otwieranie dostępu dla całego Internetu.
Zainstaluj usługę proxy i skonfiguruj uwierzytelnianie
Po zakończeniu inicjalizacji serwera można przejść do samego proxy.
Jedną możliwością jest bezpośrednie użycie tunelu SSH. Na serwerze nie trzeba niczego dodatkowo instalować; klient używa wbudowanej usługi SSH do przekazywania ruchu i tych samych danych logowania co serwer. To wygodne, ale wydajność jest przeciętna i duża liczba równoczesnych połączeń szybko staje się problemem, więc rozwiązanie najlepiej nadaje się do zastosowań tymczasowych lub niewielkiej liczby kont.
Druga możliwość to instalacja dedykowanej usługi proxy. Zwykle wystarcza jedno polecenie instalacyjne, a następnie samodzielnie ustawia się metodę uwierzytelniania i port nasłuchiwania. Pamiętaj o włączeniu automatycznego startu; inaczej po jednym restarcie serwera proxy przestanie działać.
Można wyróżnić trzy typowe poziomy uwierzytelniania, od najmniej do najbardziej bezpiecznego: użytkownik i hasło są najprostsze, ale wyciek praktycznie oddaje proxy; hasło wraz z listą dozwolonych źródłowych IP zwykle wystarcza na co dzień; uwierzytelnianie kluczem lub certyfikatem jest najpewniejsze, choć wymaga więcej konfiguracji i opłaca się w przypadku kont używanych długoterminowo.
Otwórz port w dwóch oddzielnych miejscach
To jeden z najczęstszych punktów awarii. Port nasłuchiwania usługi proxy trzeba dopuścić zarówno w zaporze systemowej, jak i w grupie zabezpieczeń dostawcy. Te dwa mechanizmy są niezależne i otwarcie tylko jednego z nich nie wystarczy.
Łatwo przeoczyć także adres nasłuchiwania usługi. Niektóre usługi domyślnie wiążą się wyłącznie z 127.0.0.1. Jeśli test lokalny na serwerze działa, ale połączenie z zewnątrz nie, często właśnie to jest przyczyną. Zmień adres nasłuchiwania na prywatny adres serwera lub 0.0.0.0.
Połącz się z lokalnego klienta
Utwórz nowe środowisko w narzędziu do zarządzania i wybierz faktycznie używany typ proxy. Przy tunelu SSH adresem jest publiczny IP serwera, portem port SSH, a nazwą użytkownika i hasłem są dane logowania do serwera. Następnie uruchom test połączenia.
Pozytywny test oznacza tylko, że ścieżka działa. Otwórz środowisko i sprawdź jeszcze trzy rzeczy: czy wyjściowy IP jest publicznym IP serwera; czy DNS również przechodzi przez proxy, ponieważ lokalne rozwiązywanie DNS może ujawniać region niezgodny z wyjściowym IP; oraz czy strefa czasowa i język odpowiadają regionowi wyjścia. Dopiero gdy wszystkie trzy warunki są spełnione, środowisko jest gotowe do użycia.
Gdy liczba kont rośnie, utrzymuj stałe powiązanie między środowiskiem a wyjściem, aby kilka kont nie współdzieliło jednego środowiska. Narzędzia takie jak PurpleMark mogą przypisać osobne wyjście do każdego konta i są pewniejsze niż ręcznie prowadzona tabela powiązań.
Gdy nie ma połączenia, sprawdzaj od zewnątrz do wewnątrz
Zacznij od najbardziej zewnętrznej warstwy: czy grupa zabezpieczeń przepuszcza ruch? Czy zapora systemowa go przepuszcza? Potwierdź oba punkty, zanim przejdziesz dalej.
Następnie sprawdź samą usługę: czy proces nadal działa, szczególnie po restarcie serwera? Czy adres nasłuchiwania jest związany tylko z hostem lokalnym?
Potem sprawdź warstwę uwierzytelniania: czy nazwa użytkownika lub hasło są błędne? Czy uprawnienia pliku klucza nie są zbyt szerokie? SSHD bezpośrednio odrzuci klucz przy nieprawidłowych uprawnieniach. Dopiero na końcu sprawdź klienta: czy wpisano publiczny IP, czy przez pomyłkę prywatny IP? To pomyłka zdarza się bardzo często.
Przy takiej kolejności zwykle wystarczą dwie lub trzy rundy, aby wskazać warstwę powodującą problem, zamiast wielokrotnie reinstalować usługę.
Zakończenie
Przygotowanie strony serwerowej zajmuje mniej niż pół godziny, ale decyduje o tym, ile obsługi maszyna będzie wymagać przez następne miesiące. Ogranicz dostęp, poprawnie otwórz porty i jasno skonfiguruj uwierzytelnianie; później pozostanie już tylko rutynowa administracja.
