Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2017-04-12 17:02:50

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Iptables - ruch z routera przez VPN

Witam.
Potrzebuje pomocy zwiazanej z konfiguracja iptables na maszynie, ktora robi za router w mojej sieci.
Glowna potrzeba: dostep przez internet do rejestratora kamer z monitoringu.
Przeczytalem tysiac tutoriali itp. Niestety nie radze sobie z Iptables.
Mam VPS, ze stalym IP i z odpalonym serwerem OpenVPN, ktory przyjmuje polaczenia i przez ten tunel puszcza ruch.
W chwili obecnej system dziala tak, ze jak odpale na routerze OpenVPN to ruch od routera w internet idzie przez tunel, ale ruch z urzadzen za routerem dociera tylko do routera i dalej go puszcza.


Zalaczam schemat sieci. Jesli potrzeba jakies logi, lub pliki conf to mowcie.
I naprawde niech sie ktos nade mna zlituje bo osiwieje przedwczesnie... :)[img]http://eksprespak.pl/img.jpg[/img]

Offline

 

#2  2017-04-12 19:26:25

  stepien86 - Członek DUG

stepien86
Członek DUG
Skąd: Łódź
Zarejestrowany: 2006-03-26

Re: Iptables - ruch z routera przez VPN

Pokaż wynik polecenia: # ip route show ( z routera na debianie)
i jeszcze zapodaj konfiga tego iptablesa na routerze co tam wyklikałeś, może forward wystarczy dodać tylko.

Ostatnio edytowany przez stepien86 (2017-04-12 19:29:34)


manual ponad wszysytko....konsola ponad manual

Debian GNU Linux

Offline

 

#3  2017-04-13 11:00:46

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Re: Iptables - ruch z routera przez VPN

Ok prosze bardzo.
Przed odpaleniem OpenVPN

Kod:

default via 192.168.0.1 dev eth1 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.10 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1

Po uruchomieniu

Kod:

0.0.0.0/1 via 192.168.3.1 dev tun0 
default via 192.168.0.1 dev eth1 
51.254.208.185 via 192.168.0.1 dev eth1 
128.0.0.0/1 via 192.168.3.1 dev tun0 
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.10 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1 
192.168.3.0/24 dev tun0  proto kernel  scope link  src 192.168.3.2

Iptables:

Kod:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  192.168.3.0/24       192.168.1.0/24       ctstate NEW

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Offline

 

#4  2017-04-15 20:18:28

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Re: Iptables - ruch z routera przez VPN

Ponawiam prosbe do zgromadzonych tutaj :P

Offline

 

#5  2017-04-15 21:04:00

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Iptables - ruch z routera przez VPN

Do OpenVPN musisz puścić routing default, a tylko OpenVPN (jako usera systemowego) albo ruch do VPSa (routing do hosta) puścić przez  eth1.

Masz problem nie z netfiterem/iptables tylko z routingiem.

Przy okazji, OpenVPN moim zdaniem troszkę lepiej chodzi przez interfejsy TAP niż TUN, ale wtedy  musi działać na protokole TCP, nie UDP.

Jeśli chcesz na TUP/TAP wyciągnąć większe prędkości, niż 10Mbit, to potrzebujesz tej łatki na kernele (na obu końcach tunelu):

Kod:

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 8c8dc16..64f4dcc 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -950,6 +950,9 @@  static void tun_net_init(struct net_device *dev)
         dev->addr_len = 0;
         dev->mtu = 1500;
 
+        /* Set default speed 1000M */
+        tun->flags |= TUN_CTRL_SPD_1000;
+
         /* Zero header length */
         dev->type = ARPHRD_NONE;
         dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
@@ -2257,9 +2260,18 @@  static struct miscdevice tun_miscdev = {
 
 static int tun_get_settings(struct net_device *dev, struct ethtool_cmd *cmd)
 {
+    struct tun_struct *tun = netdev_priv(dev);
+
+    /*Get the speed of tun*/
+    if (tun->flags & TUN_CTRL_SPD_1000) {
+        ethtool_cmd_speed_set(cmd, SPEED_1000);
+    } else if (tun->flags & TUN_CTRL_SPD_100) {
+        ethtool_cmd_speed_set(cmd, SPEED_100);
+    } else
+        ethtool_cmd_speed_set(cmd, SPEED_10);
+
     cmd->supported        = 0;
     cmd->advertising    = 0;
-    ethtool_cmd_speed_set(cmd, SPEED_10);
     cmd->duplex        = DUPLEX_FULL;
     cmd->port        = PORT_TP;
     cmd->phy_address    = 0;
@@ -2287,6 +2299,27 @@  static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
     }
 }
 
