Routing portů z VPN ven

[lukash]

zdravim
moj problem je asi takyto
mam konfiguraciu server a pc ktore su spolu vo vpn. server je zaroven vpn server a je skovany za routrom s verejnou ip  kde su setky porty forwardovane na server. moja poziadavka od zostavy je taka ze ked na vpn klientovi pustim web server tak chcem sa z hocijakeho pocitacu mimo vpn dostat na stranku tohto web servra. pouzivam openvpn

server a aj vpn klient idu pod linuxom

vpn pracuje v poriadku s tym problemy niesu skusal som na servry routovanie cez iptables
co sa mi zrejme aj podarilo kedze vypis z tcpdumpu na klientovi mi ukazal ze na klientovu ip (10.0.0.6) prichadza komunikacia z verejnej ip cez interface tun0 co je spravne. no klient neodosielal ziadnu odpoved. ked som si pozeral logy web servra (apachu) neukazalo ziaden pristup na stranku a tu je ten problem ze ip sa zrejme aj preroutuje aj s portom ale na stranku sa nedostane. jednoducho povedane.

Pre istotu pridavam konfiguraciu openvpn ako na serverovej tak aj na clientovej strane prikazy do iptables a vypis z tcpdumpu

server

Kód: [Vybrat]

mode server
dev tun0

server 10.0.0.0 255.255.255.0

keepalive 10 120
port 1194
proto udp
tun-mtu 1500

persist-key
persist-tun
tls-server

client-to-client

ifconfig-pool-persist ipp.txt

route "192.168.0.0 255.255.255.0 10.0.0.1"
push "route 192.168.0.0 255.255.255.0 10.0.0.1"
;push "redirect-gateway"
ca /etc/openvpn/ca.crt
cert /etc/openvpn/server.crt
key /etc/openvpn/server.key
dh /etc/openvpn/dh1024.pem
client-config-dir /etc/openvpn/ccd
log /var/log/openvpn
status /var/run/openvpn/vpn.status 10
tls-auth /etc/openvpn/ta.key 0

client

Kód: [Vybrat]

client
tls-client
dev tun0
proto udp
remote 78.1.2.3 1194
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/test.crt
key /etc/openvpn/test.key
tls-auth /etc/openvpn/ta.key 1
pull
daemon


iptables prikazy

Kód: [Vybrat]

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.6:80
iptables -A FORWARD -i tun0 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -p tcp --syn --dport 80 -j ACCEPT

vypis z tcpdumpu

Kód: [Vybrat]

23:18:11.216306 IP 78.1.2.3.60057 > 10.0.0.6.80: Flags [S], seq 146517368, win 8192, options [mss 1369,nop,wscale 2,nop,nop,sackOK], length 0
23:18:13.798324 IP 78.1.2.3.60057 > 10.0.0.6.80: Flags [S], seq 146517368, win 8192, options [mss 1369,nop,wscale 2,nop,nop,sackOK], length 0

za kazdy postreh budem vdacny

[Reklama]

[chladic01]

moja poziadavka od zostavy je taka ze ked na vpn klientovi pustim web server tak chcem sa z hocijakeho pocitacu mimo vpn dostat na stranku tohto web servra

spravne chapem, ze chcete routovat provoz z vonkajsieho interface klienta cez vpn tunel na server ?

[spoky]

moja poziadavka od zostavy je taka ze ked na vpn klientovi pustim web server tak chcem sa z hocijakeho pocitacu mimo vpn dostat na stranku tohto web servra

spravne chapem, ze chcete routovat provoz z vonkajsieho interface klienta cez vpn tunel na server ?

z vonkajsieho interface servera cez vpn tunel na klienta..  takto

[kacer]

Nejsem sice odborník, ale něco podobného provozuji a mám dojem, že na takovéto hrátky jako třeba routování je potřeba (a nebo je to lepší) použít VPN přes zařízení typu tap namísto tun. Pak se to chová jako standardní síťový adaptér.

[lukash]

TAP (as in network tap) simulates an Ethernet device and it operates with layer 2 packets such as Ethernet frames. TUN (as in network TUNnel) simulates a network layer device and it operates with layer 3 packets such as IP packets. TAP is used to create a network bridge, while TUN is used with routing.

