Przekierowanie portów ssh Linux iptables (odrzucenie Marsa)


12

Mam bramę Linux wykonującą NAT dla mojej sieci domowej. Mam inną sieć, do której chciałbym transparentnie przekierowywać pakiety, ale tylko do / z określonych adresów IP / portów (tj. Nie VPN). Oto kilka przykładów adresów IP i portów do pracy:

Source          Router          Remote Gateway     Remote Target
192.168.1.10 -> 192.168.1.1 ->  1.2.3.4        ->  192.168.50.50:5000

Chciałbym, aby maszyna źródłowa mogła komunikować się z określonymi portami w zdalnym celu, tak jakby była bezpośrednio routowalna z routera. Na routerze eth0 jest siecią prywatną, a eth1 jest połączony z Internetem. Remote Gateway to kolejna maszyna Linuksa, do której mogę ssh i może kierować bezpośrednio do Remote Target.

Moja próba prostego rozwiązania polega na skonfigurowaniu przekierowania portów ssh na routerze, takich jak:

ssh -L 5000:192.168.50.50:5000 1.2.3.4

Działa to dobrze dla routera, który może teraz łączyć się lokalnie z portem 5000. Tak więc „telnet localhost 5000” zostanie podłączony do 192.168.50.50:5000 zgodnie z oczekiwaniami.

Teraz chcę przekierować ruch ze źródła i ścieżkę przez ustanowiony tunel ssh. Próbowałem do tego reguły NAT:

iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 127.0.0.1:5000

a ponieważ router jest już moją bramą NAT, ma już wymaganą regułę przekierowania:

-A POSTROUTING -s 192.168.1.0/24 -o eth1 -j MASQUERADE

Większość pytań i odpowiedzi na tej stronie lub w innym miejscu wydaje się dotyczyć portów przesyłania dalej lub NAT-spinki do włosów, z których oba działają dobrze gdzie indziej, ale żadne z nich nie dotyczy tej sytuacji. Z pewnością mógłbym przesłać DMZ porty Remote Target przez Remote Gateway, ale nie chcę, aby porty były dostępne w Internecie, chcę, aby były dostępne tylko przez bezpieczny tunel SSH.

Najlepsza odpowiedź, jaką mogę znaleźć, dotyczy odrzucenia pakietu marsjańskiego w jądrze Linux:

iptables, jak przekierować port z pętli zwrotnej?

Włączyłem rejestrowanie Marsjan i potwierdziłem, że jądro odrzuca te pakiety jako Marsjanie. Tyle że nie są: wiem dokładnie, po co są te pakiety, skąd pochodzą i dokąd idą (mój tunel ssh).

Przedstawione tam rozwiązanie „ronda” dotyczy tego pierwotnego pytania, ale nie dotyczy mojej sprawy.

Jednak pisząc / badając to pytanie, obejrzałem swój problem, używając powiązania źródłowego adresu IP SSH w następujący sposób:

ssh -L 192.168.1.1:5000:192.168.50.50:5000 1.2.3.4
iptables -t nat -D PREROUTING -i eth0 -p tcp -s 192.168.1.10 --dport 5000 -d 1.2.3.4 -j DNAT --to-destination 192.168.1.1:5000

Ponieważ nie używam sprzężenia zwrotnego, omija to odrzucenie Marsa.

Nadal zamieszczam pytanie tutaj z dwóch powodów:

  1. W nadziei, że ktoś, kto próbuje zrobić coś podobnego w przyszłości, znajdzie to w swoich wyszukiwaniach, a to obejście może im pomóc.
  2. Nadal wolę pomysł, aby mój port ssh przekazywał połączenie tylko do pętli zwrotnej i był w stanie kierować do nich przez iptables. Ponieważ wiem dokładnie, czym są te pakiety i dokąd zmierzają, czy nie powinno być sposobu, aby je oflagować jako takie, aby filtrowanie marsjańskie systemu Linux ich nie odrzucało? Całe moje wyszukiwanie na ten temat prowadzi do rp_filter, co wcale nie pomogło w moich testach. I nawet jeśli zadziałało, nie jest ono specyficzne dla pakietów, na które staram się zezwolić.

