Připojení k OpenVPN přes klienta

[TKL]

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):

Kód: [Vybrat]

# 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é.

[Reklama]

[TKL]

Ještě jsem zapomněl připsat k výpisu IPtables maškarádu:

Kód: [Vybrat]

MASQUERADE  all  --  192.168.80.0/24      anywhere            policy match dir out pol none


[sito]

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...

[uf]

Áááá ... 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.

[TKL]

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.

[Reklama]

[uf]

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?

[TKL]

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.

[Karlosek]

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í.

[TKL]

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.

[Karlosek]

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.

[TKL]

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í.

[TKL]

A hlavně: snažit se přistupovat na LAN IP serveru, ne na IP z VPN rozsahu, viz výše.

[Karlosek]

...
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

[TKL]

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ě.

[darebacik]

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)