Dotaz: Přístup na služby OPENVPN klienta - asi routing

[x.para]

Ahoj,

na asus wl500 s IP 192.168.2.1 mi běží OPENVPN klient. Současně na něm běží www a ssh server, vše na jedné IP zařízení br0. OpenVPN server s IP 192.168.1.2 si na klienta pingne, obracně také, ale na služby co běží na klientovi se už nedostanu, vše vyprší na timeout.

Zajímavé je a nevím jestli je to spravně, je to, že se na toho klienta ale dostanu přes IP OPENVPN tunelu 192.168.3.1, což je IP zařízení tun0 na straně serveru.

Další divná več je ta, že rotovací tabulka zmíněného klienta neobsahuje IP lokalního tun0 zařízení, ale tun0 serveru. tun0 klienta má IP 192.168.3.2.

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.9.1     0.0.0.0         255.255.255.255 UH    0      0        0 wan0
192.168.1.0     192.168.3.1     255.255.255.224 UG    0      0        0 tun0
192.168.3.0     0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
192.168.9.0     0.0.0.0         255.255.255.0   U     0      0        0 wan0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.9.1     0.0.0.0         UG    0      0        0 wan0

dokáže to někdo vysvětlit?

---

---

Odpovědi

[Jendа]

tcpdump, co jiného na to poradit.

Btw. příště prosím ip r, výpisy z route neumím číst.

[x.para]

ok, takze na tun0 na klientovi dorazi http pozadavek na port 8000, coz je v poradku, ale klient nic nevrati

listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
19:34:24.165177 IP 192.168.1.2.52371 > asus.8000: Flags [S], seq 656531295, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796425379 ecr 0,sackOK,eol], length 0
19:34:24.165893 IP 192.168.1.2.52372 > asus.8000: Flags [S], seq 3725258729, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796425715 ecr 0,sackOK,eol], length 0
19:34:24.166582 IP 192.168.1.2.52371 > asus.8000: Flags [S], seq 656531295, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796426379 ecr 0,sackOK,eol], length 0
19:34:24.167264 IP 192.168.1.2.52372 > asus.8000: Flags [S], seq 3725258729, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796426715 ecr 0,sackOK,eol], length 0
19:34:24.304411 IP 192.168.1.2.52371 > asus.8000: Flags [S], seq 656531295, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796436381 ecr 0,sackOK,eol], length 0
19:34:24.645083 IP 192.168.1.2.52372 > asus.8000: Flags [S], seq 3725258729, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796436717 ecr 0,sackOK,eol], length 0
19:34:32.316658 IP 192.168.1.2.52371 > asus.8000: Flags [S], seq 656531295, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796444381 ecr 0,sackOK,eol], length 0
19:34:32.654272 IP 192.168.1.2.52372 > asus.8000: Flags [S], seq 3725258729, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796444717 ecr 0,sackOK,eol], length 0
19:34:48.363389 IP 192.168.1.2.52371 > asus.8000: Flags [S], seq 656531295, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796460381 ecr 0,sackOK,eol], length 0
19:34:48.837098 IP 192.168.1.2.52372 > asus.8000: Flags [S], seq 3725258729, win 65535, options [mss 1368,nop,wscale 5,nop,nop,TS val 796460717 ecr 0,sackOK,eol], length 0

ip r klienta:

ip r
192.168.9.1 dev wan0  scope link 
192.168.1.0/27 via 192.168.3.1 dev tun0 
192.168.3.0/24 dev tun0  proto kernel  scope link  src 192.168.3.2 
192.168.2.0/24 dev br0  proto kernel  scope link  src 192.168.2.1 
192.168.9.0/24 dev wan0  proto kernel  scope link  src 192.168.9.100 
127.0.0.0/8 dev lo  scope link 
default via 192.168.9.1 dev wan0 

[Jendа]

Hm, kdyby ten webserver neposlouchal, tak to snad hodí RST. Není tam nějak „chytře“ nastavený firewall? (iptables-save dumpne, co tam všechno je)

