Dlaczego reguła portu źródłowego psuje jedną z twoich ścieżek SSH

Dopasowanie „sport 22” nie mówi, do którego wpisu SSH należy odpowiedź. Ogranicz regułę polityki do przepływu zarządzania zamiast jednej tabeli tylko dla WAN.

Dwa wpisy zarządzania na jednym hoście, jeden port usługi i reguła polityki, która miała pomóc obu. Reguła pasuje do portu źródłowego 22, wysyła wyszukiwanie do tabeli, która zna tylko domyślne ustawienie WAN, a wpis VPN przestaje odpowiadać na nowe logowania, podczas gdy wpis bezpośredni nadal działa. Nic w tym nie jest tajemnicze, gdy selektor zostanie odczytany poprawnie. Port źródłowy identyfikuje usługę, a nie ścieżkę, którą przyszło połączenie.

Dwa wpisy, jeden port usługi

Host ma adres po stronie LAN i adres VPN, a sshd nasłuchuje na obu. Sesja bezpośrednia i sesja tunelowa dzielą więc port usługi i różnią się tylko tym, który adres lokalny odbiera połączenie.

Ta różnica wystarcza do wyboru ścieżki odpowiedzi i jest dokładnie tą różnicą, którą odrzuca reguła oparta na porcie. Obie sesje tworzą odpowiedzi, których port źródłowy to 22, więc reguła pasująca do tego portu nie może ich rozdzielić. Wysyła oba wyszukiwania do tej samej tabeli, a jedno z nich otrzymuje odpowiedź, która nie pasuje. Poprawka polega na dopasowaniu atrybutu, który naprawdę się różni.

Przydzielenie każdemu wpisowi własnego portu też by działało, a traktowanie tego jako wymogu jest wyborem projektowym, nie właściwością SSH.

Przeczytaj regułę, potem tabelę

Reguła polityki to uporządkowany selektor, a pierwsza, która zwróci użyteczną odpowiedź, kończy wyszukiwanie. Przeczytaj listę po kolei i zwróć uwagę, która reguła może wygrać.

Następnie przeczytaj tabelę, na którą wskazuje ta reguła, ponieważ reguła, która rozwiązuje się skutecznie, nie jest regułą, która rozwiązuje się użytecznie. Tabela zawierająca tylko trasę domyślną wysyła odpowiedź pochodzącą z VPN przez interfejs WAN. Bardziej szczegółowa trasa w późniejszej tabeli nigdy nie jest sprawdzana, dlatego dodanie drugiej tabeli tak często nic nie zmienia. Wybrana tabela jest tym, co trzeba zbadać.

ip -4 rule show
ip route show table 100
ip route show table main

Te dwa wyniki razem wyjaśniają rezultat; każdy z osobna zaprasza do błędnego wniosku.

Ogranicz regułę do przepływu, który masz na myśli

Atrybutem, który rozdziela dwa wpisy, jest lokalny adres źródłowy. Reguła pasująca do tego adresu wysyła tylko sesje tunelowe do prywatnej tabeli, a sesje bezpośrednie pozostawia w tabeli głównej.

Tę regułę trzeba połączyć z tabelą zawierającą prywatną trasę i trasę powrotną dla tej podsieci. Ogranicz obie do ruchu zarządzania, a nie do każdej usługi na hoście. Reguła, która przechwytuje cały ruch z tego adresu, przekieruje też wszystko inne, co host stamtąd wysyła. Wąskie wygrywa tu z przebiegłym, ponieważ następna osoba musi to przeczytać.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Jeśli oba wpisy zostaną przetłumaczone na jeden adres lokalny, ta różnica znika, a projekt potrzebuje zamiast tego stanu świadomego połączenia.

Trzymaj osobno nasłuchiwacz, uprawnienie i wybór odpowiedzi

Trzy osobne rzeczy muszą być prawdziwe, zanim sesja zadziała: adres istnieje, usługa na nim nasłuchuje, a odpowiedź znajduje drogę powrotną. Zmiana trasy naprawia tylko trzecią.

Konfiguracja nasłuchiwacza to osobny plik i osobne przeładowanie, a wiele adresów nasłuchu jest normalnych. Uwierzytelnianie to znów trzecia decyzja, a wyjątek w routingu nikomu nie daje dostępu. Zachowaj weryfikację klucza hosta, uwierzytelnianie konta i ograniczenia źródła na obu wpisach i oprzyj się pokusie osłabienia pozostałych kontroli tunelu, żeby jedna ścieżka zarządzania działała.

Utrzymuj kanał odzyskiwania, który nie zależy od ścieżki, którą zmieniasz, bo błąd tutaj blokuje samą poprawkę.

Udowodnij to nową sesją, a nie starą

Ustanowiony terminal niczego nie dowodzi, ponieważ został dopuszczony przed zmianą. Otwórz nową sesję przez każdy zamierzony wpis.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Następnie powtórz ponowne połączenie VPN i spróbuj jeszcze raz, ponieważ trasa, która przetrwa ponowne połączenie, nie jest tym samym co trasa dodana do tabeli, którą ponowne połączenie czyści. Obserwuj odrzucone źródła osobno od dozwolonych, żeby zablokowana próba nie ukryła się za działającą sesją. Zapisz adres lokalny, regułę i tabelę obok wyniku. Jeśli zamiast tego podzielisz porty, zapisz to jako decyzję operacyjną, a nie ograniczenie SSH.

Powiązane artykuły