Dotaz: Propojeni vice VPN siti

[Tom]

Dobry den,

chtel bych ze zeptar, respektive pozadat o doporuceni, jak nejvhodneni nakonfigurovat nasledujici situaci:

Mam jednu hlavni LocalLAN (192.168.1.0/24) s verejnou IP, a dale mam nekolik RemoteLAN (10.1.X.0/24), ktere jsou k internetu pripojeny pres ADSL (O2) Potreboval bych se z LocalLAN naprimo pripojovat na jakykoliv pocitac v jakekoliv RemoteLAN.

Rozsahy v RemoteLAN jsou vzdy 10.1.X.0/24, kde X by identifikovalo tu konkretni RemoteLAN.

Takze:

RemoteLAN1:
10.1.1.1 - router
10.1.1.2 - PC1
10.1.1.3 - PC2

RemoteLAN2:
10.1.2.1 - router
10.1.2.2 - PC1
10.1.2.3 - PC2

atd....

Tech RemoteLAN by ale melo byt vice, klidne 10-20 (teoreticky klidne 254), do kazde muzu pridat OpenWRT router, ktery by mohl fungovat jako VPN klient.

Jak na to? Nasel jsem zatim navody na Site-to-Site OpenVPN. Je to to co potrebuji?

Muzete me prosim nasmerovat, jak se toto resi "spravne"? Co bych mel nastudovat?

Dekuji

Tom

Odpovědi

[Sten]

Site-to-site VPN je jednoduchá, stačí na routerech rozjet point-to-point VPN (OpenVPN tun), nasměrovat rozsah druhé strany do správného tunelu (pomocí konfigurační volby iproute) a vše bude fungovat.

[Michal]

Urcite potrebujes site-to-site VPN, nejlepe OpenVPN.

Otazka je jak nakonfigurovat ty vzdalene site. Jelikoz jich je tolik tak bych se skoro priklanel k zneuziti OpenVPN tls-server / tls-client namisto pro site-to-site obvyklejsi "shared secret" konfigurace. Budes mit jeden spolecny CA certifikat a pro kazdy router tim podepises jeho vlastni SSL certifikat. Tim padem se routery s platnym certifikatem budou moct pripojit na server.

Dalsi problem je routovani do tech vzdalenych siti. V klasickem site-to-site ma kazda strana seznam rozsahu te protistrany v OpenVPN konfiguraku, ale s tls-server/tls-klient to tak primocare neni, takze budes muset na serveru pouzit "client-config-dir" a v tom hlavne volbu "iroute" (oboji viz manpage pro openvpn). Pripadne nejake dynamicke routovani (OSPF) ale to je az dalsi level.

Drzim palce ;)

[Max]

Zajímalo by mně, proč se tu doporučuje OpenVPN a né standardní IPSEC? Jaký to má oproti IPSECu přínos, který nevidím?
Zdar Max

[NN]

Asi zadny, ale je to snazsi na konfiguraci. Ja s IPSekem problem nemam, ale ne kazdy bezny spravce vi co je SA, Phase 2 etc.

[Michal]

Protože OpenVPN "just works" zatímco IPsec "just sucks".

Tak třeba:

- v Linuxu se IPsec tunel netváří jako network interface, což značně komplikuje spoustu věcí - provoz routovacích daemonů, nastavení firewallu, tcpdump, ... OpenVPN prostě vytvoří tun0 a s ním si můžu dělat co chci stejně jako s každým jiným interfacem a vidím v něm jen vnitřní provoz toho tunelu.

- u IPsec je potřeba na obou stranách nastavit stejné parametry spojení, což je někdy netriviální zařídit. OpenVPN si to mezi sebou obě strany domluví samy.

- IPsec tunel je potřeba konfigurovat zvlášť pro IPv4 a IPv6, OpenVPN tunel může přenášet oba protokoly.

- za jedním NATem může být jen jeden IPsec client protože IPsec NAT-traversal mode má o fungování běžných NATů dost zkreslené představy. OpenVPN přes NAT funguje jako každé jiné TCP nebo UDP spojení.

- na druhou stranu OpenVPN nejede proti "profesionálním" VPN bránám (Cisco, F5, ...). Tam je třeba použít IPsec ale je s tím vždycky víc sraní než je nutné. Už třeba kvůli rozdílné terminologii různých výrobců.

Podle mě IPsec vymysleli někde na akademické půdě páni teoretici a zahrnuli tam řešení mnoha neexistujících problémů, čímž to celé mega zkomplikovali, a bohužel se jim to povedlo protlačit jako standard.

Zatímco OpenVPN vymyslel někdo z praxe na pragmatické vyřešení VPN a povedlo se mu to na jedničku.

[Michal Kubeček]

Silně mi to připomíná litanie lidí, kteří jsou zvyklí na Windows (které jim "just work"), o Linuxu nic nevědí a dozvědět se nechtějí, ale mají naprosto jasno v tom, že "just sucks", protože se chová jinak než ty Windows, na které jsou zvyklí.

[Peter Golis]