Tu by malo ist o routing nie o network bridge

[Reklama]

[lukash]

pls help

[David]

No vzdyt chces na serveru routovat pozadavky na port 80 z routeru do VPN. No tak jednoduse v iptables FORWARD povol port 80 z eth do tun, nastav PREROUTING (NAT z eth adres na tun adresy) a zapni (a nastav) routovani (z eth na tun). Nebo mi neco uniklo?

[spoky]

ten vypis z tcpdumpu je z vpn klienta a je tam znazornene to ze ono aj poziadavka prichadza len neni odpoved cize preroutovanie je zrejme dobre.. hore su aj prikazy napisane co sme pouzili... ale problem je zrejme v klientovi lebo odpoved neposiela... a ked sme skusali pozerat pristupove logy na webservry klienta na ktory sa chceme zvonka dostat tak niesu v logoch ziadne pristupy cize ono sa na klienta ip preroutuje ale v klientovi sa nedostane na web server

tam si myslim ze je problem v klientovi.. lukash hovori ze mame zle nastavene preroutovanie a pod preto su tu setky konfigy vpn servra aj klienta a aj pouzite prikazy ze ci nahodou neni daco zle

[chladic01]

Jen taky mozno hlupy dotaz, bezi vam na klientovi apache na vpn rozhrani, nie na vonkajsom interface ?

[chladic01]

ked Vam ten apache na tun rozhrani bezi, tak to ten klient potom s odpovedou posle na vonkajsi interface, preto to asi nevidite v tom tcpdump. Skuste spustit zaroven tcpdump aj na vonkajsom interface klienta, ci tam nahodou nelietaju odpovede

[lukash]

vies nam poradit ako spustit apache na tun rozhrani? lebo asi tam je prave ten problem

[maestro]

Ahoj,

jestli je SRC spojeni jdoucich skrz tunel z verejneho rozsahu tak to nebude fungovat, pokud na klientovi neni default routa pres tunel. Pokud SRC neni z verejneho rozsahu, tak na klientovi pust "ip r g <SRC>" a koukni jakym interfacem se ti data routujou zpatky. POkud tam neni iF VPN tunelu, tak mas spatne routovani an klientovi. Pokud ano, tak ti budto data reze FW. Aplikace tam asi bezi, protoze jinak by to vracelo "Connection refused"...

V

[chladic01]

Ano, maestro ma pravdu. Ja by som ale asi cele riesenie koncipoval inac,na serveru by som spustil reverse proxy, ktory by posielal vsetky poziadavky cez tun na klienta.

[Roman]

Zdravim, podla rychleho precitania vasej spravy som nepostrehol niekolko veci.
1. neviem ci mate povoleny port forwarding cat /proc/sys/net/ipv4/ip_forward ? musi byt 1, default je 0
2. nevidim povoleny FORWARD pre lan na tun0 (obojstranny, ale premyslene ...  to znamena, ze len pre urcite IP a porty)
Snad to pomoze .....

[faha]

Maestro je opravdu maestro a ma pravdu, dotaz sice dorazi pres VPN tunel az na server kde bezi http (pokud vam tedy poslouch na tun zarizeni, ale to uz je druhe kolo problemu), zde by melo dojit ke zpracovani a odeslani zpet, bohuzel nejspise stroj netusi kam ma poslat odpoved (on netusi, ze ma jit tunnel zpet), protoze vidi dotaz z nejake verejne IP a tak ji prirozene bude nejspise odbavovat smerem pres svoji defaul routu.

Reseni je mozne a to hned nekolika cestami, jednak lze veskery provoz (default route) smerovat to VPN tunelu nebo lze na serveru VPN zanatovat dotaz za svoji IP adresu tunelu smerem ke klientovi, navrh reseni s proxy taky nezni uplne spatne.

Jen dotaz, proc takove krkolomne reseni? Nebylo by jednodusi spustit http primo na serveru a idealne dat verejnou primo na server (bridge nebo treba PPPoE v pripade ADSL).