+static int tun_set_settings(struct net_device *dev, struct ethtool_cmd *cmd)
+{
+    struct tun_struct *tun = netdev_priv(dev);
+    u32 speed = ethtool_cmd_speed(cmd);
+
+    if (10 == speed) {
+        tun->flags &= ~TUN_CTRL_SPD_100;
+        tun->flags &= ~TUN_CTRL_SPD_1000;
+        tun->flags |= TUN_CTRL_SPD_10;
+    } else if (100 == speed) {
+        tun->flags &= ~TUN_CTRL_SPD_10;
+        tun->flags &= ~TUN_CTRL_SPD_1000;
+        tun->flags |= TUN_CTRL_SPD_100;
+    } else {
+        tun->flags &= ~TUN_CTRL_SPD_10;
+        tun->flags &= ~TUN_CTRL_SPD_100;
+        tun->flags |= TUN_CTRL_SPD_1000;
+    }
+    return 0;
+}
+
 static u32 tun_get_msglevel(struct net_device *dev)
 {
 #ifdef TUN_DEBUG
@@ -2307,6 +2340,7 @@  static void tun_set_msglevel(struct net_device *dev, u32 value)
 
 static const struct ethtool_ops tun_ethtool_ops = {
     .get_settings    = tun_get_settings,
+    .set_settings    = tun_set_settings,
     .get_drvinfo    = tun_get_drvinfo,
     .get_msglevel    = tun_get_msglevel,
     .set_msglevel    = tun_set_msglevel,
diff --git a/include/uapi/linux/if_tun.h b/include/uapi/linux/if_tun.h
index 50ae243..78a09a7 100644
--- a/include/uapi/linux/if_tun.h
+++ b/include/uapi/linux/if_tun.h
@@ -66,6 +66,11 @@ 
 #define IFF_PERSIST    0x0800
 #define IFF_NOFILTER    0x1000
 
+/*add speed control, default 1000M*/
+#define TUN_CTRL_SPD_10         0x0020
+#define TUN_CTRL_SPD_100        0x0040
+#define TUN_CTRL_SPD_1000       0x0080
+
 /* Socket options */
 #define TUN_TX_TIMESTAMP 1

Używam tej łatki od dawna, na źródła z kernel.org wchodzi czysto - wszystkie z serii 4.7.x, 4.8.x i 4.9.x.

Pozdro

Ostatnio edytowany przez Jacekalex (2017-04-15 21:30:11)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#6  2017-04-15 21:40:28

  lis6502 - Łowca lamerów

lis6502
Łowca lamerów
Skąd: Stalinogród
Zarejestrowany: 2008-12-04

Re: Iptables - ruch z routera przez VPN

Pozwolę sobie wrzucić swoje trzy grosze jako gość który wczoraj zestawił OpenVPNa do domu

Przy okazji, OpenVPN moim zdaniem troszkę lepiej chodzi przez interfejsy TAP niż TUN,[/quote]
Mocno się nie zgodzę- ja miałem niesamowite problemy z zestawieniem łącza w L2- pomijając fakt że chcąc korzystać z zasobów zza VPNa na Androidach trzeba rootować urzadzenie.

Zęby prawie sobie połamałem z VPNem, a w moim wypadku chodziło o firewalla ;)
Także [b]immcio[/b], sprawdź po zestawieniu tunelu czy jesteś w stanie pingować 192.168.3.1. Logi iptables z serwera VPN też przydałyby się, bo ja tylko dzięki logom doszedłem do wstępnych błędnych opcji konfiguracji.
Dalej: na początku cos pisałeś że po zestawieniu tunelu ruch idzie przez niego- czyli jesteś w stanie przeglądać internety jako modem lte? W sensie, na komputerze- kliencie VPN po sprawdzeniu adresu IP pod jakim jesteś widziany pokazuje Ci adres nadany przez modem LTE?

Offline

 

#7  2017-04-15 22:10:32

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Iptables - ruch z routera przez VPN

Mocno się nie zgodzę- ja miałem niesamowite problemy z zestawieniem łącza w L2- [b]pomijając fakt że chcąc korzystać z zasobów zza VPNa na Androidach trzeba rootować urzadzenie[/b].[/quote]
Co to za problemy z tym rootowaniem?

Na Linuksach i BSD wszyscy mamy dostęp do roota na swoich gratach,
i jakoś nasze systemy brykają jak dzikie bez żadnych problemów.

To co za problem z tym Andkiem?
Kupować tylko graty, które odblokujesz przez fastboota, i nie tracisz gwarancji po roocie (na co już  jest wyrok Europejskiego Trybunału Praw Człowieka).

To przecież nie dwumian Newtona, trzeba mieć tylko odrobinkę oleju w głowie przed zakupem.

Tam na rysunku Debian gada z VPSem, a jeszcze nie widziałem Andka bez roota na VPS. xD

Ostatnio edytowany przez Jacekalex (2017-04-15 22:12:32)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#8  2017-04-15 22:18:27

  lis6502 - Łowca lamerów

lis6502
Łowca lamerów
Skąd: Stalinogród
Zarejestrowany: 2008-12-04

Re: Iptables - ruch z routera przez VPN

Problemy są takie, że do utworzenia interfejsu TAP potrzebujesz superjuzka, a do TUN już nie :)
TUN spełnia swoją rolę nader wyśmienicie, chyba że masz coś co komunikuje się stricte po L2 jak jakieś discovery Mikrotików; ale ja z powodzeniem korzystam z zasobów NFS, HTTP, SSH przez interfejs TUN, czy to na lapku (gdzie mam ruta xD) czy na służbofonie (gdzie ruta mieć nie będę). Także nie widzę powodu by dla tak trywialnych zastosowań iść w schemat oparty o interfejsy TAP.
Na rysunku domyślam się że na VPSie nie stoi Andek, z rootem czy bez. Mówię o scenariuszu w którym OP chciałby podejrzeć obraz na żywo z kamer na jakimś andku.