Windows just work, kde?

To neplatí ani pri počítači zakúpenom s predinštalovaným Windows. Pribalený bloatware ten Windows znefunkčňuje.

[Michal Kubeček]

Zkuste si to přečíst pořádně. Netvrdil jsem, že to tak skutečně je, jen že takové věci někteří lidé píší.

[Peter Golis]

Kde také veci kto píše? Rád by som sa pozrel či sa náhodou nejedná o vyjadrenia PR firmy Microsoft.

[Max]

Trochu mysli, než něco napíšeš. Je naprosto evidentní, co tím autor chtěl říci a řekl. Vzhledem k tvé reakci jsi to nepochopil, tak se nad tím znovu trochu zamysli.
Zdar Max

[Peter Golis]

Pýtal som sa kde k tomu prišiel, a odpoveďou mi je že tomu nerozumiem. Tomu sa hovorí trefná odpoveď, ale žiaľ na nevyslovenú otázku.

Nepracuješ náhodou ako konzultant vo firme Microsoft?

[Max]

Tvá otázka je úplně mimo mísu a úplně irelevantní. Navíc byla zodpovězena hned při vyřknutí (říkají to lidé s windows, kteří neznají linuch, pokud s tím máš problém, neventiluj ho na linux foru, ale jdi si počíst na win forum).
Zdar Max

[Peter Golis]

Pýtal som sa kde, a to reálne nebolo zodpovedané.

A ohľadom linuchu, znie to ako eunuch. Je ten výraz z PR príručky MS rovnako ako tvrdenie "Windows just work"? S tým sa naozaj ventiluj v práci.

[Max]

O co ti vlastně ve skutečnosti jde? Můžeš něco dodat k tématu, nebo se jen toužíš bavit o ničem?
Zdar Max
PS: linuch je naprosto běžný výraz (asi CZ/SK výroby, nevím, stejně jako nevím, kde jsi přišel k té MS úchylce)

[Peter Golis]

Pokiaľ nedokážeš identifikovať alebo pochopiť jednoduchú otázku, a stále strielaš naučené frázy z PR príručky, tak som sa trafil. Žiaľ.

PS: Móda nahradzovania písmena x písmenom ch nie je CZ/SK výroby, ale jedná sa o pubertálny h4x0r speak. Ale to je škoda rozoberať s človekom ktorý spomína linuch na linuxovom fóre.

[Max]

Z tvého komentáře mám pocit, že máš zkušenosti jen s klientským řešením pro uživatele, né jako řešení na propojení dvou sítí (poboček) mezi sebou.
Osobně utíkám od OpenVPN a začínám nasazovat místo něj IPSEC i pro klienty (lidi s tabletem, notebookem apod.). Teď jen dolaďuji drobné věci, abych mohl dopsat dva díly k článku a pak to vydám.
To, že píšeš nepravdy (více IPSEC klientů za stejným natem není problém, funguje to jak fík) znamená, že do toho evidentně zas tak moc nevidíš.
Jinak IPSEC na propojení poboček používáme hafec let a bez problémů (dokonce jsem s jednou firmou provozoval NAT over IPSEC - měli jsme shodné segmenty na obou stranách a plně ok, i na rozdílným sw). To se o OpenVPN ale nedá moc říci.

Každopádně z tvého komentáře je cítit něco jako "IPSEC neznám, přijde mi složitý a hloupý, OpenVPN rulez"
Zdar Max

[vandrovnik]

Na články se těším - zatím používám všude OpenVPN, tak třeba si konečně troufnu se posunout

[bigBRAMBOR]

IPSec mezi pobočkami ok, ale kdyz jsme jeste meli data od O2 (uz to je pár let), nemohli se klienti připojit(L2TP/IPsec), na standardním datovém tarifu neprošlo AH a ESP (pokud se jim dokoupila veřejná IP šlo to). OVPN jde protlačit prakticku všude, dost často třeba přes port UPD/53 na sítích kde je provoz placený.

zkoušel nekdo softether? přijde mi zajímavé mít jeden server a moc se za stejných podmínek možnost připojit asi 4 různejma klientama.

[Max]

L2TP over IPSEc mám rozjetý také. Mám server za NATem a kvůli tomu jsem musel použít linux a zapomenout na freebsd. Funguje mi i komunikace klient NAT - NAT server, funguje mi i více klientů za stejným NATem. Funguje to na Androidu, Linuxu, iPhone i Windows (u win je potřeba v registrech zapnout ignorování checksumů).
Právě kvůli problému s checksumama u L2TP provozu člověk nemůže použít FreeBSD (pfSense), protože by default jeho kernel toto neumožňujě a patche existují pro starší kernely.
To byl jeden z důvodů, proč jsem nakonec nasadil IKEv2, který je spolehlivější a má lepší fci na udržení spojení / reconnect apod. (MOBIKE atd.)
Další věcí je, že doba limitů celkem pominula, takže v dnešní době není problém IPSEC nasadit, jako tomu bylo v době minulé.
Další věcí je, že do IPSECu probublává podpora kolem TNC (Trusted Network Control) a tím příprava na větší nasazení BYOD zařízení.

