Przesłać dalej do klienta VPN?

Natrafiłem na trochę układanki i nie miałem szczęścia znaleźć rozwiązania. Obecnie jestem (niestety) połączony z siecią przez Verizon 3G. Filtrują cały ruch przychodzący, więc nie mogę otworzyć portów, aby zaakceptować połączenia.

Obecnie mam maszynę wirtualną z linuksem na linode.com i przyszła mi do głowy myśl, aby zainstalować pptpdi spróbować iptablesprzekierować porty. Mam pptpdzainstalowany i moja maszyna do domu łączy się szczęśliwie. To powiedziawszy, oto kilka ogólnych informacji:

Serwer (Debian) WAN IP: xxxx na eth0 - pptpd IP: rrr1 na ppp0 - IP klienta VPN: rrr100

Aby sprawdzić, czy nie oszaleję, próbowałem nawiązać pewne połączenia z serwera do otwartych portów na kliencie, a klient akceptuje połączenia za pośrednictwem adresu IP VPN.

To, co chcę osiągnąć, to:

Internet -> WAN IP: Port -> Przekaż do klienta VPN IP: Port

Na przykład, jeśli miałbym otwarty port 6000 na moim kliencie, osoba mogłaby telnetować do xxxx: 6000, a serwer przechwyciłby to i przesłał go do 192.168.3.100:6000.

Próbowałem co najmniej 20 różnych konfiguracji Googled up iptablesi żadna jeszcze nie działała. Czy ktoś ma jakieś pomysły, a może zupełnie inne podejście, o którym być może nie wiem? Celem jest słuchanie przez strasznie zaporowe połączenie, najlepiej zarówno TCP, jak i UDP.

Aby to działało, musisz wykonać trzy czynności na serwerze VPN (Linode):

1. Musisz włączyć przekazywanie adresów IP:

   sysctl -w net.ipv4.ip_forward=1
   

2. Ustaw docelowy NAT (DNAT), aby przekierować port. Prawdopodobnie już to wymyśliłeś, ponieważ jest to standardowa funkcja przekierowywania portów, ale dla kompletności:

   iptables -t nat -A PREROUTING -d x.x.x.x -p tcp --dport 6000 -j DNAT --to-dest y.y.y.100:6000
   

3. Skonfiguruj źródłowy NAT (SNAT), aby z perspektywy klienta VPN połączenie pochodziło z serwera VPN:

   iptables -t nat -A POSTROUTING -d y.y.y.100 -p tcp --dport 6000 -j SNAT --to-source y.y.y.1
   

Powodem, dla którego potrzebujesz SNAT, jest to, że w przeciwnym razie klient VPN wyśle ​​swoje pakiety zwrotne bezpośrednio do hosta, który zainicjował połączenie (zzzz) za pośrednictwem domyślnej bramy (tj. Verizon 3G), a nie przez VPN. Zatem źródłowy adres IP na pakietach zwrotnych będzie Twoim adresem Verizon 3G, a nie xxxx Powoduje to różnego rodzaju problemy, ponieważ zzzz naprawdę zainicjował połączenie z xxxx

W większości konfiguracji przekierowania portów SNAT nie jest potrzebny, ponieważ host wykonujący przekierowanie portów jest również domyślną bramą dla hosta docelowego (np. Routera domowego).

Pamiętaj również, że jeśli chcesz przekierować port 6000 na inny port (powiedzmy 7000), to reguła SNAT powinna pasować do 7000, a nie 6000.

Miałem również ten problem i próbowałem go rozwiązać godzinami. Oto moje rozwiązanie:

• Miałem więcej niż jeden VPNClientz tym samym IPAddress. Dałem więc każdemu z nich szumIPAddress

Zdefiniuj katalog, w którym powinny być przechowywane skrypty klienta, np. / Etc / openvpn / staticclients i utwórz katalog

mkdir /etc/openvpn/staticclients

Dodaj ten katalog jako opcję do pliku konfiguracyjnego openvpn na serwerze:

client-config-dir /etc/openvpn/staticclients

Dla każdego klienta musisz utworzyć plik. Nazwa pliku musi być zgodna z common nameatrybutem określonym w certyfikacie klienta. To polecenie pobiera CN z certyfikatu komputera:

Ten przykład wypycha IPAddress10.1.134.110/10.1.134.109 do klienta z common name TESTCLIENT, a także wypycha dodatkową trasę dla podsieci 10.1.135.0.

cat /etc/openvpn/staticclients/TESTCLIENT

ifconfig-push 10.1.134.110 10.1.134.109
push "route 10.1.135.0 255.255.255.0 10.1.134.62"

• http://www.yougetsignal.com/tools/open-ports/ i http://canyouseeme.org/ nie wykryły poprawnie portów. Musiałem dodatkowo uruchomić aplikację na kliencie, aby strony były w stanie zobaczyć te porty.

• Nie ma potrzeby dodatkowych SNATzasad. Potrzebne były tylko te zasady:

sysctl -w net.ipv4.ip_forward=1

iptables -t nat -A PREROUTING -p tcp --dport 28006 -j DNAT --to 10.1.134.110

Większość serwerów ma wyłączone przekazywanie adresów IP w domyślnej konfiguracji. Musisz włączyć tę opcję, jeśli chcesz przekierowywać połączenia przychodzące przez VPN.

Spróbuj tego:

sysctl -w net.ipv4.ip_forward = 1

Mam na myśli oprócz konfiguracji iptables.

To, co chcesz osiągnąć, jest (prawdopodobnie) bardzo możliwe w przypadku pptpdOpenVPN i iptables, jednak może okazać się lepszym kandydatem do tego przypadku użycia. Właśnie przeczytałem ten, który opisuje, jak skonfigurować tinc dla dokładnie tego przypadku użycia. Jest to (potencjalnie prostsza) alternatywa dla części pptdplub OpenVPN. Wtedy potrzebujesz dokładnie tych samych reguł dla iptables.