Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: darebacik 08. 06. 2018, 17:38:59
-
Topologia je nasledovna:
OpenVPN_server_Linux(10.8.0.1)------Internet------OpenVPN_client_LEDE/OpenWRT(10.8.1.140)-----LAN_192.168.80.0/24-----Stroj_bez_OpenVPN_192.168.80.100Stroj_bez_OpenVPN nepozna openvpn (je to hlupy stroj, ale ma LAN).
V tejto konfiguracii podla topologie, dokazem zo stroja 192.168.80.100 pingat 10.8.0.140.
Ja sa vsak potrebujem zo strojom 192.168.80.100 dostat na 10.8.0.1.
Je to vobec mozne nastavit ?
-
Měl jsem to nějak podobně, nastavil jsem na klientovi nat s maškarádou, tj
iptables -t nat -A POSTROUTING -i $ETH -o $VPN -j MASQUERADEpak povolit forwarding mezi rozhraními
iptables -A FORWARD -i $ETH -o $VPN -j ACCEPT
iptables -A FORWARD -o $ETH -i $VPN -j ACCEPT
sammozřejmě mít zapnutý forwarding v jádře.
-
Nikdo nic, pritom to je docela bezna situace. (?)
Pokud jde o me chabe znalosti, tak ten uprostred musi povolene forwardovani (to uz psal kolega prede mnou, v jadre viz sysctl).
A v principu to pak musi jit i bez natu. Ovsem za predpokladu, ze stroj 10.8.0.1 zna routu do 192.168.80.0/24 a stroj 192.168.80.100 zna routu do 10.8.x.y.
-
Měl jsem to nějak podobně, nastavil jsem na klientovi nat s maškarádou, tj
iptables -t nat -A POSTROUTING -i $ETH -o $VPN -j MASQUERADEpak povolit forwarding mezi rozhraními
iptables -A FORWARD -i $ETH -o $VPN -j ACCEPT
iptables -A FORWARD -o $ETH -i $VPN -j ACCEPT
sammozřejmě mít zapnutý forwarding v jádře.
ipv4 forward by asi mal byt na routery zapnuty uz v defaultnej konfiguracii.
Vstupne zariadenie asi pri postroutingu pouzit nemozem (dostanem hlasku)
iptables v1.4.21: Can't use -i with POSTROUTINGMalo by tam byt asi len -o a maskaradovat sa bude vsetko co opusta -o.
Ale nie som na to odnornik, takze to neviem na isto.
Nikdo nic, pritom to je docela bezna situace. (?)
Pokud jde o me chabe znalosti, tak ten uprostred musi povolene forwardovani (to uz psal kolega prede mnou, v jadre viz sysctl).
A v principu to pak musi jit i bez natu. Ovsem za predpokladu, ze stroj 10.8.0.1 zna routu do 192.168.80.0/24 a stroj 192.168.80.100 zna routu do 10.8.x.y.
Pre mna to bezna situacia neni :)
-
Asi to mám taky jen s -o, možná by to ještě vzalo -s 192.168.80.0/24. Ale toto funguje, ne?
-
ANo skusil som pravidlo
iptables -t nat -A POSTROUTING -s 192.168.80.0/24 -o tun0 -j MASQUERADEa forward
iptables -A FORWARD -i br-lan -o tun0 -j ACCEPT
iptables -A FORWARD -o br-lan -i tun0 -j ACCEPTAle volajako to nefunguje (na 10.8.0.1 nedosiahnem)
-
Na klientovi potřebujete routu do sítě kam se chcete dostat. Brána je OpenVPN server.
Automatické nastavení routy na klientech se konfiguruje na serveru pomocí push.
-
Na klientovi potřebujete routu do sítě kam se chcete dostat. Brána je OpenVPN server.
Automatické nastavení routy na klientech se konfiguruje na serveru pomocí push.
A na serveru kromě maškarády musí být nastaveno tunelování VPN.
Přiznám se, že nevím, jak se to udělá s čistými IPtables, ale se Shorewallem stačí v /etc/shorewall/tunnels zadat něco jako:
openvpn:1194 loc 0.0.0.0/0
kdy openvpn je název, 1194 je číslo portu, loc je název lokální sítě a 0.0.0.0/0 je adresa sítě, kam se má tunelovat.
-
zrejme to az take trivialne nebude ako sa zdalo byt. Ocakaval som, ze bude potrebna routa v lede medzi tun0 (openvpn) a br-lan(ethernet).
Asi tomu az tak velmi nerozumiem.
Z prveho prispevku je jasne, ze medzi ovpn serverom a ovpn klientom spojenie funguje (pingam 10.8.0.1 a 10.8.0.140).
Medzi ovpn klientom v leda a lan klientom, spojenie taktiez funguje (pingam 10.8.0.140 a 192.168.80.100).
Teoreticky by sa malo nasmerovat 192.168.80.0/24 na 10.8.0.1.
Bohuzial si neviem sam poradit. Teoria je pekna vec, ale ja to potrebujem spravit aj prakticky
-
zrejme to az take trivialne nebude ako sa zdalo byt. Ocakaval som, ze bude potrebna routa v lede medzi tun0 (openvpn) a br-lan(ethernet).
Asi tomu az tak velmi nerozumiem.
Z prveho prispevku je jasne, ze medzi ovpn serverom a ovpn klientom spojenie funguje (pingam 10.8.0.1 a 10.8.0.140).
Medzi ovpn klientom v leda a lan klientom, spojenie taktiez funguje (pingam 10.8.0.140 a 192.168.80.100).
Teoreticky by sa malo nasmerovat 192.168.80.0/24 na 10.8.0.1.
Bohuzial si neviem sam poradit. Teoria je pekna vec, ale ja to potrebujem spravit aj prakticky
Jak jsem psal: router na druhé straně (tzn. OpenVPN server) musí vědět, že má pakety z VPN tunelu posílat dále do LAN. Já to umím nastavit jen se Shorewallem, ale Google by měl dodat relevantní odpověď. Třeba:
https://arashmilani.com/post?id=53
-
Takže server má VPNadresu 10.8.0.1, klient má VPNadresu 10.8.0.140 a LANadresu 192.168.80.kolik?, stroj má LANadresu 192.168.80.100.
Má stroj masku 192.168.80.255 a bránu "LANadresa klienta"?
Jak má klient routování (route -n)? Je na klientovi zapnutá maškaráda do VPN?
-
Je to tak ako pises, (v prvom prispevku je topologia siete)
OpenVPN_server_Linux(10.8.0.1)------Internet------OpenVPN_client_LEDE/OpenWRT(10.8.1.140)-----LAN_192.168.80.0/24-----Stroj_bez_OpenVPN_192.168.80.100OpenVPN Server ma IP adresu 10.8.0.1.
OpenVPN_client_LEDE/OpenWRT uspesne ziskal od OpenVPN servera IP adresu 10.8.0.140 (cize odtial sa pingnem na 10.8.0.1)
LEDE/OpenWRT - LAN adresa siete 192.168.80.0/24.
Má stroj masku 192.168.80.255 a bránu "LANadresa klienta"?
Jak má klient routování (route -n)? Je na klientovi zapnutá maškaráda do VPN?
Teraz ti neviem povedat aku ma stroj masku (ale mal by mat 255.255.255.0 (CIDR /24).
Klienta myslis ten hlupy stroj s 192.168.80.100 ? Alebo myslis LEDE/OpenWRT ?
momentalne je openwrt nejaky rozbity, takze zajtra ho resetujem a nastavim na novo (nemam ani backup, zatial som ho nerobil, lebo vela zmien oproti defaultu tam neni).
Ale ako som spomenul vyssie tak som tam zatial supol tieto pravidla
toto do NATu
iptables -t nat -A POSTROUTING -s 192.168.80.0/24 -o tun0 -j MASQUERADEa tieto do filtra
iptables -A FORWARD -i br-lan -o tun0 -j ACCEPT
iptables -A FORWARD -o br-lan -i tun0 -j ACCEPTale aj tak to nechodilo
-
Pokud váš router s OpenWRT dostane IP od VPN serveru, tak vše funguje správně. Jediné, co potřebuje mít nastaveno, jsou routy do všech sítí, do kterých se chcete na druhé straně dostat, což může proběhnout automaticky nebo ručně, to je jedno. Ostatní (maškaráda, předávání dat z tunelu do LAN na druhé straně) je třeba řešit na VPN serveru. A zakopaný pes je na 99% právě v tom, že pakety sice doputují na VPN server, ale ten neví, co s nimi dále dělat.
-
Ostatní (maškaráda, předávání dat z tunelu do LAN na druhé straně) je třeba řešit na VPN serveru
To si nemyslím, na serveru ty pakety končí a tak NAT není potřebný. Ten je potřebný na klientovi. push/pull je určený spíše pro přidání routy do sítě za servem.
Mě by zajímal výpis z klienta
ip routea
iptables -t nat -LTy pravidla může být potřeba dát na začátek -I místo -O, aby to něco neblokovalo. Pak mě napadlo - jakou IP má WAN klienta? ten přeci routuje net. Jestli tam není nějaká kolize rozsahů s VPN. Na VPN je rozsah /24?
-
Pokud váš router s OpenWRT dostane IP od VPN serveru, tak vše funguje správně. Jediné, co potřebuje mít nastaveno, jsou routy do všech sítí, do kterých se chcete na druhé straně dostat, což může proběhnout automaticky nebo ručně, to je jedno. Ostatní (maškaráda, předávání dat z tunelu do LAN na druhé straně) je třeba řešit na VPN serveru. A zakopaný pes je na 99% právě v tom, že pakety sice doputují na VPN server, ale ten neví, co s nimi dále dělat.
Ospravedlnujem sa, nie som sietar, ale tato problematika ma zaujma a ak mam cas, tak vzdy s niecim experimentujem.
Ano presne tak ako pisete (mam to uz aj v prvom prispevku) OpenWRT adresuu uspesne od OpenVPN servera ziska.
Ja si to vysvetlujem takto:
Spojenie 10.8.0.1 --- 10.8.0.140 funguje
Spojenie 10.8.0.140 --- 192.168.80.100 funguje
Spojenie 192.168.80.100 --- 10.8.0.1 nefungujeCize jedno riesenie je spravit v OpenWRT NAT, ale nie medzi LAN a WAN, ale medzi LAN a TUN.
Alebo druhe riesenie je routovanie. Ja sa vsak mojim malym mozgom domnievam, ze pakety treba smerovat medzi sietami z roznymi IP adresami. V tomto pripade sa musi smerovat medzi 192.168.80.1 a 10.8.0.140.
Lebo ten hlupy stroj co ma IP 192.168.80.100 netusi, ze existuje nejaka IP 10.8.0.1 (ale vie, ze existuje 10.8.0.140 (ta IP by mala predstavovat vlastne GW z pohladu 192.168.80.100)).
Sorry ja som este nikdy neroutoval, v zdy co sa dalo, tak som bridgoval :)
Ostatní (maškaráda, předávání dat z tunelu do LAN na druhé straně) je třeba řešit na VPN serveru
To si nemyslím, na serveru ty pakety končí a tak NAT není potřebný. Ten je potřebný na klientovi. push/pull je určený spíše pro přidání routy do sítě za servem.
Mě by zajímal výpis z klienta
ip routea
iptables -t nat -LTy pravidla může být potřeba dát na začátek -I místo -O, aby to něco neblokovalo. Pak mě napadlo - jakou IP má WAN klienta? ten přeci routuje net. Jestli tam není nějaká kolize rozsahů s VPN. Na VPN je rozsah /24?
Vystup IP route
default via 192.168.1.1 dev eth0.2 src 192.168.1.154
10.8.0.0/24 dev tun0 src 10.8.0.140
192.168.1.0/24 dev eth0.2 src 192.168.1.154
192.168.1.1 dev eth0.2 src 192.168.1.154
192.168.80.0/24 dev br-lan src 192.168.80.1
A nat tabulka, je to ale dost neprehladne. Je tam aj ta maskarada, vid. prispevky vyssie.
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
prerouting_rule all -- anywhere anywhere /* !fw3: user chain for prerouting */
zone_lan_prerouting all -- anywhere anywhere /* !fw3 */
zone_wan_prerouting all -- anywhere anywhere /* !fw3 */
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
postrouting_rule all -- anywhere anywhere /* !fw3: user chain for postrouting */
zone_lan_postrouting all -- anywhere anywhere /* !fw3 */
zone_wan_postrouting all -- anywhere anywhere /* !fw3 */
MASQUERADE all -- 192.168.80.0/24 anywhere
Chain postrouting_lan_rule (1 references)
target prot opt source destination
Chain postrouting_rule (1 references)
target prot opt source destination
Chain postrouting_wan_rule (1 references)
target prot opt source destination
Chain prerouting_lan_rule (1 references)
target prot opt source destination
Chain prerouting_rule (1 references)
target prot opt source destination
Chain prerouting_wan_rule (1 references)
target prot opt source destination
Chain zone_lan_postrouting (1 references)
target prot opt source destination
postrouting_lan_rule all -- anywhere anywhere /* !fw3: user chain for postrouting */
Chain zone_lan_prerouting (1 references)
target prot opt source destination
prerouting_lan_rule all -- anywhere anywhere /* !fw3: user chain for prerouting */
Chain zone_wan_postrouting (1 references)
target prot opt source destination
postrouting_wan_rule all -- anywhere anywhere /* !fw3: user chain for postrouting */
MASQUERADE all -- anywhere anywhere /* !fw3 */
Chain zone_wan_prerouting (1 references)
target prot opt source destination
prerouting_wan_rule all -- anywhere anywhere /* !fw3: user chain for prerouting */
REDIRECT tcp -- anywhere anywhere tcp dpt:9999 /* !fw3: luci-remote */ redir ports 443
-
Myslím, že už vzniká zmatek, tak to zkusím shrnout a popsat celé znovu a pokud možno jednoduše.
Vy de facto nestavíte běžné VPN spojení (kdy se jeden klient spojí s VPN serverem, přes vzniklý tunel teče veškerý traffic z klienta a VPN server rozhodne, co kam půjde dále), ale tunelové spojené dvou sítí.
1) Tunel se naváže mezi dvěma koncovými body, u vás to jsou router s OpenWRT a na druhé straně OpenVPN server.
Toto vám evidentně funguje, protože z OpenWRT pingnete na OpenVPN server.
2) Abyste se z počítače v LAN, která je za routerem s OpenWRT, dostal (třeba pomocí pingu) na OpenVPN server, nemusíte na tomto počítači nic nastavovat. Jeho žádná VPN nezajímá, protože pro něj je to běžný traffic někam mimo vlastní síť, o jehož směřování se stará default gateway. Takže aby to fungovalo, musíte na routeru s OpenWRT mít správně nastavenu routu do sítě s OpenVPN, ve vašem případě 10.8.0.0 přes rozhraní tunelu. Pokud tam bude, router pozná, že požadavky do sítě 10.8.0.0 má směřovat právě tudy a tak to udělá. V tom okamžiku se z počítače ve vaší LAN dostanete na OpenVPN server, ale už ne dále. Toto vám zřejmě také funguje, takže i routu v OpenWRT routeru máte nastavenu správně.
3) Abyste se dostal dále, tzn. na stroj, který je ve vzdálené LAN za OpenVPN serverem - ať už z vašeho OpenWRT routeru nebo z počítačů v LAN za ním - musí váš OpenVPN server vědět, že má paktety, které k němu připutovaly přes tunel ze sítě 192.168.80.0, posílat dále do své LAN. Pokud na něm toto nastavíte, začne to celé fungovat přesně tak, jak potřebujete. Bohužel vám neumím poradit, jak to udělat s čistými IPtables pravidly, protože desítky let pro jejich nastavování používám výhradně Shorewall.
Když si vypíšu svá IPtables pravidla, vztahující se k mému IPsec tunelu, mám tam něco takového (změnil jsem adresu své sítě na tu vaši):
# iptables -L | grep vpn
vpn_frwd all -- 192.168.80.0/24 anywhere [goto] policy match dir in pol ipsec
vpn2fw all -- 192.168.80.0/24 anywhere policy match dir in pol ipsec
fw2vpn all -- anywhere 192.168.80.0/24 policy match dir out pol ipsec
Chain fw2vpn (1 references)
Chain loc2vpn (1 references)
loc2vpn all -- anywhere 192.168.80.0/24 policy match dir out pol ipsec
Chain net2vpn (1 references)
net2vpn all -- anywhere 192.168.80.0/24 policy match dir out pol ipsec
Chain vpn2fw (1 references)
Chain vpn2loc (1 references)
Chain vpn2net (1 references)
Chain vpn_frwd (1 references)
vpn2loc all -- anywhere anywhere policy match dir out pol none
vpn2net all -- anywhere anywhere policy match dir out pol none
vpn je zóna mého IPsec tunelu, fw je zóna serveru, loc je zóna lokální sítě za VPN serverem a net je zóna vnějšího Internetu. Samozřejmě tam místo adresy vzdálené LAN můžete mít i anywhere, pokud by router s OpenWRT sloužil jako gateway pro více sítí, to už záleží na vaší konfiguraci.
Když to celé shrnu:
- nemusíte nastavovat nic na počítači ve vaší LAN za OpenWRT, protože ten to vůbec nezajímá
- na OpenWRT routeru taky nemusíte nic zvláštního kromě VPN spojení nastavovat, jen obyčejnou routu tak, aby pakety do cílové sítě tekly přes tunel a ne do Internetu
- na OpenVPN serveru musíte správně nastavit předávání paketů z tunelu dál do LAN za serverem
Snad to je dostatečně srozumitelné.
-
Ještě jsem zapomněl připsat k výpisu IPtables maškarádu:
MASQUERADE all -- 192.168.80.0/24 anywhere policy match dir out pol none
-
Staci na stroji bez_OpenVPN_192.168.80.100 nastavit spravnu routu:
ip route add 10.8.0.0/24 via 192.168.80.xxx
Kde xxx je posledna cast IP adresy klienta. (Z dotazu sa neda vycitat.)
Na klientovi musi samozrejme bezat forward paketov...
-
Áááá ... stroj by měl mít masku 255.255.255.0, ne 192.168.80.255 (to jsem tedy napsal pěkně blbě), a bránu "LANadresa klienta".
> Spojenie 10.8.0.140 --- 192.168.80.100 funguje
No, to by se skoro nemělo normálně použít. Jestli tím myslíš spojení WRT-strij, použije se prostě "LANadresa WRT" (to je 192.168.80.X (napiš ji už)) a IPadresa stroje. Tedy "Spojení 192.168.80.? -- 192.168.80.100". A není důvod, aby toto nefungovalo.
> Cize jedno riesenie je spravit v OpenWRT NAT, ale nie medzi LAN a WAN, ale medzi LAN a TUN.
Mezi LAN a WAN ho nech, to je kvůli normálnímu přístupu na internet. Ale přidej mazi LAN a TUN (maškarádu uplatnit pro odchozí pakety do VPN).
> Lebo ten hlupy stroj co ma IP 192.168.80.100 netusi, ze existuje nejaka IP 10.8.0.1 (ale vie, ze existuje 10.8.0.140 (ta IP by mala predstavovat vlastne GW z pohladu 192.168.80.100)).
Ten stroj by neměl vědět, že existuje 10.8.0.140. Měl by vědět jen to, že on má IPadresu 192.168.80.100 a bránou pro jiné sítě je 192.168.80.X (zas ta LANadresa WRT).
Takže když chce stroj poslat paket serveru VPN (nebo klientu VPN, nebo komukoliv jinému mimo síť 192.168.80.0), pošle ji LANadrese WRT (své univerzální bráně). WRT tak dostane paket směřující do 10.8.0.1 a tak ho tam pošle; je ale potřeba, aby udělal maškarádu (NAT) a odeslal ho "jménem své adresy 10.8.0.140", jinak by server VPN dostal paket od jakéhosi 192.168.80.100 a nevěděl by, co s ním. Bude-li paket správně zamaškarádovaný, z pohledu serveru VPN bude pocházet z klienta VPN, takže svou dpověď pošle server VPN zpět lklientu VPN, ten ji "odmaškaráduje" a předá hloupému stroji.
-
jinak by server VPN dostal paket od jakéhosi 192.168.80.100 a nevěděl by, co s ním
No však tak je to taky v pořádku. Pak bude v logu jasně vidět, kdo se kam pokouší připojit. Pokud to celé schováte za router, tak nikdy nikde neuvidíte, z jaké adresy kdo kam přistupoval, všude bude jen adresa maškarády.
Mělo by to být nastaveno tak, jak jsem psal o kousek výše - tzn. o finální předání paketů do cíle se má starat VPN server, ne klient ani zdrojový počítač. Zbytek je klasický tunel, bez ohledu na to, že je realizován pomocí služby s názvem OpenVPN. To, že by se takové věci měly dělat spíše pomocí IPsecu je už jiná písnička.
-
jinak by server VPN dostal paket od jakéhosi 192.168.80.100 a nevěděl by, co s ním
No však tak je to taky v pořádku. Pak bude v logu jasně vidět, kdo se kam pokouší připojit. Pokud to celé schováte za router, tak nikdy nikde neuvidíte, z jaké adresy kdo kam přistupoval, všude bude jen adresa maškarády.
Mělo by to být nastaveno tak, jak jsem psal o kousek výše - tzn. o finální předání paketů do cíle se má starat VPN server, ne klient ani zdrojový počítač.
...
To je věcí názoru.
V mnoha případech se pozná zdroj už podle portu, aplikace běžně může logovat i něco (třeba název protistrany) z obsahu paketů a tedy nějaké IP je nezajímavé apod.
Použití maškarády je často jednodušší. Kdyby si za WRT přidal další síť, v případě maškarády nebude muset nic nastavovat. V případě speciálního směrování na serveru VPN by musel zasahovat i do něj (a nutnost závislého nastavování na více místech je vždy náročnější na údržbu).
Kdyby si do VPN připojil dalšího klienta WRT2 z jiného místa a tam by měl opět síť 192.168.80.0 (Proč ne? Konfiguraci už má ověřenou, použije stejnou.), co by pak měl psát do směrování v serveru VPN?
-
Použití maškarády je často jednodušší. Kdyby si za WRT přidal další síť, v případě maškarády nebude muset nic nastavovat. V případě speciálního směrování na serveru VPN by musel zasahovat i do něj (a nutnost závislého nastavování na více místech je vždy náročnější na údržbu).
Nemusel. Klidně si může směřovat všechny požadavky, záleží na tom, jak si to nastaví.
Nicméně to, že součástí konfigurace nového tunelu je i nastavení směřování paketů z něj, je naprosto v pořádku.
Kdyby si do VPN připojil dalšího klienta WRT2 z jiného místa a tam by měl opět síť 192.168.80.0 (Proč ne? Konfiguraci už má ověřenou, použije stejnou.), co by pak měl psát do směrování v serveru VPN?
Toto se prostě nedělá. Důvod je jednoduchý: může být potřeba i provoz mezi tunelovanými sítěmi navzájem. Proto se nikdy nepropojují dvě sítě se stejnou adresou.
Ano, věřím, že mohou existovat obskurní nasazení, kdy to takto někdo provede, ale není to správně.
Pokud mají být nějaké sítě navzájem propojené, má mít každá jiný rozsah. Každé jiné řešení dříve nebo později přinese problémy.
Ale nebavíme se tady o klasické VPN, protože ta funguje jinak (s VPN serverem navazují spojení přímo koncové počítače a dostávají IP adresy z rozsahu, poskytovaného samotnou VPN). Tohle je tunel (i když přes VPN), a proto by se měl jako tunel taky nastavovat.
-
Já si myslím, že tento požadavek je plně v režii klienta VPN, ne serveru. Nemůžete na serveru nastavit napevno směrování a to pushnout do klienta. Co kdyby (a to skoro jistě) byl další klient VPN a ten měl jiné LAN adresy, které se navíc mohou měnit. Tady se musí nastavit směrování na klientovi VPN té dané sítě. Na serveru budu něco nastavovat v případě, že chci do LAN servera - takový požadavek tu není.
-
Já si myslím, že tento požadavek je plně v režii klienta VPN, ne serveru. Nemůžete na serveru nastavit napevno směrování a to pushnout do klienta. Co kdyby (a to skoro jistě) byl další klient VPN a ten měl jiné LAN adresy, které se navíc mohou měnit. Tady se musí nastavit směrování na klientovi VPN té dané sítě. Na serveru budu něco nastavovat v případě, že chci do LAN servera - takový požadavek tu není.
V konfiguraci, kterou tazatel požaduje (tunel) těžko. O tom celou dobu mluvím. Kdyby to byla klasická VPN jen s klienty, pak máte pravdu. U tunelu je ale plně na správci, jaké sítě propojuje.
-
A to i v pripade NATu, o ktery mi jde? Ja si za klientem muzu schovat kolik chci těch hloupych pc, stekne jako se to deje s providerem. Takze kdo ovlada toho klienta, muze se dostat do vpn z kolika pc chce, to je princip maskarady. Mozna to nechapu ja, co tim myslis, a mozna taky mluvime o stejne veci.
-
Tady vůbec nejde o NAT. O tom, co se s pakety, poslanými do VPN nebo do tunelu, nakonec stane, rozhodne VŽDY VPN server. Mění se jen způsob, jakým na něj doputují.
V případě VPN, jak se běžně rozumí (bridgované rozhraní TAP) se klienti spojí se serverem, ten jim přidělí IP z VPN rozsahu a stane se jejich defaultní branou. Pak veškerý provoz teče z klienta přes VPN na server a ten směruje provoz podle vlastní konfigurace. Dá se nastavit split, kdy pouze nakonfigurovaný provoz teče přes VPN a ostatní standardní cestou přímo do Internetu.
V případě tunelu (routované rozhraní TUN), který si představte jako trubku, nataženou mezi dvěma routery, kterou tečou zašifrovaná data, neexistuje žádný klient a server, jen první a druhý konec. Počítače v LANkách na jedné i druhé straně vůbec nezajímá, kudy data potečou, o tom rozhodují konce tunelu (routery) podle svých konfigurací a počítače normálně komunikují přes svou výchozí bránu, aniž by měly ponětí o nějakém tunelu. Pokud zrovna požadují spojení do sítě na druhém konci tunelu, router na jejich straně to podle své routovací tabulky pošle přes tunel na druhou stranu a router na druhé straně to podle své routovací tabulky dále zpracuje. Tady k žádnému NATování nedochází.
Z logiky věci vyplývá, že to, co chce tazatel zprovoznit, není klientská VPN, ale tunel (propojení dvou sítí). Není podstatné, kam provoz směřuje, jestli jen na druhý konec trubky (tzn. na server), nebo dále (do LAN za ní). Princip zůstává stejný.
V tomto vláknu dochází ke zmatení pojmů díky tomu, že se k vytvoření tunelu používá něco, co má v názvu VPN. Ano, OpenVPN umí postavit šifrovaný tunel pomocí TUN rozhraní. A taky se to pak jako tunel chová, a proto aby to fungovalo jak má, musí se to jako tunel nakonfigurovat. Tzn. je potřeba si uvědomit, že server jako IP, ze které pakety putují do cíle, nevidí IP z VPN rozsahu, ale IP adresu z LAN rozsahu. Takže pokud tazateli neodpovídá server na ping, pravděpodobně nastavil špatně pravidla firewallu a díky zmatení pojmů povolil provoz z VPN rozsahu, nikoliv z IP adresy routeru (192.168.80.1 nebo jakou má nastavenu, to není z dotazu patrné). Ty IP z VPN rozsahu v tomto případě slouží jen k sestavení tunelu.
Aby se dostal ze své LAN přes VPN tunel na server, musí:
- na svém routeru mít routu do sítě na druhé straně přes TUN rozhraní
- na vzdáleném routeru (serveru) mít na firewallu povolen příslušný provoz z LAN IP svého routeru
Aby se dostal ještě dále (do LAN za vzdáleným routerem), musí:
- na vzdáleném routeru nastavit maškarádu pro svou LAN síť
- na počítači ve vzdálené LAN, kam se chce dostat, povolit na firewallu příslušný provoz z LAN IP serveru
Cokoliv další je zbytečné a kontraproduktivní.
-
A hlavně: snažit se přistupovat na LAN IP serveru, ne na IP z VPN rozsahu, viz výše.
-
...
Aby se dostal ze své LAN přes VPN tunel na server, musí:
- na svém routeru mít routu do sítě na druhé straně přes TUN rozhraní
- na vzdáleném routeru (serveru) mít na firewallu povolen příslušný provoz z LAN IP svého routeru
Aby se dostal ještě dále (do LAN za vzdáleným routerem), musí:
- na vzdáleném routeru nastavit maškarádu pro svou LAN síť
- na počítači ve vzdálené LAN, kam se chce dostat, povolit na firewallu příslušný provoz z LAN IP serveru
Cokoliv další je zbytečné a kontraproduktivní.
Aby se dostal ze své LAN přes VPN tunel na server, musí:
- udělat NAT, který je přesně pro tyhle situace, pak nemusí nic povolovat na serveru, čisté řešení IMHO
- nebo nastavit pevnou routu ať už na adresy VPN, nebo LAN. Co když ale bude druhý klient s jiným rozsahem? Pak by musel dát na server další adresu.
Aby se dostal ještě dále (do LAN za vzdáleným routerem), musí:
nastavit na serveru push "route $rozsah_lan_serveru maska" a samozřejmě povolit. Mimochodem toto je také řešení problému, pak se bude tázat na LAN adresu serveru a nemusí se nastavovat NAT Tohle jsem ale moc nezkoušel.
Je jedno, jestli je to tunel routovaný, switchovaný, nebo zaplavený. Důležité je, aby klient uměl zpracovat požadavek z LAN do VPN. Já to vyzkouším, jen potřebuju někde zprovoznit ten hloupý pc za klientem
-
Vy pořád chcete konfigurovat VPN klienta, ale on má tunel. Mícháte jabka s hruškami a ještě jen v teoretické rovině. Já jsem napsal funkční, čistý a v praxi ověřený postup.
Tim končím svou účast v této nyní již zbytečné debatě.
-
Ja som sa teraz z toho vsetkeho sam zamotal. Tak som sa rozhodol, ze to radsej nakreslim aj s popisom.
Cesta je nasledovna OpenVPN server -- mikrotik -- Internet -- OpenWRT -- Hlupy Stroj.
Mirotik v tom nehraje velku rolu (resp. na mikrotiku je vsetko nastavene).
Vobec ho nebolo potrebne kreslit, ale kedze je tam, tak som ho nakreslil.
Ja sa potrebujem dostat z hlupim strojom (s IP 192.168.80.100) na Openvpn server (10.8.0.1).
Pozor !!!!
Nepotrebujem sa dostat zo strojom 192.168.80.100 dalej. Cesta konci na 10.8.0.1 (cize ip_forward na openvpn servery nepotrebujem, je vypnuty).
To je vlastne vsetko. Neviem ci je to bezne, alebo nie. Ale mne sa skor zda, ze konfigurovat by sa mal openwrt router.
Hlupy stroj sa neda konfigurovat vobec a OpenVPN server je nakonfigurovany tak, ze s openvpn klientom na openwrt sa spoji, cize tam by som tiez nejake zmeny konfiguracie vylucil.
Jedine kde sa musia robit nejaky zmeny mi vychadza len openwrt (ci uz routy, maskarady, naty ..... to neviem a na to sa vlastne pytam)
-
Pokud je OpenVPN nakonfigurována s TUN rozhraním, chcete se dostat na IP 192.168.1.100, ne na 10.8.0.1.
U tunelu adresy 10.8.0.x slouží jen k jeho navázání. Na WRT potřebujete jen routu do sítě 192.168.1.0 přes TUN.
Kdybyste místo OpenVPN použil raději IPsec a tunel navazoval už s Mikrotikem, bylo by to celé mnohem jednodušší.
-
Mimochodem, hodně vám pomůže traceroute.
-
Vy pořád chcete konfigurovat VPN klienta, ale on má tunel. Mícháte jabka s hruškami a ještě jen v teoretické rovině. Já jsem napsal funkční, čistý a v praxi ověřený postup.
Tim končím svou účast v této nyní již zbytečné debatě.
Tak jsem udělal z jablek a hrušek praktický kompot a funguje skvěle.
Server openvpn na TUN. Klient nainstalovaný sice v lokální síti, ale zakázaná komunikace z KVM, kde běží jakoby ten hloupý PC přes NAT. Také bez VPN nic nepingnu, s VPN bez problémů až na server na ip vpn, je tam maškaráda automaticky na virtuálním rozhraní. Takže otázka:
Proč mi to funguje? Já běžně přistupuji na server přes jeho VPN adresu při TUN rozhraní. Pokud nechci dál do jeho LAN a to nechci.
-
Pokud je OpenVPN nakonfigurována s TUN rozhraním, chcete se dostat na IP 192.168.1.100, ne na 10.8.0.1.
U tunelu adresy 10.8.0.x slouží jen k jeho navázání. Na WRT potřebujete jen routu do sítě 192.168.1.0 přes TUN.
Kdybyste místo OpenVPN použil raději IPsec a tunel navazoval už s Mikrotikem, bylo by to celé mnohem jednodušší.
No da sa povedat, ze ano. Ja to beriem tak, ze 192.168.1.100 je vlastne 10.8.0.1 (z pohladu hlupeho stroja), cize ANO potrebujem sa dostat na 192.168.1.100.
Ak by som bol v LAN sieti, kde je OpenVPN server a chcel by som komunikovat z 192.168.1.100, tak samozrejme pouzijem jeho realnu IP adresu. Ale kedze hlupy stroj je za horami za dolami, tak musim k tomu stroju pristupovat cez 10.8.0.1.
Uz sa opakujem. Ale ako to mam poriesit, potrebujem vytvorit v openwrt medzi lan a tun, alebo routu, alebo ... ?
-
Pokud je OpenVPN nakonfigurována s TUN rozhraním, chcete se dostat na IP 192.168.1.100, ne na 10.8.0.1.
U tunelu adresy 10.8.0.x slouží jen k jeho navázání. Na WRT potřebujete jen routu do sítě 192.168.1.0 přes TUN.
Kdybyste místo OpenVPN použil raději IPsec a tunel navazoval už s Mikrotikem, bylo by to celé mnohem jednodušší.
No da sa povedat, ze ano. Ja to beriem tak, ze 192.168.1.100 je vlastne 10.8.0.1 (z pohladu hlupeho stroja), cize ANO potrebujem sa dostat na 192.168.1.100.
Ak by som bol v LAN sieti, kde je OpenVPN server a chcel by som komunikovat z 192.168.1.100, tak samozrejme pouzijem jeho realnu IP adresu. Ale kedze hlupy stroj je za horami za dolami, tak musim k tomu stroju pristupovat cez 10.8.0.1.
Uz sa opakujem. Ale ako to mam poriesit, potrebujem vytvorit v openwrt medzi lan a tun, alebo routu, alebo ... ?
Už fakt nevím, jak to napsat, abyste to pochopil...
Ne, vy nechcete přistupovat na adresu 10.8.0.1, vy chcete přistupovat na adresu 192.168.1.100. Právě ten tunel vám toto umožňuje. To je to míchání jablek s hruškami, o kterém jsem psal. Vy nemáte klasickou bridgovanou VPN, kdy vzniká síť se samostatným IP rozsahem, který přiděluje VPN. Vy máte tunel, tzn. propojujete dvě vzdálené sítě. Tudíž chcete přistupovat na reálnou LAN IP adresu toho vzdáleného serveru. Na ty z rozsahu 10.8.0.X zapomeňte, ty slouží jen k navázání tunelu. Kdybyste tunel začínal už na Mikrotiku a použil IPsec, tak ho navazujete dokonce na veřejných IP adresách, ale taky byste přistupoval na LAN adresu. Proto jsem psal: pokud máte OpenVPN nakonfigurovánu na TUN rozhraní, které je ROUTOVANÉ, tak musíte přistupovat na tu 192.168.1.100 a aby to fungovalo, je třeba podle toho nastavit na serveru firewall.
-
Vy pořád chcete konfigurovat VPN klienta, ale on má tunel. Mícháte jabka s hruškami a ještě jen v teoretické rovině. Já jsem napsal funkční, čistý a v praxi ověřený postup.
Tim končím svou účast v této nyní již zbytečné debatě.
Tak jsem udělal z jablek a hrušek praktický kompot a funguje skvěle.
Server openvpn na TUN. Klient nainstalovaný sice v lokální síti, ale zakázaná komunikace z KVM, kde běží jakoby ten hloupý PC přes NAT. Také bez VPN nic nepingnu, s VPN bez problémů až na server na ip vpn, je tam maškaráda automaticky na virtuálním rozhraní. Takže otázka:
Proč mi to funguje? Já běžně přistupuji na server přes jeho VPN adresu při TUN rozhraní. Pokud nechci dál do jeho LAN a to nechci.
Ale já jsem přece nikdy netvrdil, že vám to nebude fungovat. Na světě určitě existuje spousta lidí, kteří se dokáží poškrábat levou nohou za pravým uchem a připadá jim to jako skvělý nápad. Klidně se plácejte po rameni, jak jste to vymyslel, ale to budete dělat jen do chvíle, kdy se to začne chovat nepředvídatelně, nebo kdy k tomu přijdete po 5 letech (vy, nebo nedejbože někdo jiný) a budete se divit, proč to funguje tak divně napůl a ne tak, jak by člověk z logiky věci předpokládal. Ne nadarmo máme nějaké best practices, aby se věci dělay tak, jak mají, místo aby se bastlily.
-
Bože, to je furt dokola.
Hloupý stroj zná jen svou adresu 192.168.80.100/24 a bránu 192.168.80.1, kterou má použít pro cokoliv mimo svou síť. To asi funguje.
Adresa 192.168.80.1 patří WRT a WRT je připojeno mj. k síti 10.8.0.0/24. WRT musí umět a mít povolený forwarding (aspoň) mezi sítěmi 192.168.80.0/24 a 10.8.0.0/24. To snad taky funguje.
Takže pravděpodobně funguje i putování paketu z hloupého stroje (192.168.80.100) do serveru VPN (10.8.0.1) (přes WRT 192.168.80.1 a 10.8.0.140). Řeší se problém s navrácením odpovědi, komunikace bez zpátečního paketu vypadá jako kompletně nefunkční. Řešení se nabízejí 2:
1) Do WRT přidáš maškarádu pro pakety směřující do VPN.
2) Do serveru VPN přidáš směrování paketů 192.168.80.0/24 přes bránu 10.8.0.140.
-
https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Site_to_Site_IPsec_tunnel
Princip je naprosto stejný, u vás ty VPN adresy 10.8.0.X jen nahrazují veřejné IP adresy a jinak vás nemusí zajímat.
-
Ale já jsem přece nikdy netvrdil, že vám to nebude fungovat. Na světě určitě existuje spousta lidí, kteří se dokáží poškrábat levou nohou za pravým uchem a připadá jim to jako skvělý nápad. Klidně se plácejte po rameni, jak jste to vymyslel, ale to budete dělat jen do chvíle, kdy se to začne chovat nepředvídatelně, nebo kdy k tomu přijdete po 5 letech (vy, nebo nedejbože někdo jiný) a budete se divit, proč to funguje tak divně napůl a ne tak, jak by člověk z logiky věci předpokládal. Ne nadarmo máme nějaké best practices, aby se věci dělay tak, jak mají, místo aby se bastlily.
Ale radíte někomu, kdo si ve volném čase hraje a zkouší něco nového. Nejste ve firmě, kde to musí běžet na první našlápnutí bez chyby. Já když něco zkouším, mám obrovskou radost, když to začne fungovat a pak na to vymýšlím best practice. Sice jste tu perfektně popsal rozdíl mezi TUN/TAP a dal příklady na ipsec a shorewall, ale jaksi mu to moc nepomohlo. Já dám příklad na iptables a openvpn.
Takže na serveru musí být toto:
dle best-praktice push "route $rozsah_lan_serveru maska" - to řeší přístup na reálnou IP serveru. Na klientu pak bude v konfigu pullNa server ještě možná topology subnet, ale mě to funguje i na default
Pak na serveru v iptables (záleží na výchozích politikách) povolit nejlépe vše (INPUT z eth a tun, OUTPUT, FORWARD tun a eth) to není dle best practices, ale důležité je to rozběhat. Ideálně dát pravidla jako první. To je na serveru vše, tak to mám já a přistupuju i do LAN za serverem.
Na klientu je potřeba jen v konfigu pull (viz výše), v iptables jen nat, tam máte politiky na acceptiptables -t nat -A POSTROUTING -o $VPN -j MASQUERADEPokud toto nebude fungovat budeme hledat dál. Tohle řeší jak přístup na server pod LAN adresou, tak směrování na obou stranách.
No a nebo se na to vyprdněte, přejděte na ipsec a shorewall, nebo si najměte odborníka, který "tomu rozumí". Je to tak správně?
-
Já jsem popsal obecný postup, jak zprovoznit to, co tazatel požaduje, jestli provoz šifruje IPsec nebo OpenVPN nehraje roli. Snažil jsem se vysvětlit, jak tunel, který si postavil, funguje. Že musí přistupovat na vzdálenou LAN IP a bude to fungovat jak potřebuje. On to měl od začátku téměř správně, jen k tomu přistupoval logikou client to server místo site to site. Nefunguje mu to asi proto, že ten můj postup ani nevyzkoušel.
Jinak já vám neberu váš entuziasmus, testovat si to každý může jak je mu libo, ale když někomu chci pomoci, nebudu mu přece radit řešení, o kterém sám nejsem přesvědčen nebo vím, že funguje jen na půl. Víc k tomu nemám co dodat.
-
Vysledok sa dostavil a davam sem postup:
Samozrejme openvpn a openssl musi byt nainstalovane a nastaveny openvpn klient
opkg update
opkg install openvpn-opensslNerobil som to cez terminal, ale v luci
network -- interfaces -- add new interfaceName of the new interface - tun0
Protocol of the new interface - static address
Cover the following interface - Ethernet Adapter: "tun0"
submitHlavna konfiguracia pre interface tun0
v General setup
IPv4 adress 10.8.0.140
Netmask 255.255.255.0Na ostatnych kartach sa nemusi uz nic nastavovat
save and applyFirewall
network -- firewall -- add
Name tun0
input, output, forward som nastavil na accept
Masquerading -- yes
Covered networks -- tun0a v casti Inter-Zone Forwarding
Allow forward to destination zones: lan
Allow forward from source zones: lan
save applyPo tychto nastaveniach bezi vsetko tak ako som chcel.
Na openvpn servery sa nic nemusi nastavovat.
Dakujem vsetkym zucastnenim za podporu a cenne rady