Pokud jde o softether, tak ten jsem po zběžném shlédnutí zavrhnul. Tváří se všemocně, ale není to tak. Pro Win podporuje třeba jen L2TP over IPSEc (už jsme si výše řekli, kde je s ním problém), nebo SSTP (moc neznám).
Donedávna byla podpora managementu jen z windows, teď přibyl i MAC OSX.
Teprve koncem minulého roku přibyla podpora TLS 1.2.
Celý projekt mi přijde ještě relativně mladý a ve vývoji.
Výhodou IKEv2 je, že je podpora ve všem a v některých zařízeních nabízí právě možnost ověření, zda je klient aktuální, má AV apod. věci, nebo mít víceúrovňové ověřování
Zdar Max

[pavlix]

Protože OpenVPN "just works" zatímco IPsec "just sucks".

No nevím, mně přijde IPsec na Linuxu daleko jednodušší na správu než OpenVPN, navíc se využijí všechny výhody kernelové implementace. Ale jako chápu, že samotný standard je trochu komplikovanější a hůže se adaptuje na dnešní svět zkripleného internetu, ve kterém je nejvyšším dosažitelným ideálem posílat všechno včetně TCP přes 443/TCP stream, protože to proleze všude. :D

[Karlík]

"Podle mě IPsec vymysleli někde na akademické půdě páni teoretici ..."

Zdaleka ne, koukněte se do příslušných RFC (a je jich pěkná řada, viz odkaz). Uvidíte tam Naval Research Laboratory, Trusted Information Systems, zaniklé firmy Piermont Information Systems a Daydreamer, Qualcomm, Cisco, NIST, BBN, Airespace a řadu dalších. Slyšel jsem ale pomluvu, že se na návrhu angažovala NSA. Ta se obávala, že lidu do rukou šifrování nepatří, ale vývoj zarazit nemohla, když jej finančně podporovala Clintonova nadace. Tak aspoň výsledek učinili uživatelsky/administrátorsky co nejnepřítulnější.

https://en.wikipedia.org/wiki/IPsec

[Michal Kubeček]

Nebude náhodou jednodušší vysvětlení to, že IPsec vznikal v době, kdy maškarády ještě nebyly zdaleka tak rozlezlé a nikoho nenapadlo, že jejich rozšíření nabude dnešních rozměrů? V té době na aktuální potřeby celkem pohodlně stačil CIDR a počítalo se s tím, že v dlouhodobějším horizontu problém nedostatečné velikosti adresního rozdahu IPv4 vyřeší IPv6. Autoři (a nejen oni) holt podcenili míru pasivní rezistence vůči IPv6 od velkých hráčů na trhu.

[frr]

Tento názor plně sdílím. Za posledních asi 20 let mám s IPSecem několik zkušeností, které končívaly flintou do žita po 2-3 dnech tápání v tmách "jaktože to sakra nechodí, nebo nevysvětlitelně hnije, když je to všecko správně nakonfigurované". S jednou výjimkou: kdysi dávno, Cisco proti Ciscu, konkrétní vyselektovaný release IOSu, GRE tunely zvenčí zabalené do IPSecu.

S OpenVPN většinou tak půlden studia konfigurace pro konkrétní scénář, a nakonec to chodí/chodilo. Na routing mezi pobočkami nad OpenVPN tunely jsem svého času použil nikoli OSPF, ale BGP. Chodilo to prostě líp - na trasách, kde end-to-end "detekce linku" nebyla spolehlivá, popř. nefungovala vůbec.

Nicméně je pravda, že jsem si v IPSecu zatím neosahal IKE v2 a už delší dobu jsem mu nevěnoval pár dní svého času. Možná se karta přece jenom obrací. Nechtěl bych ustrnout na starých zkušenostech, které třeba už tak docela neplatí.

[Michal Kubeček]

S OpenVPN většinou tak půlden studia konfigurace pro konkrétní scénář, a nakonec to chodí/chodilo.

Aspoň do chvíle, než se podíváte, jak to vlastně chodí. Třeba když se začnete zajímat o to, proč se čas od času všem na chvíli pozdrží veškeré pakety, a zjistíte, že je to tím, že openvpn dělá všechno v jednom threadu, takže zatímco čeká na autentizaci proti LDAPu, všechen provoz musí počkat. Tenhle konkrétní problém s autentizací je sice teď už opravený, ale primární problém přetrvává, takže při větším počtu uživatelů nejsou latence a hlavně jitter žádná sláva.

[frr]

Pravda je, že já jsem vždycky mohl spočítat pevné pobočky na prstech jedné ruky a cestující klienty řekněme na prstech všech čtyř chapadel. A měl jsem zvlášť instanci pro "cestující klienty" a zvlášť další dvě instance pro "páteřní" VPN tunely. Váš komentář je asi nejobsažnější co do informací ohledně OpenVPN, co jsem tady v podobných debatách zatím zaznamenal - děkuji

