Zapora chmurowa kontra zapora hosta dla serwera VPN
Dwa filtry strzegą tego samego portu VPN. Przejdź kolejność granic od polityki chmury do nasłuchu na gościu, a potem udowodnij poprawkę świeżą sesją.
Zezwól portowi VPN w polityce chmury, a uścisk dłoni i tak może umrzeć na instancji: gość uruchamia własny filtr i własne powiązanie nasłuchu, a każde z nich może odrzucić to, co chmura zatwierdziła. Bywa i odwrotnie, gdy reguła hosta pozwala na port, a polityka wyżej odrzuca go pierwsza. Dwaj właściciele, dwa zestawy reguł, jedna ścieżka pakietu. Przejdź ją po kolei, zamiast zgadywać na najbardziej podejrzanej warstwie.
Zacznij na krawędzi i idź do środka
Kolejność jest stała: publiczny punkt końcowy, interfejs zasobu, dołączona polityka chmury, adres gościa, nasłuch procesu, lokalne reguły wejścia. Każdy etap albo przepuszcza pakiet, albo kończy dochodzenie, dlatego zaczynanie od gościa traci najwięcej czasu.
Przekierowany ruch klienta to osobny etap, sprawdzany po dekapsulacji tunelu. Warstwa chmury widzi tylko tunel zewnętrzny, więc może zatwierdzić połączenie i mimo to nie mieć nic wspólnego z żądaniem usługi wewnętrznej. Tunel, który się łączy, ale nie dociera do hosta wewnętrznego, zwykle wskazuje na przekazywanie, a nie na zamknięty port.
Przeczytaj politykę chmury, zanim dotkniesz gościa
Potwierdź regułę wejścia dla portu VPN, jej protokół i zakres źródła zgodny z twoim klientem testowym. Sprawdź też listę kontroli dostępu podsieci: drugi filtr z własnymi regułami i wartościami domyślnymi. Oba muszą pozwalać na przepływ, zanim pakiet dotrze do instancji. Zezwolenie w jednym i odmowa w drugim to typowa postać tego błędu.
Zawęź zakres, aż będzie coś znaczył. Otwarcie portu VPN dla całego internetu łatwo udowodnić i trudno obronić, a reguła przypięta do jednego adresu łamie się, gdy twój klient testowy zmieni sieć. Zapisz identyfikator reguły i właściciela polityki, aby następna zmiana była możliwa do wytropienia do osoby.
Potwierdź nasłuch, potem łańcuch wejścia
Na instancji sprawdź, czy proces VPN jest powiązany z oczekiwanym adresem i portem, na przykład za pomocą ss -lntp 'sport = :1194'. Demon powiązany tylko z 127.0.0.1 przyjmuje klientów lokalnych i nic przez tunel, co z zewnątrz wygląda dokładnie jak filtrowany port.
Potem przeczytaj reguły lokalne w składni, której użyłbyś do ich zmiany, na przykład iptables -S INPUT lub nft list chain inet filter input. Reguła zapisana do pliku, ale nigdy nie wczytana, albo domyślne odrzucanie bez pasującego zezwolenia po cichu wyrzuca pakiety. Dla bramy przekazującej sprawdź też ustawienia przekazywania i trasy powrotnej. One decydują, co dzieje się z pakietami trasowanymi przez instancję, a nie zaadresowanymi do niej.
Ze stanem w jednej warstwie, bez stanu w następnej
Grupy zabezpieczeń pamiętają przepływy, na które pozwoliły, i wpuszczają odpowiedzi z powrotem. Listy kontroli dostępu podsieci i wiele zapór hosta nie trzymają takiego stanu, więc reguła obejmująca tylko kierunek wychodzący przepuszcza żądanie i wyrzuca odpowiedź. Nigdy nie przenoś założenia o ruchu powrotnym między warstwami bez przeczytania reguły drugiej warstwy (second layer's rule).
Liczniki rozstrzygają to szybciej niż czytanie każdej reguły na koncie. Rosnący licznik oznacza, że pakiet dotarł i tam został wyrzucony, a zamrożony na zerze, że nigdy tak daleko nie dotarł; iptables -vnL INPUT i nft list ruleset pokazują te liczby, gdy reguły zostały wczytane z licznikami.
Testuj świeżą sesją, nie żywą
Zostaw sieć źródłową i profil testowy w spokoju, porównując widoki, i otwieraj nowe połączenie po każdej zmianie. Dotarcie do konsoli web na 443 nic nie mówi o tym, czy demon VPN jest powiązany z 1194, więc testuj port, którego potrzebujesz. Istniejąca sesja jest tu najgorszym świadkiem. Działa dalej, gdy każde nowe logowanie jest odrzucane.
Przed edycją zdalnej polityki zapewnij sobie drogę powrotu, która nie zależy od ścieżki, którą zmieniasz. Potem otwórz drugą sesję administracyjną obok testu VPN: wcześniej ustanowiona może przeżyć regułę blokującą nowe. Zapisz obu właścicieli polityk, aby żadna przebudowa nie przywróciła połowy ścieżki; jeśli obie warstwy się zgadzają, a tunel nadal zawodzi, przechwyć ruch na interfejsie gościa i sprawdź adres i port, których klient naprawdę używa.