Pozwól jednemu klientowi OpenVPN połączyć się przez SSH z innym bez otwierania puli

Zostaw client-to-client wyłączone, pozwól jądrze przekazać jeden strumień, a resztę puli zostaw zamkniętą. Dwie reguły na serwerze i jedna w miejscu docelowym.

Jeden klient musi dotrzeć do usługi SSH innego klienta, a reszta puli powinna pozostać tak odizolowana jak dziś. Kuszacym przełącznikiem jest client-to-client, który włącza dostęp między równorzędnymi klientami dla wszystkich naraz i oddaje decyzję OpenVPN zamiast jądru. Węższa odpowiedź zostawia ten przełącznik wyłączony i pozwala własnemu routingowi i zaporze serwera przenieść dokładnie jeden strumień.

Mechanizm liczy się bardziej niż treść reguły, bo oba podejścia umieszczają pakiet w różnych miejscach. Wiedza, które wybrano, wyjaśnia zarówno regułę, która wydaje się nic nie robić, jak i drugiego klienta, który łączy się bez niej.

Dokąd client-to-client przenosi pakiet

Gdy client-to-client jest włączone, serwer przekazuje pakiet drugiego klienta wewnętrznie, zamiast wysyłać go z powrotem przez urządzenie tunelu, więc pakiet nigdy nie trafia na ścieżkę przekazywania jądra. To wygodne i oznacza też, że zapora nigdy nie widzi strumienia, który powinna pilnować. Zostaw opcję wyłączoną, a serwer skieruje pakiet z powrotem przez to samo interfejs, co stawia go przed netfilter. To samo interfejs na wejściu, to samo na wyjściu, i łańcuch FORWARD ma głos.

Zamiana jest wyraźna: zyskujesz punkt polityki i przejmujesz pracę routingu i przekazywania, którą skrót wykonywał za ciebie. Ta praca jest mała dla jednego strumienia i rośnie z każdym dodanym wyjątkiem. Policz wyjątki teraz, bo to w zestawie reguł naprawdę żyje polityka między klientami.

Ścieżka, którą naprawdę pokonuje pakiet drugiego klienta

Załóż usługę Linux Community OpenVPN 2.6, przetwarzanie TUN w przestrzeni użytkownika zamiast DCO, topologię podsieci, tun0 i pulę 10.44.0.0/24 z klientem A pod 10.44.0.21 i klientem B pod 10.44.0.37. Przy topologii podsieci adres i maska otrzymane przez A już obejmują pulę, więc A wysyła pakiet do urządzenia tunelu bez dodatkowej wypychanej trasy. Sprawdź rzeczywistą trasę na A, zamiast zakładać jakąś.

Na serwerze pakiet przychodzi zaadresowany do B, co nie jest adresem lokalnym, więc jest przekazywany. Przekazywanie IPv4 musi być włączone, aby to w ogóle nastąpiło, a wyszukiwanie trasy musi wysłać pakiet z powrotem przez tun0. Dlatego zapora widzi przekazywany strumień z tym samym interfejsem po obu stronach, i to jest szczegół, który pomija większość zestawów reguł. Nie ma tu potrzeby tłumaczenia źródła, a to właśnie zachowanie adresu A w całości pozwala B zastosować własną regułę opartą na źródle.

Dwie reguły na serwerze, w tej kolejności

Trzy reguły niosą całe zezwolenie: przekazywanie, wyjątek dla pary i domyślne odrzucenie dla pary tunelu. Reguła akceptacji nazywa parę i usługę, więc zezwolenie przetrwa rosnącą pulę. Umieść ją przed jakimkolwiek ogólnym zakazem ruchu tunel-tunel, bo wygrywa pierwsze dopasowanie:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Te polecenia są ilustracyjne i należą do mechanizmu, którego twój host używa do utrwalania reguł; wstawka w czasie działania znika przy następnym rozruchu. To reguła stanowa pozwala odpowiedziom B i uzgadnianiu TCP wrócić bez drugiej, lustrzanej akceptacji.

Sprawdź potem liczniki, a nie listę reguł, bo reguła, która nigdy nie pasuje, wygląda identycznie jak działająca. Jeśli liczniki pozostają na zero, pakiet nie idzie ścieżką, którą myślisz.

Co B nadal musi dopuścić

B uruchamia usługę SSH, więc B decyduje, czy coś nasłuchuje na adresie tunelu i czy jego własna zapora hosta akceptuje źródło. Zezwolenie sieciowe na serwerze nie jest pozwoleniem dla żadnego konta na B, a weryfikacja klucza hosta i uwierzytelnianie użytkownika nadal obowiązują jak z każdego innego miejsca.

Najpierw przetestuj przypadek pozytywny: nowe połączenie SSH z A na adres tunelu B, przyjęte z oczekiwanym kluczem hosta. Potem przetestuj innego klienta lub inny port i potwierdź, że jest odrzucane, bo zezwolenie, które po cichu pozwala na wszystko, jest nieodróżnialne od działającego, dopóki nie zacznie mieć znaczenia. Obie połowy tego testu są konieczne, a drugą ludzie pomijają.

Zapisz przydzielone adresy, rzeczywiste trasy na obu klientach i dokładne reguły na serwerze i na B. Udany ping do bramy lub otwarty port na serwerze niczego z tego nie dowodzi, bo oba mogą być prawdą, gdy przekazywanie między klientami jest wciąż zablokowane. Zapisz te liczby, gdy tunel jest podniesiony, bo adres, który klient otrzyma po ponownym połączeniu, może być inny.

Powiązane artykuły