[pavlix]

Nevím. Nastavil jsem Strongswan na jedné straně, nakopíroval konfiguraci na druhou, spustil a jelo to. Pravda je, že mě vůbec nenapadlo se zabývat čímkoli jiným než IKEv2.

[frr]

A navíc jste měl ten luxus, že jste si mohl zvolit konkrétní implementaci v konkrétní verzi, a použít ji na obou koncích. Já měl většinou za úkol rozjet proti sobě dvě různé implementace, sice nepochybně obě open-source původu, ale "zapečené" v nějakém black-box firmwaru, do kterého jsem nemohl sahat.

[pavlix]

Ano. Na tom se nejlépe otestuje technologie samotná bez vlivu toho, co za bullshit si kdo vymyslel.

[frr]

Tohle je možná jádro pudla. Já mám skoro vždycky shůry dáno heterogenní prostředí = různé OS platformy. Takže pak sjednocujícím prvkem je OpenVPN. A kouzelné na ní je právě to, že OpenVPN service funguje navzájem proti sobě mezi různými OS platformami a dokonce mezi různými verzemi OpenVPN, pokud nešponujete vývojově nové fičury.

Jistě máte na jazyku odpověď, že IPSec je taky "jenom jeden", že to je přeci standard, a případné vzájemné nefunkčnosti jsou otázka pečlivého vzájemného testování a release engineeringu jednotlivých různých implementací...

[pavlix]

strongSwan

the OpenSource IPsec-based VPN Solution

runs on Linux 2.6, 3.x and 4.x kernels, Android, FreeBSD, OS X and Windows

Tady nevnímám od OpenVPN zase až takový rozdíl.

[frr]

Tak jo Až budu příště stavět "otevřenou" VPN, tzn. budu mít možnost zvolit si software na obou koncích, zamyslím se nad IPsecem. Díky za všechny informace.

[Max]

Mno,
ještě jsem snad neměl problém s IPSECem vůči různým implementacím. Ale je pravda, že jsem toho zas tak moc nezkoušel. Asi jen tyto kombinace (ikev1):
ZyWALL vs Mikrotik
ZyWALL vs ZyWALL
ZyWALL vs Astaro (i v režimu NAT over IPSEC)

a ikev2 (i ikev1 + L2TP):
windows 7,10 vs strongswan
iphone vs strongswan
android vs strongswan
Zdar Max

[Max]

Právě kvůli heterogennímu prostředí jsem byl nucen nasadit IPSEC. OpenVPN je jen pro pár platforem, IPSEC je implementován snad ve všem.
Zdar Max

[hydrandt]

Ja na tohle pouzivam tinc, respektive chaosvpn (dela management konfigurace pro tinc).

Ale openvpn/ipsec poslouzi stejne tak dobre. Vyhoda tinc je v tom, ze v siti neni centralni uzel.

[Petr Šobáň]

Píše že má O2 připojení přes ADSL tak nechápu kde je problém O2 Používá IPv6 takže každý PC za tím ADSL má veřejnou IPv6 na kterou se dá dostat.

Takže si akorát v firewalu povol patřičné porty a máš to....

PS. Jinak můj comtrend umí IPsec a viděl jsem to i u jiných adsl modemů takže proč to nepoužít.... (Já to nepoužívám používám IPv6 takže nevím jak mod je IPsec v comtrendu spolehlivý.)

[Tom]

Dobry den, omlouvam se ze reaguji az tak pozde (moc prace...)

Kazdopadne uz mi to funguje. Zvolil jsem OpenVPN, konfigurace byla nakonec opravdu jednoducha a dela to to co potrebuji. Poupravil jsem jiz bezici Client-Server konfiguraci, pridal client-config-dir s iroute, pro kazdy router vlastni certifikat a statiske routovani na hlavni gateway.

ad IPSEC) Urcite si rad prectu ten Maxuv planovany clanek, treba se to ukaze jako vhodnejsi. Zatim ale o IPSEC vim jenom to ze existuje... :)

ad O2 a IPv6) No, s tim jsem na tom momentalne podobne jako s IPSEC.... takze nula. Asi by to bylo i idealni, ale to me teprve ceka. Ale v IPv6 vidim jeden problem, ktery by mi hodne vadil - dost se mi hodi byt schopen vedet jakou IP ma jake zarizeni v dane vzdalene lokaci. S IPv4 je to idealni, s IPv6 si to moc nedovedu predstavit.

Diky vsem za rady i diskuzi.

Tom

[Tom]

Takze precijenom problem...

Kdyz se pripojim z jakehokoliv PC v lokalni LAN na jakykoliv pocitac v RemoteLAN pomoci SSH, tak se bez problemu pripojim, na vzdalenem PC muzu normalne pracovat, ale po cca 20-30 vterinach se spojeni "zasekne". Zadna hlaska v konzoli, proste prestane reagovat. Ping jede bez vypadku paketu

Kdyz se na stejny pocitac prihlasim primo z OVPN serveru, tak spojeni drzi bez problemu. Stejne tak spojeni z RemoteLAN -> Local LAN je v poradku, SSH drzi.