Offline

 

#9  2017-04-15 22:41:12

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Iptables - ruch z routera przez VPN

Służbofona? Do szuflady grata, chyba że nie słyszałeś o Dual SIM - dual standby. xD

Przy okazji, ja nie  zabraniam używania TUN, tylko wolę TAP, bo po prostu przy TAP mam praktycznie normalną kartę sieciową VPNa, co mocno upraszcza życiorys.


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#10  2017-04-18 09:42:56

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Re: Iptables - ruch z routera przez VPN

[b]Jacekalex:[/b] Jakos od poczatku intuicyjnie myslalem o TAP. Po Twoim poscie postanowilem postawic vpn na tap. I pojawil sie pierwszy, dla mnie mocno nie zrozumialy problem. Mianowicie, czy mam robic bridge servera z eth0 na VPS? Jesli tak to jak skoro eth0 ma IP zewnetrzne VPS? W momencie kiedy bridguje tap0 z eth0 na VPS to wywala caly ruch do i z VPSa, dopiero restart calego networking przywraca IP, maske i reszte w ifconfig dla eth0. Wiem ze cala zabawa z OpenVPN jest prosta, ale jak dla mnie malo logiczna :P.

Pozdrawiam


___


Ok, wiec jeszcze raz wszystko od poczatku:
Ponizej nowa mysl jesli chodzi o polaczenie z VPS.
[img]http://eksprespak.pl/img2.jpg[/img]

Chodzi o to, zeby vps pelnil role gatewaya do LAN za NAT. Czyli, zeby dostac sie do LAN i np na rejestrator video, musze sie polaczyc z OpenVPN na VPS. Urzadzenie laczace sie z VPS stanie sie kolejnym urzadzeniem w LAN.
Takie zestawienie sprawy o wiele bardziej mi odpowiada.
Ide dobrym tokiem rozumowania, czy mnie ponioslo?

