abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 13:44 | Zajímavý software

Evropská komise vydala novou verzi 1.4.0.1 svého open source v Javě naprogramovaného softwaru pro online průzkumy EUSurvey. Online dotazníky lze vytvářet na stránkách Evropské komise nebo si lze software stáhnout (zip a war) a nainstalovat lokálně. Zdrojové kódy jsou k dispozici pod licencí EUPL (European Union Public Licence).

Ladislav Hagara | Komentářů: 0
včera 23:55 | Komunita

Ubuntu 17.10 (Artful Aardvark) bude ve výchozím stavu zobrazovat Dok (Launcher). Jedná se o rozšíření GNOME Shellu Ubuntu Dock. To bylo forknuto z rozšíření Dash to Dock. Ukázka na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
17.8. 15:33 | Nová verze

Byla vydána verze 17.08.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace kmag, kmousetool, kgoldrunner, kigo, konquest, kreversi, ksnakeduel, kspaceduel, ksudoku, kubrick, lskat a umbrello byly portovány na KDE Frameworks 5.

Ladislav Hagara | Komentářů: 0
17.8. 15:11 | Nová verze

Simon Long představil na blogu Raspberry Pi novou verzi 2017-08-16 linuxové distribuce Raspbian určené především pro jednodeskové miniaturní počítače Raspberry Pi. Společně s Raspbianem byl aktualizován také instalační nástroj NOOBS (New Out Of the Box Software). Nejnovější Raspbian je založen na Debianu 9 Stretch. Přehled novinek v poznámkách k vydání. Řešena je také bezpečnostní chyba Broadpwn (CVE-2017-9417).

Ladislav Hagara | Komentářů: 1
17.8. 12:33 | Nová verze

Byla vydána verze 3.2.0 programu pro skicování, malování a úpravu obrázků Krita. Přehled novinek v poznámkách k vydání a na YouTube.

Ladislav Hagara | Komentářů: 0
17.8. 11:44 | IT novinky

Minulý týden na šampionátu The International 2017 byl představen bot, který poráží profesionální hráče počítačové hry Dota 2. V nejnovějším příspěvku na blogu se organizace OpenAI o projektu více rozepsala a zveřejnila videozáznamy několika soubojů.

Ladislav Hagara | Komentářů: 7
16.8. 17:11 | Komunita

Byly zveřejněny videozáznamy přednášek z Fedora 26 Release Party konané 10. srpna v Praze.

Ladislav Hagara | Komentářů: 0
16.8. 15:33 | Komunita

Přesně před čtyřiadvaceti lety, 16. srpna 1993, oznámil Ian Murdock vydání "Debian Linux Release".

Ladislav Hagara | Komentářů: 8
16.8. 06:00 | Bezpečnostní upozornění

Ve virtualizačním softwaru Xen bylo nalezeno a opraveno 5 bezpečnostních chyb XSA-226 až XSA-230. Nejzávažnější z nich XSA-227 (CVE-2017-12137) umožňuje eskalaci privilegií a ovládnutí celého systému, tj. správce hostovaného systému se může stát správcem hostitelského systému.

Ladislav Hagara | Komentářů: 1
15.8. 22:00 | Zajímavý projekt

V roce 2013 proběhla na Kickstarteru úspěšná kampaň na podporu otevřeného Dobře temperovaného klavíru (Well-Tempered Clavier). Stejný tým s Kimiko Išizaka spustil před týdnem na Kickstarteru kampaň Libre Art of the Fugue na podporu svobodného Umění fugy.

Ladislav Hagara | Komentářů: 2
Těžíte nějakou kryptoměnu?
 (4%)
 (2%)
 (17%)
 (76%)
Celkem 358 hlasů
 Komentářů: 21, poslední 13.8. 09:57
    Rozcestník

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

    20.1.2016 18:37 x.para | skóre: 11 | blog: x_para
    Přístup na služby OPENVPN klienta - asi routing
    Přečteno: 336×
    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?


    Řešení dotazu:


    Odpovědi

    Jendа avatar 20.1.2016 18:49 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    tcpdump, co jiného na to poradit.

    Btw. příště prosím ip r, výpisy z route neumím číst.
    tf_train.py:93: global_step=110749, loss=1.4074e+17
    20.1.2016 19:37 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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а avatar 20.1.2016 20:40 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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)
    tf_train.py:93: global_step=110749, loss=1.4074e+17
    20.1.2016 20:43 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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а avatar 20.1.2016 20:48 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    -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?
    tf_train.py:93: global_step=110749, loss=1.4074e+17
    20.1.2016 20:56 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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а avatar 20.1.2016 21:48 Jendа | skóre: 74 | blog: Výlevníček | JO70FB
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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.
    tf_train.py:93: global_step=110749, loss=1.4074e+17
    20.1.2016 21:57 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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
    20.1.2016 22:26 NN
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    Dej sem netstat -an. Jses si jisty ze na 8000 skutecne neco posloucha?
    20.1.2016 22:28 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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    
    20.1.2016 22:31 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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
    20.1.2016 23:10 NN
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    HTTP/1.0 400 Bad Request
    Je odpoved serveru => normalne to chodi. Pust ten tcpdump na br0 s parametrem -n -p.
    20.1.2016 23:31 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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 :(
    20.1.2016 23:32 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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
    21.1.2016 11:57 NN
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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.
    21.1.2016 12:42 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    kde vidis ze na neco odpovida? ja tam prave vidim ze prichozi provoz na tun0 je bez odpovedi
    21.1.2016 15:35 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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
    21.1.2016 20:55 pupala | skóre: 20
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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.
    21.1.2016 21:08 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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
    21.1.2016 23:28 GeorgeWH | skóre: 36
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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.
    21.1.2016 21:09 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    jo a je to Oleg FW takze to neni Openwrt
    21.1.2016 22:38 GeorgeWH | skóre: 36
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    a co tak spustit tcpdump na VSETKYCH sietovkach/rozhraniach? na klientovi, openvpn serveri aj na serveri, na ktory sa chces dostat.
    21.1.2016 22:58 GeorgeWH | skóre: 36
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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?
    21.1.2016 23:06 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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			
    
    
    
    
    22.1.2016 10:41 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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?
    22.1.2016 10:49 NN
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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?
    22.1.2016 11:21 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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) 
    
    22.1.2016 12:08 NN
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing2016
    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.
    22.1.2016 13:53 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing2016
    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
    
    22.1.2016 16:46 NN
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing2016
    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.
    Řešení 1× (x.para (tazatel))
    25.1.2016 12:32 x.para | skóre: 11 | blog: x_para
    Rozbalit Rozbalit vše Re: Přístup na služby OPENVPN klienta - asi routing
    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!

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.