PC v LocalLAN: 172.17.128.0/23
OVPN Server 172.17.129.6
OVPN tunel 10.10.0.1 -> 10.10.0.240

PC v RemoteLAN: 10.128.240.0/24

Na hlavnim routeru v LocalLAN (pFsense) jsem pridal novou gateway (OVPN server 172.17.129.6) a staticke routovani pro 10.128.240.0/24 pres tuto novou gateway.

Toto mam v server.conf:

port 2194
proto udp
dev tun
sndbuf 0
rcvbuf 0
ca ca.crt
cert server.crt
key server.key
dh dh.pem
tls-auth ta.key 0
topology subnet
server 10.10.0.0 255.255.255.0
#ifconfig-pool-persist ipp.txt

client-to-client
client-config-dir /etc/openvpn/ccd

push "route 10.128.240.0 255.255.255.0"
push "route 172.17.128.0 255.255.254.0"

route 10.128.240.0 255.255.255.0 10.10.0.240

#push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 172.17.129.1"
push "dhcp-option DNS 172.17.128.15"
keepalive 10 120
cipher AES-128-CBC
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem

client CCD:

ifconfig-push 10.10.0.240 255.255.255.0
iroute 10.128.240.0 255.255.255.0
push "route 172.17.128.0 255.255.254.0 10.10.0.1"

Toto je client.conf

client
dev tun
proto udp
sndbuf 0
rcvbuf 0
remote x.x.x.x 2194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-128-CBC
comp-lzo
setenv opt block-outside-dns
key-direction 1
verb 3

Mate nekdo tuseni kde muze byt problem? Co hledat? Sledoval jsem logy ssh/sshd, ale tam je jenom uspesne prihlaseni, po tom "zaseknuti se" zadna chyba nezapise.

Tom.

[Max]

A není to problém ssh klienta? Zkus :

/etc/ssh/ssh_config
...
Host *
  ServerAliveInterval 240

Zdar Max

[Tom]

Dobry den, tak s drobnym zpozdenim, ale uz to funguje. Problem byl nakonec na hlavnim routeru (pfSense) ktery mel zapnute blokovani provozu ruznych subnetu na stejnem rozhrani. Ted uz to jede, spojeni se drzi bez problemu.

Ale ukazal se jeste jeden "problem" ktery bych pokudmozno rad vyresil. Chtel jsem vyzkouset jestli z te RemoteLan pujde PXE boot ze serveru v LocalLan. Nejde... Na tom TFTP serveru je v logu toto:

 RRQ from 172.17.129.6 filename pxelinux.0
 tftpd: read: Connection refused

To 172.17.129.6 je lokalni adresa VPN serveru. To je v poradku? Nemela by tam byt spis lokalni adresa toho vzdaleneho pocitace?

Pri konfigurovani toho OpenVPN serveru jsem iptables nastavil takto:

iptables -I INPUT -p udp --dport 3194 -j ACCEPT
iptables -I FORWARD -s 10.10.0.0/24 -j ACCEPT
iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -j SNAT --to 172.17.129.6

Jde nejak zaridit, aby se ty vzdalene pocitace hlasily svoji skutecnou adresou? Pomuze to tomu PXE? Nebo se to musi udelat uplne jinak?

Dekuji. Tom

[frr]

> Jde nejak zaridit, aby se ty vzdalene pocitace hlasily svoji skutecnou adresou?

Co třeba zrušit ten SNAT ?

Mimochodem... jak vypadá výsledná sada IPtables pravidel? Býval jsem zvyklý dávat spíš IPtables -A než IPtables -I (tady je to asi jedno, když včechny řádky mají -j ACCEPT). Taky nevidím, jakou má který chain "default policy".

Pokud je "connection refused" v logu přímo od tftpd démona, tak TFTP klienta poslal k šípku sám démon, nikoli iptables. Otázka je, co máte za tftpd. Pokud je omezení přístupu zařízeno přes standardní "wrapper", co máte v /etc/hosts.allow a hosts.deny ? Chodí Vám to PXE aspoň napřímo z lokálního subnetu kolem TFTP serveru?

[Andrej]

chtel bych ze zeptar, respektive pozadat o doporuceni, jak nejvhodneni nakonfigurovat nasledujici situaci: …

IPv6.

(O2 IPv6 poskytuje, takže tradiční výmluva na poskytovatele v tomto případě odpadá, a neexistuje žádný racionální důvod zabývat se v roce 2017 omezeními protokolu IPv4 z roku 1975.)

[Tom]

Ano, verim ze IPv6 by mi to asi par veci vyresilo, ale :

1. potrebuji byt schopen znat IP adresy tech vzdalenych zarizeni. Proste mi nekdo zavola ze neco nekomunikuje, tak at to muzu rovnou z telefonu treba aspon pingnout. U IPv4 nemam problem i kdyby tech zarizeni bylo treba 500. Ale jak "vydedukovat" IPv6 adresu jen tak z hlavy to netusim....
2. nekde mame zarizeni ktere IPv6 snad ani neumi....