Czy na VPS musze cos ze soba bridgowac? Jesli tak to co i jak. Bo nie logicznym wydaje mi sie bridgowanie z obecnym eth0, poniewaz wyglada ono tak:

Kod:

eth0      Link encap:Ethernet  HWaddr fa:16:3e:07:3e:37  
          inet addr:51.254.208.185  Bcast:51.254.208.185  Mask:255.255.255.255
          inet6 addr: fe80::f816:3eff:fe07:3e37/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:21160 errors:0 dropped:0 overruns:0 frame:0
          TX packets:21209 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1234738 (1.1 MiB)  TX bytes:2107169 (2.0 MiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:267 errors:0 dropped:0 overruns:0 frame:0
          TX packets:267 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:19188 (18.7 KiB)  TX bytes:19188 (18.7 KiB)

W momencie, gdy probowalem bridgowac eth0 z tap0 na VPS, to ucinal sie caly ruch z i na VPS. Musialem z konsoli restartowac networking.
Z kolei odpalony bez bridge tworzy tap0, ale bez zadnych adresow:

Kod:

tap0      Link encap:Ethernet  HWaddr fa:16:3e:07:3e:37  
          UP BROADCAST PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

Polaczenie miedzy client - server bez ustawionych bridgow rowniez sie odbywa, ale nie ma odpowiedzi na ping ani z servera ani z klienta.

Jesli dobrze to wszystko rozumiem, to bridge musi nastapic miedzy tap0 a eth1 na routerze w lan za natem, czyli na polaczeniu clienta vpn.
Wszystkie tutoriale dotyczace TAP na VPN jakie znalazlem, nawet te pochodzace z manuala openvpn, dotyczyly sytuacji gdy server VPN znajduje sie w LAN, do ktorego sie laczy client i uzyskuje do niego dostep. W takiej sytuacji jest logiczne, ze bridguje sie tap z eth na serwerze. Ale w mojej sytuacji jest to kompletnie bez sensu...

Gdyby ktos mial chwile to prosze o wyjasnienie i pomoc.
Pozdrawiam

Offline

 

#11  2017-04-18 18:40:09

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Iptables - ruch z routera przez VPN

Nie mostkuj tap z eth0, tylko routing default puść na tap od VPNa.
Mostek interfejsu fizycznego z interfejsem wirtualnym do VPN to katastrofalna wtopa, która nie ma prawa działać.
Albo zrozumiesz sprawy routingu w linuxie, albo się w ogóle nie bierz za te systemy.

Tu masz dosyć ważny dokument po polsku:
www.przybytek.net/download/2.4routing.pdf

Ostatnio edytowany przez Jacekalex (2017-04-18 20:12:30)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#12  2017-04-18 19:20:56

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Re: Iptables - ruch z routera przez VPN

[b]@Jacekalex[/b]: Wiec dobrze myslalem. Poprostu sugerowalem sie wieloma tutorialami, ktore tak jak wspomnialem, nie przedstawialy mojej sytuacji.
Ok, dzieki za ten dokument. Jak uda mi sie postawic tego vpn w tej konfiguracji, to podziele sie tym
Pozdrawiam

Offline

 

#13  2017-04-18 20:21:31

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Iptables - ruch z routera przez VPN

Najprostsza konfiguracja routingu na OpenVPN:

Kod:

route add -host {server_vpn} gw 192.168.0.1 eth1

Czyli ta trasa po włączeniu VPNa

Kod:

51.254.208.185 via 192.168.0.1 dev eth1

była prawidłowa.

Problem był tu:

Kod:

default via 192.168.0.1 dev eth1

Bo po prostu, żeby programy leciały przez VPN, trasa default musi kierować do VPN, czyli:

Kod:

default via 192.168.3.1 dev tun0

Łatwiej taki cel osiągnąć na interfejsach TAP, ale nie zawsze da się je zastosować.

Ostatnio edytowany przez Jacekalex (2017-04-18 20:24:32)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#14  2017-04-18 20:49:32

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Re: Iptables - ruch z routera przez VPN

[b]@Jacekalex[/b]: No to jednak mam uzywac tun? Mysle ze tapem tez sie da...

Offline

 

#15  2017-04-18 21:19:02

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Iptables - ruch z routera przez VPN

TUN czy TAP, routing jest taki sam.

TAP ma tą przewagę, że jest interfejsem obsługującym L2, czyli praktycznie pełnowartościową, chociaż wirtualną kartą sieciową.
Jeśli można używać TAP, powinien działać lepiej, jeśli nie można założyć interfejsu TAP, zostaje TUN, też będzie działał.

Na połączeniu  VPS<>Debian zazwyczaj nie masz takich ograniczeń, jak np łącząc się ze smartfona, na którym nie masz roota.

Chyba że VPS jest na wirtualizacji OpenVZ albo LXC bez sterowników TUN/TAP, ale wtedy w ogóle byś VPNa nie odpalił.

Ostatnio edytowany przez Jacekalex (2017-04-18 21:21:10)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#16  2017-04-18 21:35:53

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Re: Iptables - ruch z routera przez VPN

Nie no na VPS jest tez debian, takze dostep do roota bede mial tu zawsze...
Wiec ok, bedzie TAP + routing do tego i ma smigac tak? Zadnych mostkow, poprostu odpowiednie tabele i kazde urzadzenie ktore sie prawidlowo polaczy z OpenVPN na VPS zostanie pelnoprawnym urzedzeniem w LAN za NAT?
Bo caly czas mnie frapuje kwestia zwiazana np z tym, ze nawet w oficjalnej dokumentacji OpenVPN calosc opiera sie na mostach, z tym ze w tamtych przypadkach VPN jest elemnetem LAN, i kazdy klient do tego lanu sie dolacza. A u mnie bedzie odwrotnie... Serwer ma byc furtka do lanu, ktory sie do niego dolacza...

Offline

 

#17  2017-04-18 22:26:38

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/urandom
Zarejestrowany: 2008-01-07

Re: Iptables - ruch z routera przez VPN

Póki kaczka dupy nie umoczy, pływać się nie nauczy.

Spróbuj zrobić prawidłowo routing do VPS, jak się nie uda, to będziemy dalej kombinować, ale powinno się udać.


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#18  2017-04-19 06:56:49

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Iptables - ruch z routera przez VPN

[quote=Jacekalex]Problem był tu:

Kod:

default via 192.168.0.1 dev eth1

Bo po prostu, żeby programy leciały przez VPN, trasa default musi kierować do VPN, czyli:

Kod:

default via 192.168.3.1 dev tun0

[/quote]
No nie do końca. Można zostawić default tak jak jest i dorobić te dwa poniższe wpisy w tablicy routingu:

Kod:

0.0.0.0/1 via 10.80.0.1 dev tun0
128.0.0.0/1 via 10.80.0.1 dev tun0
...
default via 192.168.1.1 dev bond0 metric 10

Nie trzeba tego ręcznie wpisywać, wystarczy w konfiguracji serwera dodać:

Kod:

push "redirect-gateway def1 bypass-dhcp"

I to automatycznie doda te dwa powyższe wpisy w tablicach routingu każdego z klientów, który się do serwera VPN podłączy. [url=https://morfitronik.pl/jak-skonfigurowac-serwer-vpn-na-debianie-openvpn/]Jak coś to tutaj jest więcej info[/url] ale tam w tablicy routingu już te wpisy siedzą, więc tutaj nie ma problemu.

Jeśli chcesz na TUP/TAP wyciągnąć większe prędkości, niż 10Mbit, to potrzebujesz tej łatki na kernele (na obu końcach tunelu):[/quote]
Jak to? U mnie bez żadnych łat (debian założył?) na moim VPS wyciągam po VPN około 40 mbit/s.

Ostatnio edytowany przez morfik (2017-04-19 06:57:56)

Offline

 

#19  2017-04-22 09:24:09

  immcio - Użytkownik

immcio
Użytkownik
Zarejestrowany: 2017-04-12

Re: Iptables - ruch z routera przez VPN

Dobra wiec po kilku dniach walki wrocilem do opcji tun, bo tap nie chodzil jak trzeba. Komputery sie nie widzialy i nie mialem cierpliwosci zeby sie w tym babrac.
W tej chwili mam:
Struktura i adresacja tak jak na pierwszym obrazku powyzej.
Server widzi klienta i odwrotnie.
Ruch z sieci lan idzie przez LTE - tak jak chcialem
Gdy puszczam na komputerze z lan traceroute 192.168.3.1 - czyli na adres servera openvpn, to ruch odbywa sie przez tun0

Stanalem na routingu do rejestratora IP. Rejestrator jest na 192.168.1.189:80. Pod spodem sa wpisy w iptables:

ROUTER (klient vpn):

Kod:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             192.168.1.189        tcp dpt:5800
ACCEPT     tcp  --  anywhere             192.168.3.2          tcp dpt:http
ACCEPT     tcp  --  anywhere             192.168.3.2          tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             192.168.3.2          tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             192.168.1.189        tcp dpt:http-alt
ACCEPT     tcp  --  anywhere             192.168.1.189        tcp dpt:http
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.1.0/24       anywhere             ctstate NEW
ACCEPT     all  --  192.168.3.0/24       anywhere             ctstate NEW
ACCEPT     all  --  192.168.3.0/24       192.168.1.0/24       ctstate NEW
ACCEPT     all  --  192.168.1.0/24       anywhere            
ACCEPT     all  --  anywhere             192.168.1.0/24      
ACCEPT     all  --  anywhere             192.168.3.0/24      
ACCEPT     all  --  anywhere             192.168.3.0/24      
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  192.168.0.0/16       anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply

Server VPS (Server VPN):

Kod:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn ctstate NEW /* vpn */

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             192.168.3.2          tcp dpt:5800
ACCEPT     tcp  --  anywhere             192.168.3.2          tcp dpt:http
ACCEPT     tcp  --  anywhere             192.168.3.2          tcp dpt:http-alt
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  192.168.1.0/24       anywhere            
ACCEPT     all  --  anywhere             192.168.1.0/24      
ACCEPT     all  --  192.168.3.0/24       anywhere            
ACCEPT     all  --  anywhere             192.168.3.0/24      

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     icmp --  anywhere             anywhere             icmp echo-reply
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request

Przy probie polaczenia przez np www to przegladarka mieli, nastepuje polaczenie, jednak zrywa z powodu timeout timeout. Wnioskuje ze jednak cos nie tak jest z routingiem od routera do rejestratora...
Ponizej jeszcze iptables jakich uzylem:

Server

Kod:

iptables -I FORWARD -i eth0 -p tcp -d 192.168.3.2 --dport 8080 -j ACCEPT

iptables -t nat -I PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.3.2:8080

Router

Kod:

iptables -I FORWARD -i tun0 -p tcp -d 192.168.1.189 --dport 8080 -j ACCEPT

iptables -t nat -I PREROUTING -i tun0 -p tcp --dport 8080 -j DNAT --to-destination 192.168.1.189:80

Jeszcze dodam ze przy probie polaczenie przez http://192.168.3.2 z komputera w lan to pieknie sie laczy z serwerem www na routerze, ale jak dodam port 8080 to nie moze nawiazac polaczenia...

Ostatnio edytowany przez immcio (2017-04-22 09:30:27)

Offline

 

#20  2017-04-23 16:15:22

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Iptables - ruch z routera przez VPN

Maskaradę masz w nat dodaną?

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Nas ludzie lubią po prostu, a nie klikając w przyciski ;-)

[ Generated in 0.021 seconds, 11 queries executed ]

Informacje debugowania

Time (s) Query
0.00014 SET CHARSET latin2
0.00008 SET NAMES latin2
0.00258 SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.191.132.36' WHERE u.id=1
0.00193 REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.191.132.36', 1715850050)
0.00062 SELECT * FROM punbb_online WHERE logged<1715849750
0.00142 SELECT topic_id FROM punbb_posts WHERE id=310260
0.00010 SELECT id FROM punbb_posts WHERE topic_id=29497 ORDER BY posted
0.00164 SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=29497 AND t.moved_to IS NULL
0.00015 SELECT search_for, replace_with FROM punbb_censoring
0.00462 SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=29497 ORDER BY p.id LIMIT 0,25
0.00232 UPDATE punbb_topics SET num_views=num_views+1 WHERE id=29497
Total query time: 0.0156 s