Dotaz: Linux jako VPN server pro Mikrotik klienty

[Petr]

Dobrý den.
Prosím, na čem by jste postavili Linuxový VPN server, ke kterému by se připojovali Mikrotik klienti ? Původně jsem si myslel, že bych to postavil nad OpenVPN, ale tady jsem během chvíle narazil a to díky tomu, že v Mikrotiku je podpora pro OpenVPN velmi limitována - neumí UDP, TLS, autentifikace pouze přes jméno/heslo, atd... Detaily o omezení OpenVPN na Mikrotiku zdeTakže tudy asi cesta moc nevede. K tomuto serveru bude trvale připojeno cca 15-20 Mikrotik klientů 24x7x365. V tunelu se budou přenášet data do max. velikosti 1MB za minutu. Taky, pokud VPN tunel spadne, tak by se měl znovu umět sestavit - to ale počítám bude Mikrotik umět sám od sebe. Ještě jedna důležitá věc, všechny Mikrotiky jsou za NATem, tudíž cokoli s IPSEC by mohlo "teoreticky" dělat problémy. Zároveň ale potřebuju aby byla data na cestě šifrována.

No a teď babo raď

Měl by někdo nějaký nápad, co by stálo za vyzkoušení ?
Mikrotik jako klient je podmínka.

Děkuji,
Petr

Odpovědi

[Petr]

Ještě doplním, že podpora UDP v OpenVPN na Mikrotiku již nějak začíná fungovat, ale možnosti jsou stále omezené a funkcionalita je možná pouze při přechodu na poslední Beta verzi RouterOS. Totéž platí pro WireGuard ....V produkci ale nechci žádné beta verze používat.

Petr

[kolemjdouci]

Zvazoval jste Wireguard?

On snad už Mikrotik umí Wireguard?

[Petr]

Ano. Nejaka podpora pro WireGuard v posledni “7-mickove” bete RouterOSu je.
Takze zatim nepouzitelne.

Vyzkoušel bych strongSwan.

[Petr]

Prosim vice detailneji.

Betaverze nechceš ==> Wireguard a OpenVPN ne

Zbývá IPsec. No a ten se na linuxu konfiguruje pomocí strongSwan.

Ještě ti zbývá, dát místo linuxu taky Mikrotik, abys měl na obou stranách zařízení, které umí přesně to stejné, co protistrana.

[Jendа]

Pro uvedené přenosy je OpenVPN, byť v omezené Mikrotik implementaci přes TCP, úplně v pohodě. Problémy se začnou objevovat při 1 MB za sekundu. Počet klientů je taky v pohodě, a pokud by bylo potřeba přidat tolik, že by to openvpn server přestal zvládat (tam očekávám, že na problém narazíš tak při 100-200 klientech), tak spustíš druhý openvpn server na jiném portu a část klientů nastavíš na něj.

TLS, autentifikace pouze přes jméno/heslo

To je nějaký omyl, na RouterOS jsem normálně importoval certifikát CA, certifikát klienta a privátní klíč a funguje to. TLS, samozřejmě. Dokonce je použitá kryptografie překvapivě moderní a v pohodě. A to všechno je tam už minimálně dva roky.

Taky, pokud VPN tunel spadne, tak by se měl znovu umět sestavit - to ale počítám bude Mikrotik umět sám od sebe.

Ano, to OpenVPN v RouterOS normálně dělá. Pokud to bude často, budeš chtít změnit keepalive a podobné parametry, ale default je rozumný.

//a nejlepší řešení s jakýmkoli Mikrotikem samozřejmě je flashnout tam OpenWRT

[ET]

Ola,

mas nekde nasazeny OWRT na MKT?

V lete jsem kupoval do jedne firmy MKT (moje prvni zkusenost) kvuli (SSTP) VPN a celkem fail - neumi locknout account pri vice neuspesnych pokusech (takze brute-force ready), v DNS nesel nastavit domain suffix, grrr...

PS: dobrej waaat aneb anonym excel rulezzz, wtf... mas na to nejakyho bota/harvestera, nebo fakt procitas seznam.cz? :)

[Jendа]

mas nekde nasazeny OWRT na MKT?

Mám, a to docela dost, asi 15 RBmAPL-2nD, 15 RB750Gr3 a pár nějakých hAP. Běží na tom meteostanice (bitbangované SWD přes GPIO) a radiolokátory (skládání obrazu z UDP paketů a nějaké základní odšumování), oboje napsané v Pythonu (na ten imageprocessing vlastní modul přes CFFI). Zatím umřel jeden ten RB750Gr3, nedávno jsme ho vyměnili a měl bych analyzovat co se mu stalo. Jakože každou hodinu jsem tam měnil 100B soubor, ale to by snad jako mělo vydržet.

PS: dobrej waaat aneb anonym excel rulezzz, wtf... mas na to nejakyho bota/harvestera, nebo fakt procitas seznam.cz? :)

Tohle bylo na #brmlab a na #mindspace, seznamzprávy nečtu. Ale občas koukám na homepage novinek a idnes.

[ET]

dix za info, priste zkusim OWRT ;)

[Jendа]