[x.para]

Ted jsem je flushnul a nic se nezmenilo, nicimene :

iptables-save 
# Generated by iptables-save v1.4.3.2 on Thu Jan  1 01:01:23 1970
*nat
:PREROUTING ACCEPT [38:12910]
:POSTROUTING ACCEPT [36:1795]
:OUTPUT ACCEPT [36:1795]
:UPNP - [0:0]
:VSERVER - [0:0]
-A PREROUTING -d 192.168.9.100/32 -j VSERVER 
-A POSTROUTING ! -s 192.168.9.100/32 -o wan0 -j MASQUERADE 
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.0/24 -o br0 -j MASQUERADE 
-A VSERVER -p tcp -m tcp --dport 10052 -j DNAT --to-destination 192.168.2.1:8080 
COMMIT
# Completed on Thu Jan  1 01:01:23 1970
# Generated by iptables-save v1.4.3.2 on Thu Jan  1 01:01:23 1970
*mangle
:PREROUTING ACCEPT [915:139557]
:INPUT ACCEPT [794:108081]
:FORWARD ACCEPT [5:425]
:OUTPUT ACCEPT [701:84289]
:POSTROUTING ACCEPT [706:84714]
COMMIT
# Completed on Thu Jan  1 01:01:23 1970
# Generated by iptables-save v1.4.3.2 on Thu Jan  1 01:01:23 1970
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [5:425]
:OUTPUT ACCEPT [605:74734]
:BRUTE - [0:0]
:MACS - [0:0]
:SECURITY - [0:0]
:UPNP - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
-A INPUT -m conntrack --ctstate INVALID -j DROP 
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -i br0 -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 10022 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 8080 -j ACCEPT 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 10050 -j ACCEPT 
-A INPUT -p icmp -m icmp ! --icmp-type 8 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A INPUT -p udp -m udp --dport 33434:33534 -j ACCEPT 
-A INPUT -j DROP 
-A FORWARD -i br0 -o br0 -j ACCEPT 
-A FORWARD -m conntrack --ctstate INVALID -j DROP 
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD ! -i br0 -o wan0 -j DROP 
-A FORWARD -m conntrack --ctstate DNAT -j ACCEPT 
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN 
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN 
-A SECURITY -p udp -m limit --limit 5/sec -j RETURN 
-A SECURITY -p icmp -m limit --limit 5/sec -j RETURN 
-A SECURITY -j DROP 
-A logaccept -m conntrack --ctstate NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode 
-A logaccept -j ACCEPT 
-A logdrop -m conntrack --ctstate NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode 
-A logdrop -j DROP 
COMMIT
# Completed on Thu Jan  1 01:01:23 1970

[Jendа]

-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.0/24 -o br0 -j MASQUERADE

Maškaráduje ta spojení, co tě zajímají, ne?

-A INPUT -m conntrack --ctstate INVALID -j DROP 
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -i br0 -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 10022 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 8080 -j ACCEPT 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 10050 -j ACCEPT 
-A INPUT -p icmp -m icmp ! --icmp-type 8 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A INPUT -p udp -m udp --dport 33434:33534 -j ACCEPT 
-A INPUT -j DROP

Kde se tady povoluje port 8000?

[x.para]

jo praveda, ale to pravidlo tam bylo, davam to tam rucne a jak jsem to flushnul tak jsem o to prisel. s timto pravidlem zadna zmena.

Maškaráde tady moc nerozumim, vubec nechapu z čeho se tam bere, čili jestli tomu dobře rozumim, ta by se měla uplně vyhodit?

jinak teď již:

:logdrop - [0:0]
-A INPUT -p tcp -m tcp --dport 8000 -j ACCEPT 
-A INPUT -p udp -m udp --dport 8000 -j ACCEPT 
-A INPUT -m conntrack --ctstate INVALID -j DROP 
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -i br0 -m conntrack --ctstate NEW -j ACCEPT 
-A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 10022 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 8080 -j ACCEPT 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 80 -j ACCEPT 
-A INPUT -p tcp -m tcp --dport 10050 -j ACCEPT 
-A INPUT -p icmp -m icmp ! --icmp-type 8 -j ACCEPT 
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT 
-A INPUT -p udp -m udp --dport 33434:33534 -j ACCEPT 
-A INPUT -j DROP 

[Jendа]

Maškaráde tady moc nerozumim, vubec nechapu z čeho se tam bere, čili jestli tomu dobře rozumim, ta by se měla uplně vyhodit?

No mně tam přijde jako blbost.

Zkusil bych místo dropů dát rejecty, jestli se místo ticha začnou vracet resety.

Obecně dropy nikde nedávám, protože mě vždycky strašně štve, když někam pošlu paket, a místo vyfuckování je ticho, takže nevím, jestli se to ztratilo, nebo se se mnou nechtějí bavit.

[x.para]

ok tak jsem maskaradu vyhodil a zadna zmena.

nicmene koukam jestli to fakt nebude jinde. Pokud delam dobre tcpdump, tak vidim ze na zarizeni tun0 je prichozi provoz na port 8000 ale na br0 uz ne. jaktoze ale funguje na stejnou IP ping?

tcpdump -i tun0 tcp port 8000


tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
21:53:17.688688 IP 192.168.1.2.35795 > asus.8000: Flags [S], seq 963909617, win 29200, options [mss 1368,sackOK,TS val 32620938 ecr 0,nop,wscale 7], length 0
21:53:17.689799 IP 192.168.1.2.35795 > asus.8000: Flags [S], seq 963909617, win 29200, options [mss 1368,sackOK,TS val 32621038 ecr 0,nop,wscale 7], length 0
21:53:17.690470 IP 192.168.1.2.35795 > asus.8000: Flags [S], seq 963909617, win 29200, options [mss 1368,sackOK,TS val 32621238 ecr 0,nop,wscale 7], length 0
21:53:19.618763 IP 192.168.1.2.35795 > asus.8000: Flags [S], seq 963909617, win 29200, options [mss 1368,sackOK,TS val 32621639 ecr 0,nop,wscale 7], length 0
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

tcpdump -i br0 tcp port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes


^C
ping 192.168.2.1 
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=36.9 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=37.8 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=37.2 ms

[NN]

Dej sem netstat -an. Jses si jisty ze na 8000 skutecne neco posloucha?

[x.para]

tady je:

netstat -an
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:10050           0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:10022           0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:8080            0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      
tcp        0      0 192.168.2.1:10022       192.168.2.75:60002      ESTABLISHED 
tcp        0      0 192.168.9.100:53960     89.103.214.138:10001    ESTABLISHED 
tcp        0      0 192.168.9.100:53972     89.103.214.138:10001    ESTABLISHED 
tcp        0      0 192.168.9.100:53978     89.103.214.138:10001    ESTABLISHED 
tcp        0      0 192.168.2.1:10022       192.168.2.75:60022      ESTABLISHED 
tcp        0      0 :::10050                :::*                    LISTEN      
tcp        0      0 :::53                   :::*                    LISTEN      
tcp        0      0 :::22                   :::*                    LISTEN      
udp        0      0 0.0.0.0:9999            0.0.0.0:*                           
udp        0      0 127.0.0.1:38032         0.0.0.0:*                           
udp        0      0 0.0.0.0:48680           0.0.0.0:*                           
udp        0      0 0.0.0.0:53              0.0.0.0:*                           
udp        0      0 0.0.0.0:67              0.0.0.0:*                           
udp        0      0 0.0.0.0:38000           0.0.0.0:*                           
udp        0      0 :::53                   :::*                                
Active UNIX domain sockets (servers and established)
Proto RefCnt Flags       Type       State         I-Node Path
unix  9      [ ]         DGRAM                    335    /dev/log
unix  2      [ ACC ]     STREAM     LISTENING     5095   /opt/tmp/php-fastcgi.socket-0
unix  2      [ ]         DGRAM                    6677   
unix  2      [ ]         DGRAM                    775    
unix  2      [ ]         DGRAM                    706    
unix  2      [ ]         DGRAM                    646    
unix  2      [ ]         DGRAM                    641    
unix  2      [ ]         DGRAM                    395    
unix  2      [ ]         DGRAM                    374    