Nevim jestli tohle jsou take tradicni vymluvy, ale pro toto pouziti mi prijde IPv4 v poradku.

S tim jak to ted funguje jsem v zasade spokojen. Kdyby zafungoval ten PXE boot a zobrazovani lokalni IP vzdaleneho zarizeni, tak by to byl prijemny bonus.

Jde toho nejak docilit pri teto konfiguraci OpenVPN? Mozna na to bude stacit nejak zmena treba v iptables, mozna to nepujde uz z principu... Nevim, proto se ptam a hledam nejakou radu.

Dekuji

Tom

[Josef Kufner]

Ale jak "vydedukovat" IPv6 adresu jen tak z hlavy to netusim....

Od toho máme DNS. Klidně můžeš zónový soubor generovat z nějaké databáze zákazníků, kde můžeš mít i fyzickou polohu zařízení (GPS souřadnice), komu patří a co tam zhruba běží. Z telefonu není problém se k takové databázi dostat přes triviální webové rozhranní, které si v PHP spíchneš za večer, a/nebo použiješ Adminer Editor. Vedle zónového souboru můžeš z toho generovat i GPX pro navigaci, až tam pojedeš. Při troše šikovnosti by se dal udělat i CardDAV export, že bys pak měl v mobilu u kontaktu na zákazníka i seznam jeho zařízení a rovnou odkazy na jejich administraci.

[Tom]

No, jako namet na dlouhe zimni vecery pekny.. Ne, vazne, to co popisujete by bylo moc hezky, ale je to mnohem, mnohem dal nez momentalne dokazu dohlednout.

Jestli dobre chapu ty navrhy na IPv6, tak bych vlastne vubec nemel resit VPN, ale vyuzit verejne dostupnosti tech lokalnich IPv6 adres?

To ale neni to jedine o co mi jde. Nejedna se o skutecne zakazniky, ale o nase vlastni pobocky, ktere bych chtel mit ve VPN, veskery provoz smerovat tim VPN tunelem. Pristup na ty pobocky chci opet pouze tim tunelem. Takze nejaka forma VPN stejne musi probehnout. Koukam ze OpenVPN umi IPv6, takze tudy by to asi slo, ale ... co to zarizeni, na kterem jde nastavit pouze IPv4? Jak se na nej pripojim? . Nebo dodavatel toho zarizeni kvuli monitoringu a administraci.  Tam to proste neprojde at je to problem technicky nebo uzivatelsky (ani bych se nedivil, kdyby tento dodavatel IPv6 odmitl jenom proto ze se mu nevejde do bunky v Excelu...) A ja s tim proste nemohu nic udelat.

Takze rozhodne dekuji za podnety, ale presto bych se rad vratil k te otazce, jak to vyresit pomoci IPv4 a OpenVPN. Jak rikam, momentalne to funguje tak jak potrebuji, kdybych dostal radu (nebo napovedu?) jak upravit konfiguraci tohto stavajiciho reseni aby zafungoval te PXE boot a zobrazovani lokalni IP vzdalenych zarizeni, tak bych byl rad. Nebo jsem prave narazil na omezeni IPv4 pres ktere nejede vlak?  IPv6 si opravdu musim odlozit na neurcito.

Dekuji.

Tom

[Josef Kufner]

Co popisuju bych udělal i kdyby to bylo jen na IPv4. Tak jako tak musíš vědět kde kdo co má a jak k tomu. Navíc určitě máš nějaký monitorovací nástroj, který by také mohl posloužit.

VPN bych si klidně udělal jednu servisní na nějaký dobře dostupný server (přes tu by nešel běžný provoz) a mezi pobočkami tahat tunely napřímo, pokud mají veřejné (a nejlépe i pevné) IP adresy. Celé to je jen o nastavení routování – taková pěkná rozcvička s čísílkama (VPN udělá tunel jako malý subnet a na obou stranách potřebuješ mít v síti správné routy; dev tun, topology subnet).

S PXE bootem mám takové mlhavé tušení, že je tam někde schované omezení na lokální segment sítě. Ale tahat to po VPN je stejně ptákovina, neboť pak bez VPN a přípojení k Internetu nebude fungovat vůbec nic. Dej do každé sítě lokální mirror.

[frr]

K tomu PXE mezi subnety: podle mého je potřeba vyřešit dvě věci:

1) pokud není v satelitní LANce její vlastní BOOTP/DHCP server, tak na routeru (OpenWRT?) nakonfigurovat aspoň DHCP relay na centrální server (patrně skrz VPN).

2) DHCP klienti v satelitní LANce musí skrz DHCP dostat správnou default gateway na svůj lokální router (OpenWRT?). Pokud tato satelitní LANka nemá svůj vlastní DHCP server, tzn. jede to z různých satelitních LAN skrz relay na společný centrální DHCP server, je potřeba rozlišit toto v "master" konfiguraci centrálního DHCP serveru. DHCP dotaz obsahuje myslím hned několik identifikátorů, na které by šlo pověsit rozlišení gatewaye, ze které dotaz přišel (a návaznou dodávku odpovídající konfigurace v odpovědi).