Jestem zainteresowany udziałem w moim pytaniu i obejściu dla ogólnego wyszukiwania, aby zaoszczędzić komuś godziny poszukiwań, które wymyśliłem tylko w celu znalezienia ślepych zaułków, a także mam nadzieję, że ktoś odpowie na część mojego pytania zwrotnego / marsjańskiego, która wciąż pozostaje otwarta Dla mnie.


Po dalszym czytaniu postu Meta na UL vs. SF zauważam również prośbę Michaela, by nie krzyżować. Przesłuchałem to tylko dlatego, że zostało to specjalnie oznaczone jako nietypowe w SF, więc jeśli bardziej odpowiednie i możliwe jest po prostu przeniesienie pierwotnego pytania i zamknięcie tego, to też byłoby świetnie.
Mark

czy umieszczenie net.ipv4.conf.default.rp_filter = 0 i net.ipv4.conf.all.rp_filter = 0 w pliku /etc/sysctl.conf i wykonanie polecenia „sudo sysctl -p” rozwiązuje problem?
Rui F Ribeiro

Próbowałem zastosować oba oba bezpośrednio, tj. 'sysctl net.ipv4.conf.default.rp_filter = 0', w tym także jeden dla mojego konkretnego interfejsu prywatnego. Potwierdziłem, że są ustawione przez 'sysctl -a', jednak pakiety marsjańskie do 127.0.0.1 są nadal odrzucane. I nawet jeśli to zadziałało, otwarcie wszystkich moich interfejsów na Marsjan NIE jest tym, czego chcę. Nie chcę nawet otwierać jednego interfejsu (albiet private). Wiem dokładnie, na które pakiety marsjańskie chcę zezwolić i pragnę / mam nadzieję na wyrażenie NAT / magle iptables, które pozwoli mi to osiągnąć.
Mark

Możesz chcieć net.ipv4.conf.default.rp_filter = 2 i kilka innych reguł iptables
Rui F Ribeiro

Odpowiedzi:


1

Problem z zrobieniem DNAT do 127.0.0.1:5000 polega na tym, że gdy strona zdalna odpowiada, pakiety te wracają do silnika routingu, jakby były lokalnie (od 127.0.0.1), ale mają zewnętrzny adres docelowy. SNAT / MASQUERADE pasujące do zewnętrznego interfejsu złapałyby je i przepisały, ale decyzje o routingu, które muszą być podjęte, aby pakiety dotarły do ​​tego interfejsu, były pierwsze i nie zezwalają na te pakiety, które są domyślnie fałszywe. Mechanizm routingu nie może zagwarantować, że pamiętasz, aby później to przepisać.

Zamiast tego należy odrzucić wszelkie połączenia zewnętrzne do 192.168.1.1:5000 w iptables INPUT inne niż te pochodzące z 192.168.1.10, używając !argumentu przed podaniem -sadresu źródłowego. Jeśli użyjesz resetowania TCP jako mechanizmu odrzucania ( -j REJECT --reject-with tcp-resetzamiast domyślnego miejsca docelowego ICMP nieosiągalnego), będzie on w dużej mierze identyczny z sytuacją, w której nic nie nasłuchiwałoby pod tym adresem: kombinacją portów w odniesieniu do świata zewnętrznego.


0

Użyłbym openVPN do stworzenia tunelu od routera do RemoteGateway.

Następnie na routerze dodałbym trasę:

route add -host RemoteTarget gw RemoteGateway-VPNaddress

używaj prostej reguły iptables, gdziekolwiek chcesz ograniczyć porty, do których zezwalasz Sourceowi się dostać.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.