Sziasztok a következő problémával küzdök már több hete és valahogy nem tudok rájönni hol rontom el, van egy router aminek 192.168.0.0/24 a hálózata, e mögött van egy másik router aminek a hálózata 192.168.1.0/24, a 1194 tcp/udp port forward-olva van. A VPN kapcsolat fel is áll gond nélkül csak sehogy nem tudom pingelni, sem a szerverről a kliens, vagy fordítva, a következő konfig-ja van:
SERVER
port 1194
proto udp
dev tun1
server 10.0.0.0 255.255.255.0
cipher AES-128-CBC
user nobody
group nogroup
verb 2
mute 20
max-clients 100
management 127.0.0.1 8876
keepalive 10 120
client-to-client
persist-key
persist-tun
ccd-exclusive
CLIENT
client
proto udp
dev tun
ca ca.crt
dh dh2048.pem
remote server.dyndns.org 1194
cipher AES-128-CBC
user nobody
group nogroup
verb 2
mute 20
keepalive 10 120
persist-key
persist-tun
float
resolv-retry infinite
nobind
##################
root@server:~# iptables -t filter -L -v -n
Chain INPUT (policy ACCEPT 4839 packets, 3874K bytes)
pkts bytes target prot opt in out source destination
81 5061 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20000
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:10000
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:443
37 3046 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:993
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:143
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:995
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:110
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:20
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:25
61 7442 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3306
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5432
48 3056 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:3128
26 2424 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:137
19 4200 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:138
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:139
0 0 ACCEPT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:445
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
0 0 ACCEPT all -- tun1 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- br0 tun1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun1 br0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 5012 packets, 3551K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tun1 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
####################
root@server:~# iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 490 packets, 199K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 22 packets, 3314 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 595 packets, 41359 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 595 packets, 41359 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * br0 10.0.0.0/24 0.0.0.0/0
###################
root@server:~# iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 11032 packets, 9207K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 10548 packets, 9003K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 10452 packets, 8629K bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 10549 packets, 8639K bytes)
pkts bytes target prot opt in out source destination
- 6594 megtekintés
Hozzászólások
A 1194 porton miért nem látszik a forgalom?
'ip ro' és 'ip ad' kimenet még jó lenne.
- A hozzászóláshoz be kell jelentkezni
Van rajta forgalom, de csak bejövő.
root@server:~# iptables -t filter -L -v -n
Chain INPUT (policy ACCEPT 4434 packets, 5004K bytes)
pkts bytes target prot opt in out source destination
407 72977 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- br0 tun0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- tun0 br0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 6550 packets, 5815K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
- A hozzászóláshoz be kell jelentkezni
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
Output esten source lesz a 1194 port.
- A hozzászóláshoz be kell jelentkezni
Ott a pont! :)
A fentit próbáld meg rubenzsolt.
- A hozzászóláshoz be kell jelentkezni
A policy ACCEPT, ez a fenti konfigban nem befolyásol semmit. Kár volt bonyolítani a dolgot az egész no-op filter/mangle táblákkal (pláne, hogy még a counterek se a hiba reprodukálása utáni állapotot mutatják).
- A hozzászóláshoz be kell jelentkezni
A szerver konfigjához hozzáadtam még a két beállítást.
push "dhcp-option DNS 192.168.1.1"
push "redirect-gateway def1"
root@server:~# iptables -t filter -L -v -n
Chain INPUT (policy ACCEPT 24885 packets, 27M bytes)
pkts bytes target prot opt in out source destination
8925 2164K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194
0 0 ACCEPT all -- tun0 * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
9802 7374K ACCEPT all -- br0 tun0 0.0.0.0/0 0.0.0.0/0
8171 1307K ACCEPT all -- tun0 br0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 28570 packets, 36M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tun0 0.0.0.0/0 0.0.0.0/0
10471 8207K ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp spt:1194
*******
root@server:~# iptables -t nat -L -v -n
Chain PREROUTING (policy ACCEPT 2202 packets, 688K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 135 packets, 7992 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 674 packets, 42735 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 674 packets, 42735 bytes)
pkts bytes target prot opt in out source destination
595 33863 MASQUERADE all -- * br0 10.0.0.0/24 0.0.0.0/0
*******
root@server:~# iptables -t mangle -L -v -n
Chain PREROUTING (policy ACCEPT 61627 packets, 41M bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 41945 packets, 31M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 18173 packets, 8725K bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 41263 packets, 46M bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 59501 packets, 54M bytes)
pkts bytes target prot opt in out source destination
- A hozzászóláshoz be kell jelentkezni
Szia,
Rajzolj egy morickaabrat, rajzold le vagy gondolt vegig, hol - mi tortenik. Es mindjart meglesz a valasz.
Azert irom mindezt, mert a leirtak alajan vagy lusta vagy gondolkozni, vagy csak egy receptet kovettel.
Ha, van morickarajz akkor szivesen segitek.
Udv.,
:)
- A hozzászóláshoz be kell jelentkezni
Route tábla?
- A hozzászóláshoz be kell jelentkezni
root@server:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 br0
10.0.0.0 10.0.0.2 255.255.255.0 UG 0 0 0 tun0
10.0.0.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.1.0 * 255.255.255.0 U 0 0 0 br0
- A hozzászóláshoz be kell jelentkezni
Kliens oldalon be van állítva,hogy route-olja be azt a hálót a tunnel-be? A szerver oldalon nem látok egyetlen push route parancsot sem a vpn konfigban. Ezzel tudnád megmondani a kliensnek,hogy merre küldje a csomagokat.
Másik probléma lehet, ha a kliens saját hálózata is 192.168.0.0/24 vagy 192.168.1.0/24, akkor még meggyűlhet a bajod a route-olással is.
- A hozzászóláshoz be kell jelentkezni
Miert?!!!! Egy nagy fekete pont!!!! Es meg -150 pont a Kallaicsnak!
:)
- A hozzászóláshoz be kell jelentkezni
Először is pontatlan a kérdésed.
Másodsorban elolvastam még egyszer a pontos problémát. Első olvasásra csak átfutottam gyorsban a témát. A szervert tudnia kellene pingelni.
Harmadszor ha nem teszik, hogy próbálok segíteni másnak, akkor tartsd meg a véleményed magadnak.
Visszatérve a problémára:
Jó lenne tudni,hogy a routereken milyen rendszer fut.
Én elkezdeném megnézni a routing táblát. route -n
Utána megnézném a routeren az icmp szabályokat (ha csak a ping nem megy). Másik port megy?
Ha minden oké és mégsem megy, akkor valamelyik tcpdump, tshark vagy amelyik szimpatikus hálózati paranccsal megnézném a forgalmat.
- A hozzászóláshoz be kell jelentkezni
Nezd meg a smileyt a mondandom vegen. Lehet, ha Griffendelt irok, mint ahogy eloszor akartam, jobb lett volna. :P
Akkor most vissza az elejere. Meglatasom szerint, az sokkal nagyobb segitseg, ha valaki megtanulja, hogy valami hogyan mukodik, mint egybol megmondani, merre kell keresni a problema okat vagy mi az. Persze ez nem mindig jarhato ut, erosen fugg a problematol. Az pedig csak hab a tortan, amit a masodi reszben emlitettel 192.168.0.0 es 192.168.1.0 kliens nettel kapcsolatban.
Visszaterve az eredeti problemara: meg mindig hianyolom a moriczkaabrat! De akkor boncolgassuk is csak egy kicsit miert kell ez az abra.
Egyszeruen mert mident elmond. Ki, hova, hogyan, minkeresztul es mit tehet.
Pl., az sem mindegy, hogy:
- S2S vagy P2P kliens(ek)rol beszelgetunk. (S2S is P2P csak egy kicsit mas cellal hozzuk letre.)
- ha P2P akkor lathatjak-e egymast a kliensek
- hol van vagy talan ugy egyszerubb, hol fut az openvpn szerver?
- milyen megoldast hasznal a VPN kapcsolat letrehozasara (persze ez a mellekelt configbol - ha van -, azert altalaban kitalalhato; de ki tudja.)
Nem az a problemam, hogy segiteni akarsz, hanem ahogy teszed. Velemenyem szerint (no offence), a fenti kerdesre, csak ugy lehet rovid, pontos, valaszt = segitseget adni, ha teljesen kepben vagy. Egyeb esetben, csak felsorolod, hogy lehet ez is a problema, lehet az is, stb... ami, lassuk be, a rendelkezesre allo informaciok alapjan csak talalgatas. ;)
- A hozzászóláshoz be kell jelentkezni
Ha már ilyen jól megismerkedtünk :)
Valóban jó lenne, ha az illető tényleg lerajzolja, amit csinál és utánaolvas egy kicsit.
Én vizuális típus vagyok szóval nehezen képzelem el dolgokat, szóval inkább rajzolok és az alapján megyek :)
Ha jól sejtem valami ilyesmit akar, de tényleg jó lenne egy rajz:)
Kliens -> Internet -----> router1 (NAT) /192.168.0.0/24 /-----> router2 (OpenVPN szerver /10.0.0.0/24 / ) /192.168.1.0/24/
Ha jó a rajz, akkor lehet tovább vinni a dolgot. Nem egyértelmű számomra, hogy melyik routeren fut az OpenVPN szerver.
- A hozzászóláshoz be kell jelentkezni
Pontosan. :)
- A hozzászóláshoz be kell jelentkezni
Sziasztok, a következőképpen néz ki a hálozat.
public IP ---> 1ROUTER (192.168.0.0/24) 1194/UDP open --> 2ROUTER (192.168.1.0/24) 1194/UDP open --> openVPN SERVER 192.168.1.100
A OPENVPN nem egy routeren fut hanem egy szerveren a 192.168.1.0/ hálon belül aminek 192.168.1.100 az IP címe.
- A hozzászóláshoz be kell jelentkezni
Na kezdunk kozelebb jutni a celhoz.
A 2ROUTERen van NATolas?
- A hozzászóláshoz be kell jelentkezni
azt hiszem részben megoldott a probléma, megváltoztattam a 192.168.1.0/24-es hálózatot 192.168.200.0/24-re, Windows távoli kliensről tudom pingelni a szerver ip-t, illetve a belső hálózat gépeit, de a belső hálóról a tun-t nem, a tűzfal beállítások jók.
valakinek valamilyen ötlet
- A hozzászóláshoz be kell jelentkezni
tcpdump mit mond a szerveren a tun interface-re ping közben? Ha kimegy a csomag,akkor a kliens dobja el a csomagot vagy routing probléma kliens oldalon.
Ha nincs a routing táblában a 192.168.0.0/24 és 192.168.1.0/24 routolva a tunnel felé,akkor nem tud visszamenni a csomag.
tedd be a konfighoz:
push route 192.168.0.0 255.255.255.0
push route 192.168.1.0 255.255.255.0
Egy bökkenő lehet, ha a kliens alapból szintén valamelyik hálózaton van. 192.168.1.0/24 vagy 192.168.0.0/24
Utána vissza fog menni a csomag.
A tűzfalon zárd le a láncokat a szabályok után, mert így nincs értelme a tűzfalnak.
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
- A hozzászóláshoz be kell jelentkezni
a következőképpen változott a dolog:
publicIP -> router 192.168.0.0/24 -> router 192.168.200.0/24
A VPN a 192.168.100.0/24 hálózaton kapcsolódik.
kívülről kapcsolódom egy 172.16.2.0-as hálózatról a 192.168.100.6
A VPN kapcsolat létrejön gond nélkül, és kívülről ping OK elérem a belső gépeket, kifelé ping kliens felé nem megy, pedig a tűzfal ok elméletileg.
VPN SERVER config -
push "redirect-gateway def1"
push "route 192.168.0.0 255.255.255.0"
push "route 192.168.200.0 255.255.255.0"
push "dhcp-option DNS 192.168.200.1"
push "dhcp-option WINS 192.168.100.2"
push "dhcp-option DOMAIN WORKGROUP"
root@server:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.200.1 0.0.0.0 UG 0 0 0 br0
192.168.100.0 192.168.100.2 255.255.255.0 UG 0 0 0 tun0
192.168.100.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.200.0 * 255.255.255.0 U 0 0 0 br0
- A hozzászóláshoz be kell jelentkezni
A kliens oldali route táblát küldd át légyszi, mikor aktív a tunnel.
- A hozzászóláshoz be kell jelentkezni
===========================================================================
Kapcsolatlista
23...00 ff 07 47 b0 ad ......TAP-Win32 Adapter V9
14...00 26 82 66 0c 69 ......Broadcom 43224AG 802.11a/b/g/draft-n Wi-Fi adapter
12...00 24 7e 5a d6 67 ......Bluetooth-eszköz (személyes hálózat)
11...c8 0a a9 1d 3c cd ......Realtek RTL8168D/8111D Family PCI-E Gigabit Ethern
et NIC (NDIS 6.20)
20...08 00 27 00 88 c9 ......VirtualBox Host-Only Ethernet Adapter
1...........................Software Loopback Interface 1
25...00 00 00 00 00 00 00 e0 Microsoft ISATAP adapter
21...00 00 00 00 00 00 00 e0 Microsoft ISATAP adapter #2
15...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
22...00 00 00 00 00 00 00 e0 Microsoft ISATAP adapter #3
===========================================================================
IPv4 útvonaltábla
===========================================================================
Aktív útvonalak:
Hálózati cél Hálózati maszk Átjáró Kapcsolat Metrika
0.0.0.0 0.0.0.0 172.16.1.1 172.16.2.54 25
0.0.0.0 128.0.0.0 192.168.100.5 192.168.100.6 30
127.0.0.0 255.0.0.0 Kapcsolaton belüli 127.0.0.1 306
127.0.0.1 255.255.255.255 Kapcsolaton belüli 127.0.0.1 306
127.255.255.255 255.255.255.255 Kapcsolaton belüli 127.0.0.1 306
128.0.0.0 128.0.0.0 192.168.100.5 192.168.100.6 30
172.16.0.0 255.255.252.0 Kapcsolaton belüli 172.16.2.54 281
172.16.2.54 255.255.255.255 Kapcsolaton belüli 172.16.2.54 281
172.16.2.243 255.255.255.255 Kapcsolaton belüli 192.168.56.1 21
172.16.3.255 255.255.255.255 Kapcsolaton belüli 172.16.2.54 281
192.168.0.0 255.255.255.0 192.168.100.5 192.168.100.6 30
192.168.56.0 255.255.255.0 Kapcsolaton belüli 192.168.56.1 276
192.168.56.1 255.255.255.255 Kapcsolaton belüli 192.168.56.1 276
192.168.56.255 255.255.255.255 Kapcsolaton belüli 192.168.56.1 276
192.168.100.0 255.255.255.0 192.168.100.5 192.168.100.6 30
192.168.100.4 255.255.255.252 Kapcsolaton belüli 192.168.100.6 286
192.168.100.6 255.255.255.255 Kapcsolaton belüli 192.168.100.6 286
192.168.100.7 255.255.255.255 Kapcsolaton belüli 192.168.100.6 286
192.168.200.0 255.255.255.0 192.168.100.5 192.168.100.6 30
213.181.217.199 255.255.255.255 172.16.1.1 172.16.2.54 25
224.0.0.0 240.0.0.0 Kapcsolaton belüli 127.0.0.1 306
224.0.0.0 240.0.0.0 Kapcsolaton belüli 192.168.56.1 276
224.0.0.0 240.0.0.0 Kapcsolaton belüli 192.168.100.6 286
224.0.0.0 240.0.0.0 Kapcsolaton belüli 172.16.2.54 281
255.255.255.255 255.255.255.255 Kapcsolaton belüli 127.0.0.1 306
255.255.255.255 255.255.255.255 Kapcsolaton belüli 192.168.56.1 276
255.255.255.255 255.255.255.255 Kapcsolaton belüli 192.168.100.6 286
255.255.255.255 255.255.255.255 Kapcsolaton belüli 172.16.2.54 281
===========================================================================
Állandó útvonalak:
Nincs
IPv6 útvonaltábla
===========================================================================
Aktív útvonalak:
Kapcs. Metrika Hálózati cél Átjáró
1 306 ::1/128 Kapcsolaton belüli
20 276 fe80::/64 Kapcsolaton belüli
23 286 fe80::/64 Kapcsolaton belüli
14 281 fe80::/64 Kapcsolaton belüli
14 281 fe80::11fd:9367:d2d2:6aba/128
Kapcsolaton belüli
20 276 fe80::bce2:d26f:a8c2:cb2f/128
Kapcsolaton belüli
23 286 fe80::ecaa:9449:ee8:174f/128
Kapcsolaton belüli
1 306 ff00::/8 Kapcsolaton belüli
20 276 ff00::/8 Kapcsolaton belüli
23 286 ff00::/8 Kapcsolaton belüli
14 281 ff00::/8 Kapcsolaton belüli
===========================================================================
Állandó útvonalak:
Nincs
- A hozzászóláshoz be kell jelentkezni
Ezek benne vannak,ami jónak tűnik.
192.168.0.0 255.255.255.0 192.168.100.5 192.168.100.6 30
192.168.200.0 255.255.255.0 192.168.100.5 192.168.100.6 30
Kliens gépen milyen OS van most?
Kliens gépen milyen tűzfal szabályok vannak, ha vannak?
Ping-re most sem válaszol?
Elvileg most így néz ki a dolog, ha jól sejtem:
Kliens (172.16.0.0/22 / VPN: 192.168.100.6)
----> Public IP
----> Router1 (NAT) / 192.168.0.0/24 )
----> Router2 (192.168.200.0/24) / VPN (192.168.100.0/24)
Melyik hálózatból pingeted a VPN klienst?
Ha a 192.168.0.0/24-ből, akkor a router1- fel kell venned egy static routing szabályt, hogy a 192.168.100.0/24-et tolja a másik router felé, mert az abban a hálózatban a lévő gépek a router1-en mennek ki alapból.
- A hozzászóláshoz be kell jelentkezni
En mar az elejen elvesztettem a fonalat, melyik szegmenst masqolod, melyiket routelod openvpnbol (neki is van belso routeja), es melyiket siman.
Lehet csak en nem ertem,hogy szamodra itt mit jelent a "kifele" a kliensek azok vpn kliensek, vagy mas kliensek? Ha a samba server 192.168.100.2, akkor miert adod hozza 192.168.200.0/24et routenak? 192.168.200.0/24-es halon megadtad statikus routenak a vpn atjarot, hogy ott talalhato a 192.168.100.0/24?
- A hozzászóláshoz be kell jelentkezni
Az első router egy TP-Link saját firmware, ezen forwardolva van a 1194/UDP tovább a másik routerre amin egy openwrt fut, itt ugyancsak a 1194/UDP nyitva.
- A hozzászóláshoz be kell jelentkezni
Melyik az elso router, es melyik a masodik? Rajzold le, _legyszi_. Olyan "rajz" eleg, mint kallaics fenti kommentjeben.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.
- A hozzászóláshoz be kell jelentkezni
A klienssel egy mobil kapcsolaton keresztül próbáltam illetve egy 174.16.1.0 as hálózaton. Állitottam be push route parancsot is de semmi enm változott.
- A hozzászóláshoz be kell jelentkezni
Szamomra erdekes, hogy firewallban policy accept, es az osszes ruled is, valami kimaradt, en neztem el?
Masik, hogy "tcpdump -ni tun0" parancs segitsegevel mindket oldal debugolhato, mikozben fut ping (lehetoleg mindket iranybol kulon).
Ugye mindket iranyban levo ping az valami 10.0.0.x pingelsz?
- A hozzászóláshoz be kell jelentkezni