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... :)
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/random
- 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 1Uż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,
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 immcio, 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/random
- 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- pomijając fakt że chcąc korzystać z zasobów zza VPNa na Androidach trzeba rootować urzadzenie.
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/random
- 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
Jacekalex: 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.
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/random
- 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
@Jacekalex: 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/random
- 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 eth1Czyli 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
@Jacekalex: 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/random
- 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/random
- 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
Re: Iptables - ruch z routera przez VPN
Jacekalex napisał(-a):
Problem był tu:
Kod:
default via 192.168.0.1 dev eth1Bo po prostu, żeby programy leciały przez VPN, trasa default musi kierować do VPN, czyli:
Kod:
default via 192.168.3.1 dev tun0
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. Jak coś to tutaj jest więcej info 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):
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