[x.para]

a jeste:

telnet 192.168.2.1 8000


HTTP/1.0 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 20 Jan 2016 21:29:49 GMT
Server: lighttpd/1.4.35
Connection closed by foreign host

[NN]

HTTP/1.0 400 Bad Request

Je odpoved serveru => normalne to chodi. Pust ten tcpdump na br0 s parametrem -n -p.

[x.para]

dik, na br0 ale nikdy nic nedoleze, co vidim je pouze prichozi provoz na tun0

viz:

tcpdump -i tun0 -p tcp port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
23:29:31.942748 IP 192.168.1.2.35846 > asus.8000: Flags [S], seq 471705616, win 29200, options [mss 1368,sackOK,TS val 33197822 ecr 0,nop,wscale 7], length 0
23:29:31.943498 IP 192.168.1.2.35846 > asus.8000: Flags [S], seq 471705616, win 29200, options [mss 1368,sackOK,TS val 33197922 ecr 0,nop,wscale 7], length 0
23:29:31.944195 IP 192.168.1.2.35846 > asus.8000: Flags [S], seq 471705616, win 29200, options [mss 1368,sackOK,TS val 33198122 ecr 0,nop,wscale 7], length 0
23:29:31.944840 IP 192.168.1.2.35846 > asus.8000: Flags [S], seq 471705616, win 29200, options [mss 1368,sackOK,TS val 33198523 ecr 0,nop,wscale 7], length 0
23:29:36.428476 IP 192.168.1.2.35846 > asus.8000: Flags [S], seq 471705616, win 29200, options [mss 1368,sackOK,TS val 33199324 ecr 0,nop,wscale 7], length 0

tcpdump -i br0 -p tcp port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes

s parametrem -n to vytuhava :(

[x.para]

tcpdump -i br0 -p tcp port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

[NN]

No ocividne na ten telnet neco odpovida. Muzes pustit tcpdump i na klientovi at vidime s jakou IP se to vraci. Dale pokud das telnet 192.168.2.1 8000 na serveru mel by byt videt provoz alespon lokalne.

[x.para]

kde vidis ze na neco odpovida? ja tam prave vidim ze prichozi provoz na tun0 je bez odpovedi

[x.para]

OK, takze se snazim podle vasich rad zdumpovat provoz na zarizeni br0 na jakoukoliv sluzbu co je na br0 (www,rtsp,ssh) a vysledek je nic. na br0 ten provoz tcpdumpem nevidim i kdyz www server odpovi. nova otazka teda je jak mam udelat tcpdump na sluzby na br0?

tcpdump -i br0 tcp port 8000
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes

^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

[pupala]

Ahoj. Skús najprv stopnúť firewall. OpenVPN problémy sú poväčšie spojené s nesprávnym routovaním. A ak používaš rozhranie TUN, routuješ. Vypni FW a zisti, či je konekt OK. Vypni značí "zruš všetky pravidlá a akceptuj všetko". AK nie je konekt, skontroluj routy. ADD ak aj sú routy OK a používaš OpenWRT, tak to je ešte väčšie mecheche, nakoľko musíš použiť /etc/firewall.user, lebo konfigurácia cez LUCI zakáže forwardovanie medzi TUN a BR skôr, ako sa uplatnia tvoje pravidlá. Takže veľa zdaru. Pastni se konfigy z OpenVPN servera aj z klienta a následne routy.

[x.para]

klient:

client
dev tun
proto udp
remote mujserver.cz 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /usr/local/root/openvpn/keys/ca.crt
cert /usr/local/root/openvpn/keys/asus.crt
key /usr/local/root/openvpn/keys/asus.key
comp-lzo
verb 3

ip r
192.168.9.1 dev wan0  scope link 
192.168.1.0/27 via 192.168.3.1 dev tun0 
192.168.3.0/24 dev tun0  proto kernel  scope link  src 192.168.3.2 
192.168.2.0/24 dev br0  proto kernel  scope link  src 192.168.2.1 
192.168.9.0/24 dev wan0  proto kernel  scope link  src 192.168.9.100 
127.0.0.0/8 dev lo  scope link 
default via 192.168.9.1 dev wan0 

server:

ip r
default via 89.103.214.1 dev eth0 
89.103.214.0/24 dev eth0  proto kernel  scope link  src 89.103.214.138 
192.168.1.0/27 dev eth0  proto kernel  scope link  src 192.168.1.2 
192.168.2.0/24 via 192.168.3.1 dev tun0 
192.168.3.0/24 dev tun0  proto kernel  scope link  src 192.168.3.1 


mode server
tls-server
dev tun
proto udp #UDP or TCP transport
port 1194 

ca /etc/openvpn/keys/ca.crt 
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh2048.pem

server 192.168.3.0 255.255.255.0 
push "route 192.168.1.0 255.255.255.224" 
push "topology subnet"

ifconfig-pool-persist ip_pool.txt
topology subnet

keepalive 10 120 

client-config-dir ccd 
route 192.168.2.0 255.255.255.0 192.168.3.1 

ifconfig 192.168.2.0 255.255.255.0
client-to-client 

comp-lzo 

user nobody 
group nogroup 

persist-key 
persist-tun 

status /var/log/openvpn-status.log 20 
log /var/log/openvpn.log 
verb 3

firewal jsem zkousel vypnout a nema to na to zadny vliv. stav je ten ze pakcety jsou videt jen na tun0 a na br0 uz ne. tyka se to vsech sluzeb na br0, cili www lighthttp,dropber a www admin

jak je videt, packety pouze dorazi a uz nemaji zadnou odpoved zpatky.

 tcpdump -i tun0 port 10022
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
20:39:41.966083 IP 192.168.1.8.34416 > asus.10022: Flags [S], seq 3065059741, win 29200, options [mss 1368,sackOK,TS val 193406 ecr 0,nop,wscale 7], length 0
20:39:41.966853 IP 192.168.1.8.34416 > asus.10022: Flags [S], seq 3065059741, win 29200, options [mss 1368,sackOK,TS val 194408 ecr 0,nop,wscale 7], length 0
20:39:41.967972 IP 192.168.1.8.34416 > asus.10022: Flags [S], seq 3065059741, win 29200, options [mss 1368,sackOK,TS val 196412 ecr 0,nop,wscale 7], length 0
20:39:41.968600 IP 192.168.1.8.34416 > asus.10022: Flags [S], seq 3065059741, win 29200, options [mss 1368,sackOK,TS val 200416 ecr 0,nop,wscale 7], length 0

dneska jsem ale zjistil ze stejny problem je i obracene. z konzole openvpn klienta mi nefunguje ani ssh na openvpn server i kdyz ping normalne funguje, viz:

ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: seq=0 ttl=64 time=47.845 ms
64 bytes from 192.168.1.2: seq=1 ttl=64 time=41.445 ms
64 bytes from 192.168.1.2: seq=2 ttl=64 time=40.845 ms
^C
--- 192.168.1.2 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 40.845/43.378/47.845 ms
[admin@asus root]$ ssh -p 10001 user@192.168.1.2




....a timeout :(

uz fakt netusim kde by to mohlo byt

[GeorgeWH]

inac mam pocit, ze sa ti tam bije server 192.168.3.0 255.255.255.0 a ifconfig 192.168.2.0 255.255.255.0. to prve je len skratka pre to druhe + nieco naviac.

[x.para]

jo a je to Oleg FW takze to neni Openwrt

[GeorgeWH]

a co tak spustit tcpdump na VSETKYCH sietovkach/rozhraniach? na klientovi, openvpn serveri aj na serveri, na ktory sa chces dostat.

[GeorgeWH]

a tcpdump pustaj parametrom '-n', nech je vidiet ip adresy. a posli aj vypisy ip adries servera aj klienta.

co je to za interfce 'br0'" predpokladam, ze je to bridge. ake interfaci su v nom?

[x.para]

dik, myslim ze to zacina byt jasne?

v tom bridge neni zarizeni tun0, taky proc by tam bylo takze to ani fungivat nemuze. idealni by bylo ho tam pridat, coz tusim ze nepujde

brctl showstp br0
br0
 bridge id		8000.002618207912
 designated root	8000.002618207912
 root port		   0			path cost		   0
 max age		  20.00			bridge max age		 200.00
 hello time		   2.00			bridge hello time	  20.00
 forward delay		   0.00			bridge forward delay	   0.00
 ageing time		 300.00
 hello timer		   0.24			tcn timer		   0.00
 topology change timer	   0.00			gc timer		 274.24
 flags			


vlan0 (1)
 port id		8001			state		     forwarding
 designated root	8000.002618207912	path cost		 100
 designated bridge	8000.002618207912	message age timer	   0.00
 designated port	8001			forward delay timer	   0.00
 designated cost	   0			hold timer		   0.00
 flags			

eth1 (2)
 port id		8002			state		     forwarding
 designated root	8000.002618207912	path cost		 100
 designated bridge	8000.002618207912	message age timer	   0.00
 designated port	8002			forward delay timer	   0.00
 designated cost	   0			hold timer		   0.00
 flags			

[x.para]

pokouším se teda vyřešit routing z tun0 na br0 přes pravidlo IPTABLES

zkouším

iptables -I FORWARD -i tun0 -o br0 -s 192.168.3.0/24 -d 192.168.2.0/24 -m conntrack --ctstate NEW -j ACCEPT
iptables -I FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

a vysledek z logu:

Jan 22 10:25:56 kernel: ACCEPT IN=tun0 OUT= MAC= SRC=192.168.1.8 DST=192.168.2.1 LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=24950 DF PROTO=TCP SPT=47280 DPT=10022 SEQ=4042786163 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405580402080AFFFC64050000000001030307) 

takže packet dorazi, ale ssh spojeni se stejne nepodari a zustane viset na timeout.

nějaké nápady?

[NN]

Jenze v tom logu je:

SRC=192.168.1.8

Neni na strane klienta maskarada? Nema byt nahodou source IP z rozsahu 192.168.3.0/24. Jak vypada firewall na klietovi?

[x.para]

OK, takze tady jsou IP tables klienta:

tady jsi nejsem taky jisty jaka ma byt SRC adresa. to ssh jsem zkousel z hosta 8.1. ma to tedy byt adresa vpn tunnelu a ne hosta, jestli to chapu dobre?

# Generated by iptables-save v1.4.3.2 on Fri Jan 22 11:10:48 2016
*nat
:PREROUTING ACCEPT [2369:911422]
:POSTROUTING ACCEPT [362:23158]
:OUTPUT ACCEPT [359:22970]
:UPNP - [0:0]
:VSERVER - [0:0]
-A PREROUTING -d 192.168.9.100/32 -j VSERVER 
-A POSTROUTING ! -s 192.168.9.100/32 -o wan0 -j MASQUERADE 
-A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.0/24 -o br0 -j MASQUERADE 
-A VSERVER -p tcp -m tcp --dport 10052 -j DNAT --to-destination 192.168.2.1:8080 
COMMIT
# Completed on Fri Jan 22 11:10:48 2016
# Generated by iptables-save v1.4.3.2 on Fri Jan 22 11:10:48 2016
*mangle
:PREROUTING ACCEPT [7311:3070664]
:INPUT ACCEPT [3780:1381522]
:FORWARD ACCEPT [1151:744719]
:OUTPUT ACCEPT [4684:2818034]
:POSTROUTING ACCEPT [5834:3562713]
COMMIT
# Completed on Fri Jan 22 11:10:48 2016
# Generated by iptables-save v1.4.3.2 on Fri Jan 22 11:10:48 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [658:525764]
:OUTPUT ACCEPT [4568:2805055]
:BRUTE - [0:0]
:MACS - [0:0]
:SECURITY - [0:0]
:UPNP - [0:0]
:logaccept - [0:0]
:logdrop - [0:0]
-A INPUT -m conntrack --ctstate INVALID -j logdrop 
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A INPUT -i lo -m conntrack --ctstate NEW -j logaccept 
-A INPUT -i br0 -m conntrack --ctstate NEW -j logaccept 
-A INPUT -p udp -m udp --sport 67 --dport 68 -j logaccept 
-A INPUT -p tcp -m tcp --dport 10022 --tcp-flags FIN,SYN,RST,ACK SYN -j logaccept 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 8080 -j logaccept 
-A INPUT -d 192.168.2.1/32 -p tcp -m tcp --dport 80 -j logaccept 
-A INPUT -p tcp -m tcp --dport 10050 -j logaccept 
-A INPUT -p icmp -m icmp ! --icmp-type 8 -j logaccept 
-A INPUT -p icmp -m icmp --icmp-type 8 -j logaccept 
-A INPUT -p udp -m udp --dport 33434:33534 -j logaccept 
-A INPUT -j logdrop 
-A FORWARD -i br0 -o br0 -j logaccept 
-A FORWARD -m conntrack --ctstate INVALID -j logdrop 
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT 
-A FORWARD ! -i br0 -o wan0 -j logdrop 
-A FORWARD -m conntrack --ctstate DNAT -j logaccept 
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j RETURN 
-A SECURITY -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK RST -m limit --limit 1/sec -j RETURN 
-A SECURITY -p udp -m limit --limit 5/sec -j RETURN 
-A SECURITY -p icmp -m limit --limit 5/sec -j RETURN 
-A SECURITY -j logdrop 
-A logaccept -m conntrack --ctstate NEW -j LOG --log-prefix "ACCEPT " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode 
-A logaccept -j ACCEPT 
-A logdrop -m conntrack --ctstate NEW -j LOG --log-prefix "DROP " --log-tcp-sequence --log-tcp-options --log-ip-options --log-macdecode 
-A logdrop -j DROP 
COMMIT

udelal jsem dalsi pokus z openvpn serveru, co ma ip 192.168.1.2, na ssh se taky nedostanu ale SRC je ted adresa tunelu

Jan 22 10:10:38 kernel: ACCEPT IN=tun0 OUT= MAC= SRC=192.168.3.1 DST=192.168.2.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40964 DF PROTO=TCP SPT=35742 DPT=10022 SEQ=1933818693 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405580402080A02B91B410000000001030307) 
Jan 22 10:10:39 kernel: ACCEPT IN=tun0 OUT= MAC= SRC=192.168.3.1 DST=192.168.2.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40965 DF PROTO=TCP SPT=35742 DPT=10022 SEQ=1933818693 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405580402080A02B91BA50000000001030307) 
Jan 22 10:10:41 kernel: ACCEPT IN=tun0 OUT= MAC= SRC=192.168.3.1 DST=192.168.2.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40966 DF PROTO=TCP SPT=35742 DPT=10022 SEQ=1933818693 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405580402080A02B91C6D0000000001030307) 
Jan 22 10:10:45 kernel: ACCEPT IN=tun0 OUT= MAC= SRC=192.168.3.1 DST=192.168.2.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40967 DF PROTO=TCP SPT=35742 DPT=10022 SEQ=1933818693 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405580402080A02B91DFE0000000001030307) 
Jan 22 10:10:53 kernel: ACCEPT IN=tun0 OUT= MAC= SRC=192.168.3.1 DST=192.168.2.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40968 DF PROTO=TCP SPT=35742 DPT=10022 SEQ=1933818693 ACK=0 WINDOW=29200 RES=0x00 SYN URGP=0 OPT (020405580402080A02B921200000000001030307) 