Jinak předtím měli na radarech místo Mikrotiků Raspberry a to teda byla odysea mrtvých SD karet a nevysvětlitelných problémů. Ale měli je read-write (byť na to moc nezapisovali, ale žurnál se předpokládám updatuje stejně), tak si za to možná můžou sami. Ale zase mít to kompletně read-only je opruz, protože třeba i konfiguraci si musíš tahat po každém bootu, .bash_history bych rád aby mi fungovalo a tak. Ty Mikrotiky nasazujeme něco přes rok (no prostě co to adminuju já), tak doufám, že to nezačne třeba po dvou letech nějak masivně umírat… Jinak teda ještě je blbý že to nemá FPU, ale jako upočítá se to (napsal jsem si vlastní logaritmus, ale pak jsem zjistil, že problém ve výkonu je jinde -- no vida, další problém, jak to je osekaný systém, tak tam není třeba perf), a nemá to obecně výkon třeba na realtime kompresi kamer a taky mi vadí osekané věci a bugy v busyboxu.

[jiwopene]

Pokud Raspberry s readonly kartou, vytvořil bych na ní 1 oddíl vfat, na kterém je zavaděč, jádro, initrd a systém ve SquashFS. Patche můžete řešit přimountováním dalšího SquashFS „přes“ stávající systém – viz Slax 8 a starší. Na kartě je pak jen adresář s očíslovanými obrazy. Další možností je mít na kartě tar/cpio/… archivy, které se z initrd načtou do tmpfs a drží se po celou dobu v RAM. Pokud máte i spolehlivý záložní zdroj, nemusíte mít kartu při používání ani vloženou, protože je vše v paměti a karta je potřeba jen při spuštění a údržbě.

Nastavení initrd je na Raspberry trochu divné (fungovalo mi jen jendou), připadá mi jednodušší ho mít přibalené rovnou do jádra (menuconfig a dál se proklikáte). Pokud chcete i aktualizaci jádra, vytvořil bych si jádro s initrd, které stáhne ze serveru nastavení (bash skript podepsaný GPG), který kexecem spustí systém nebo vykoná jiné úkony.

[Jendа]

Pokud Raspberry s readonly kartou, vytvořil bych na ní 1 oddíl vfat, na kterém je zavaděč, jádro, initrd a systém ve SquashFS. Patche můžete řešit přimountováním dalšího SquashFS „přes“ stávající systém – viz Slax 8 a starší. Na kartě je pak jen adresář s očíslovanými obrazy.

To by byl ještě větší opruz, nekonečně rostoucí řada patchů. Jako přemýšlel jsem o tom, že tam udělám tohle a ten squashfs bude ve skutečnosti brutálně redundantní (buď víc kopií, nebo Reed-Solomonovy kódy třeba pomocí programu par2) a při bootu se celý nahraje do paměti už opravený, ale nakonec jsem skončil u tohoto. Výhoda je, že změny provedené v RAM lze pak aplikovat.

libattr1-dev
https://github.com/kmxz/overlayfs-tools
main.c: +//#include <linux/stat.h>

cd /root/overlayfs-tools
rm /mnt/root-rw/upper/var/lib/haproxy/dev/log
rm overlay-tools-*.sh
mount -o remount,rw /mnt/root-ro
echo y | ./overlay diff -l /mnt/root-ro -u /mnt/root-rw/upper
echo y | ./overlay merge -l /mnt/root-ro -u /mnt/root-rw/upper
bash overlay-tools-*.sh

možná opravit /mnt/root-ro/etc/fstab

[Jendа]

Jinak ještě stojí za to kouknout na APU2, což je x86-64 s normálním mSATA SSD. Ty máme zatím dvě a normálně to funguje a samozřejmě systém pohodlnější (normální Debian). Ale zrovna jsou na místech kde je to v budce, kdyby to bylo v rozvaděči venku, tak už to třeba taky umře, kdo ví. Teď koukám, že něco z toho má minimální provozní teplotu 0°C a to možná v zimě bude v rozvaděči míň i když to běží, hmm…

[Max]

Buď si vystač s OpenVPN, nebo použij ipsec/ikev2. Jiná možnost není.
Zdar Max

[Petr Šobáň]

Já používám normálně Ipsec na propojení dvou mikrotiku přes internet a tam odkud se navazuje spojení nemá ten mikrotik veřejnou IPv4 (DSL modem od O2 v bridge).

[Petr]

Tak jsem to nakonec vyřešil přes OpenVPN over TCP.
Konfigurák serveru viz. níže...

Připomínky vítány, rady jak a kde co zlepšit/upravit taktéž

port 1194
proto tcp

dev tap

ca ca.crt
cert webcams.my-domain.com.crt
key webcams.my-domain.com.key
dh dh.pem

server 10.8.1.0 255.255.255.0

client-config-dir /etc/openvpn/ccd
ifconfig-pool-persist ipp.txt

push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 10.8.1.1"
push "dhcp-option DNS 10.10.10.1"

keepalive 10 120
auth-nocache
cipher AES-256-CBC

user nobody
group nogroup

persist-key
persist-tun

status /var/log/openvpn/openvpn-status.log
log         /var/log/openvpn/openvpn.log
log-append  /var/log/openvpn/openvpn.log

verb 3

Děkuji všem, kteří přispěli.
Dlouho jsem si s tím hrál a přemýšlel nad tím - OpenVPN s Mikrotik klienty je asi nejlepší a nejjednodušší řešit touto cestou.

Petr

[Petr]

Ještě jsem se dnes divil, že nevidím klienty mezi sebou...
Opraveno přidáním direktivy "client-to-client" do konfiguračního souboru serveru.

Petr