Jakmile dostane DHCP klient (PXE stack v BIOSu) správnou IP gateway, nemá už problém dobouchat se přes TFTP napříč mezi subnety (a skrz VPN) až někam do centrály na TFTP server, kde koupí pxelinux.0 a další potřebné věci.

[Tom]

Tak konecne uspech. Konfiguraci OpenVPN jsem ponechal beze zmeny, chtelo to jenom ubrat s iptables. Zrusil jsem ten SNAT na OpenVPN serveru, tim se vzdalene pocitace prestali hlasit IP adresou serveru ale IP adresou konkretniho tunelu. Pak jsem tedy zrusil jeste MASQUARADE na tom OpenWRT klientovi a konecne vidim puvodni IP kazdeho konkretniho stroje. Staticke routy jsem doplnil pouze na hlavnim routeru v LocalLAN. Spojeni mezi sitemi funguje obousmerne. Dokonce i ten PXE boot se rozbehl. Ten nemam na regulerni bootovani, ale spis jsem chtel ze site spoustet instalatory. PXE menu se mi zobrazi, vic jsem zatim nezkousel, ale predpokladam ze ted uz by to mohlo fungovat. To mne teprve ceka, snad to bude pouzitelne.

Ted uz resim jenom prenastaveni DNS na tom OpenWRT routeru po navazani vpn spojeni, ale to uz snad nejak vybojuju.

Tak jeste jednou diky vsem za rady a komentare.

Tom

[frr]

Ohledně PXE bootu: třeba u Debianu (a Ubuntu a spol) stačí na distribučním mirror serveru najít (naklikat) příslušný podadresář, z něj vzít soubory "linux" a "initrd.gz", a do /tftpboot/pxelinux.cfg/default přidáte něco jako

label jessie
  kernel jessie/linux
  append initrd=jessie/initrd.gz priority=low vga=normal  --

(což jsem tuším kdysi oprásknul z ISO instalačky Debianu z isolinux.cfg).

Debian netinstall bootne z initial ramdisku minimální prostředí, řekne si o cestu na distribuční server, a dál už tahá potřebné součástky přes FTP nebo HTTP do ramdisku.

Pokud máte něco s instalačkou ve formátu .ISO (image CD/DVD) tak samozřejmě i image CDčka se dá loadnout do ramdisku a bootnout, a to skrz pxelinuxova pomocníka zvaného "memdisk". Ten pak zajistí emulaci CD-ROM skrz služby BIOSu. Třeba instalačku DOSu takhle bootnete bez problému a dalšího zařizování. Problém nastane ve chvíli, kdy z toho CD nastartuje nějaký trochu schopný kernel, který kašle na služby BIOSu (Linux s CD instalátorem, NT kernel + Win32) a začne se pídit, kde má to CDčko připojeno k hardwaru. A protože kašle na INT13h BIOS services, tak ten disk nenajde.

I k tomuto problému existují workaroundy, bohužel pod Windows to každopádně znamená minimálně vsunout speciální driver do instalačního média = upravit ISO obraz, případně si hrát s WIM obrazy u moderních Windows, případně si poskládat vlastní Windows PE image... Není to špatná vychytávka, mít své vlastní PXE-bootable Windows PE s pár základními vyprošťovacími a klonovacími utilitami pro Windows

Jenom mám trochu obavu, jak bootování tlustých ISO obrazů pojede skrz VPNku - záleží, jak tlustou máte konektivitu mezi pobočkami. Nastartovat Windows PE loadnutím ISO image (desítky až stovky MB) do RAMdisku přes PXE+TFTP trvá docela dlouho i v LANce. TFTP je docela otravný protokol v tom ohledu, že tuším ACKuje každý UDP paket = visí to na latenci per-packet odezvy, tzn. na ping round tripu. V tomto ohledu má jednoznačně navrch netbootable instalátor Debianu, který si vše potřebné tahá over TCP (pomocí FTP nebo HTTP) a navíc selektivně jenom to, co potřebuje. BTW, ještě mě napadá, že gPXE/iPXE snad umí jako transport použít i FTP/HTTP... tzn. napadá mě třeba chainloadnout iPXE skrz primitivní PXE+TFTP a teprve pak rozpoutat pravé HTTP netboot inferno A i bez tohoto "dvoufázového PXE" by asi šlo zařídit, že by se do RAMdisku loadnul jenom relativně minimální image Windows PE, který by obsahoval driver nikoli pro RAMdisk, ale pro iSCSI (nebo AoE), a ten by mountnul na dálku blokové zařízení (třeba plný ISO image = instalačku) - takže by se to nemuselo tahat celé nastojato do RAMdisku. Nebo bootnout z RAMdisku PEčka s "podporou sítě" (včetně CIFS) a instalátor spustit ze síťového disku, ale to už si hodně vymejšlím a vidím v tom mnohá úskalí... každopádně na backup/restore třeba skrz gimagex to stačí. (Jenom ten PE image "se vším potřebným" je už docela tlustý.)