[NN]

Ne, ja jsem nemyslel firewall VPN klieta, kde visi ten webserver. Myslel jsem firewall telnet klieta, firewall te strany, ze ktere pristupujes na webserver. Mimochodem tu maskaradu na strane webserveru, kterou si udajne odstranil tam porad mas. Takze bych doporucil laskave postupovat podle rad ktere jsi dostal.

[x.para]

tu maskaradu na strane webserveru jsem opet vyhodil, ale na to ssh to nema vliv. ten klient se porad restartuje, pokud poslu ten ssh trafic do tunnelu, cimz se tam zase ta maskarada nahodi. co muze zpusobovat ty restarty? v logu vubec nic neni, proste se to jen otoci.

zde je IP tables toho stroje ze ktereho chci pristupovat na ten web server na klientovi:

# Generated by iptables-save v1.4.21 on Fri Jan 22 13:49:40 2016
*nat
:PREROUTING ACCEPT [2818:1207388]
:INPUT ACCEPT [472:28428]
:OUTPUT ACCEPT [187:13129]
:POSTROUTING ACCEPT [27:1680]
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8088 -j DNAT --to-destination 192.168.1.6:8088
-A PREROUTING -i eth0 -p tcp -m tcp --dport 8091 -j DNAT --to-destination 192.168.1.7:80
-A PREROUTING -d 89.103.214.138/32 -p tcp -m tcp --dport 10554 -j DNAT --to-destination 192.168.2.10:554
-A POSTROUTING -o eth0 -j MASQUERADE
-A POSTROUTING -o eth0:0 -j MASQUERADE
-A POSTROUTING -d 192.168.2.10/32 -p tcp -m tcp --dport 554 -j SNAT --to-source 192.168.1.2
COMMIT
# Completed on Fri Jan 22 13:49:40 2016
# Generated by iptables-save v1.4.21 on Fri Jan 22 13:49:40 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [1516:510180]
:OUTPUT ACCEPT [268309:240054529]
-A INPUT -p tcp -m tcp --dport 14200 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10051 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10050 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10080 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10554 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10101 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 587 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10001 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 10022 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j DROP
-A FORWARD -i eth0 -o eth0:0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0:0 -o eth0 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
COMMIT
# Completed on Fri Jan 22 13:49:40 2016

[NN]

Omluva, pakety chodi se spravnou zdrojovou adresou z 192.168.1.0/27. Nicmene problem je ted jasny, ve firewallu na strane webserveru nemas povoleny port 8000 a posledni pravidlo pri INPUT je drop a jelikoz se ti firewall pravidelne resetuje(nejspise cronem..) tak se zadna tvoje uprava neprojevila.

[x.para]

Tak vyřešeno, ale nešlo to uplně zase tak jednoduše..

1. ten router FW není schopny forwardovat provoz mezi tun a br zarizenimi a to ani se spravnym nastavanim IPTABLES. je na to bug, ale vzhledem ke stari FW to asi uz nikdo neopravi, nicmene zdokumentovane to je.

2. Pouzil jsem tedy jiny stroj az za timto routerem, natavil routovani podle openvpn dokumentace a vse jelo na prvni dobrou.

3. Pak jeste pocitat s tim, ze openvpn enkapsuluje vsechny packety do p-2-p adres rozsahu a tim padem vse co prijde na zarizeni tun0 bude mit SRC IP tunnelu a ne skutecnou IP hosta! Podle toho je potreba uravit routing a nastavit maskarady na zarizeni tun.

tot vse, diky vsem za vase odpovedi!