Jinak na "deployment" = hromadnou instalaci má Microsoft své vlastní oficiální/kanonické netbootable nástroje, dřív se to tuším jmenovalo RIS, běží to na Windows Serveru. Něco podobného bych čekal od Symantecu (modernější generace Ghostu).

...k tomu DNS pro OpenVPN remote klienty: Windowsum servíruju z OVPN "serveru" cca toto (kráceno, ale je to vlastně učebnicový příklad):

push "ip-win32 dynamic"
push "dhcp-option DNS 192.168.5.6"
push "dhcp-option DOMAIN mydomain.com"

Odhadem na OpenWRT "klientovi" bude ještě nějaká konfigurační práce s tím, aby si ty pseudo-DHCP opšny od OpenVPN klienta převzal a zapracoval ("up" script). Na druhou stranu je to myslím poměrně běžný a logický požadavek, čekal bych, že je to v OpenWRT "hotové".

[Tom]

Dobry den, omlouvam se znovuoteviram tento stary dotaz, ale prisel jsem na jeden souvisejici problem, tak snad to nevadi....

Spojeni sice funguje, vsechno jede, mam primy pristup na vsechny stroje v RemoteLan, ale vsiml jsem si ze kdyz se ten VPN tunel zatizi nejakym vetsim prenosem, tak hodne zvedne ping (1-3s) a zacne naskakovat packet lost. Po ukonceni prenosu se vse vrati do normalu ( ping cca 25ms)

Docetl jsem se ze by mohlo pomoci zmensit MTU na tom VPN tunelu, tak jseem na server i na klienta pridal

tun-mtu 1400
mssfix 1360

tun0 uz ukazuje MTU:1400, ale je to porad stejne.

Nemate nejaky napad cim by to mohlo byt? co bych mel zkontrolovat? Dekuji. Tom

[frr]

Tohle by chtělo doplňující informace. A bohužel docela dost doplňujících informací Úzkým hrdlem může být buď nízká kapacita spoje (a třeba do toho úzkého hrdla ani přímo nekoukají Vaše routery), nebo třeba procesorový výkon některého z VPN routerů po cestě. Zhruba na co koukat:

- okamžitý CPU load na jednotlivých routerech

- odkud kam ve Vaší topologii naskočí ten dlouhý delay = na kterém hopu.

Vyskytují se tu lidi s praktickými zkušenostmi - pokud jim řeknete, jaké jsou kde procesory a při jak rychlém přenosu (kBps/pps) Vám to stropuje, třeba se podělí o názor, jestli to je/není v pořádku.

Pokud se CPU na routerech flákají, může být ten dlouhý round-trip způsobený dlouhou frontou na vstupu do úzkého hrdla: na egressu, do L3/L2 rozhraní, a to buď na krabičce ve Vaší správě, nebo v krabičce některého providera po cestě = mimo Vaši pravomoc

Teorie hromadné obsluhy praví, že pokud na nějakou zpracující jednotku (úzké hrdlo) hrnete požadavky v průměru rychleji, než kolik stíhá zpracovat, délka fronty přestane konvergovat k nule, resp. začne od nuly divergovat (k nekonečnu). Jak dlouhá fronta naroste (v počtu požadavků resp. v časových jednotkách = zpoždění) než se začnou pakety zahazovat, to je na routeru dáno nějakým konfiguračním parametrem, a je otázkou, zda je tento konfigurační parametr laditelný administrátorem Fronta o nějaké netriviální délce má dvojí význam: pobere nadrobený/dávkovitý provoz a v jistých mezích (reálná zátěž těsně pod maximem) zajistí optimální využití spoje tím, že některé pakety pozdrží = "vyhladí tok dat v čase" - a druhá věc je, že slušně vychované TCP při mírném přetížení sítě či jednotlivého spoje zareaguje zpomalením přenosu (právě díky zpoždění ve frontě kdesi po cestě), aniž by došlo ke ztrátám paketů. Zpoždění ve frontě interaguje s TCP Window na koncových bodech. Tzn. netvrdil bych kategoricky, že dlouhé fronty jsou zlo. Všechno je relativní, záleží na aplikaci. Ta problematika má spoustu dalších nuancí, viz třeba priorizace (fronty s předbíháním), kde má smysl shapovat/priorizovat (nejlépe přímo na vstupu do úzkého hrdla, nikoli o kus dál), random early detection (říkal jste, že roste ztrátovost?) apod. A zřejmě platí axiom, že surovou kapacitu (průchodnost) ničím nenahradíte, nebo přinejmenším shapingem nenahoníte.

Pokud by se Vám vyskytla situace, že se procesory flákají, linky se flákají, a přesto vidíte dlouhé latence, tak to by teprve bylo to pravé žůžo Pak začnete zkoumat, co máte kde za síťovky, nakolik efektivně pracují s interrupty a buffery apod. Pokud to má smysl na daném hardwaru řešit.