[Megoldva] OpenVPN kliens OpenWrt/LEDE router-en

Hálózatok általános

Fedora 36-ra frissítés után elmúlt a VPN elérésem. Ennek oka vélhetően az, hogy openssl-3.0.2-1.fc36.x86_64. Eddig valami 1.1.1n változatra emlékszem, de tévedhetek. Azt mondja, túl könnyű a sinature digest algoritmus. Gondoltam egyet, feltettem az OpenWrt/LEDE router-emre az openvpn-openssl csomagot, felkonfiguráltam, s úgy tűnik, hogy működik, legalább is szerintem a céges szervert sikerül pingelnem.

Most kellene nekem olyan network, firewall config részlet, ami megcsinálja azt, hogy a lokális interface-en dinamikusan osztott IP-n továbbra is az internet felé menjen a forgalom, de legyen egy másik IP tartomány, amely a céges belső legyen. A router-en most a tun0 az, ami a VPN, de ez nem látszik a LAN oldalon, s ötletem sincs, hogyan kell network és firewall configgal megoldani, illetve hol van ehhez érthető leírás.

Grafikus felületet nem szeretnék, tehát elsősorban config file, esetleg uci érdekel, luci viszont nem. Hálózatokhoz hülye vagyok, nem ez a szakmám. Azt sem tudom, ez most routing, bridge, új interface kell-e nekem, vagy mi van. Valami olyasmi, hogy cím & mask1 == alháló1 lokális háló, cím & mask2 == alháló2 céges háló tun0 interface-en, minden más kifelé wan-on.

Ha jól látom, ez routing lesz, csak még nem látom a megfejtést. Mondjuk azt sem bánnám, ha nem menne a teljes netes forgalmam a céges gateway-en át.

Megoldás

network

config interface 'vpn'
        option device 'tun0'
        option proto 'none'
        option auto '1'

firewall

config zone
        option name             vpn
        list   network          'vpn'
        option input            ACCEPT
        option output           ACCEPT
        option forward          ACCEPT
        option masq             1
        option mtu_fix          1

config forwarding
        option src              lan
        option dest             vpn

Lehet, hogy kell a vpn-policy-routing is, de az is lehet, hogy redundáns és nem kell. Ezt még vizsgálni fogom. Úgy néz ki, nem kell. Azóta csináltam új image-et. Biztos, hogy nem kell.

  • 273 megtekintés

( Elbandi v | 2022. 03. 29., k – 19:10 )

jol ertem ha valamelyik kliensen beirod a ceges 192.168.42.42 belso ipt, akkor szeretned hogy a vpn-be menjen, de minden mas a rendes neten?

ha jol van beconfigolva a vpn, akkor igy kene mennie: megkapja/beallitod hogy "route 192.168.42.0 netmask 255.255.255.255", es minden ilyen cim bemegy a tunnelbe.

kelleni fog egy masq is (hacsak nem ismeri a ceges halo a te belso halodat): masq-olja le a heli halodbol jovo de tunnelen epp kimenni akaro forgalmat: iptables -o tun+ -s 192.168.atehelyihalod.0/24 -j MASQUERADE

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( locsemege v | 2022. 03. 29., k – 19:37 )

Most ezt látom a routeren:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         valami.ca       0.0.0.0         UG    0      0        0 wan
111.22.123.0    *               255.255.248.0   U     0      0        0 wan
192.168.0.0     *               255.255.255.0   U     0      0        0 br-lan
192.168.25.0    192.168.160.169 255.255.255.0   UG    0      0        0 tun0
192.168.160.0   *               255.255.255.0   U     0      0        0 tun0

A wan oldali címet direkt elrontottam. A router-ről tudom pingelni a céges szervert, de lan oldalt és a tun0-t nem sikerült „összekötnöm”. A vpn-policy-routing csomagot próbálom használni.

Itthon 192.168.0/24 vagyok, vpn mögötti hálózat 192.168.25/24.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

itt ugye az a gond, hogy a routered tudja mi merre van, tehat ha a packet 192.168.25.123-nak szol, akkor azt bekuldi a tun0-ba, azonban a felado tovabbra is a 192.168.0.x lesz. ha a tuloldal nincs felkeszitve hogy a 192.168.0/24 az errefele talalhato akkor a valasz csomag "el fog veszni". 

erre ket megoldas van:
- vagy masq-olsz a tunnelen, igy a bemeno packeteknek a tun0 innenso ipje lesz a felado (192.168.160.x), igy a valasz packet meg fog erkezni hozzad, amit aztan a majd a router "visszamasq-ol" (deszepszo :D).

- beallitod hogy a tuloldalon is megvannak a megfelelo route szabalyok hogy az ottani gepek tudjak hogy a 192.168.0/24-nak szolo packeteket a vpnserverhez kell kuldeni. (ez bonyolultabb, de cserebe nincs masq, es a tuloldali szerver is pontosan latja ki a kliens).

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( lusi | 2022. 03. 29., k – 19:58 )

Én már átálltam wireguradra, igy régebbi openwrt configot tudok adni.

Én tap-ot használtam udp-n ment a forgalom és külön privát 10.10.x.x IP-k voltak a routereknek, klienseknek, majd ezeken belül 192.168.x.x a belső hálók.

OVpn config:

config openvpn VPN_server
option enabled 1
option port 1177
option proto udp
option dev tap
option ca /etc/openvpn/keys/ca.crt
option cert /etc/openvpn/keys/server.crt
option key /etc/openvpn/keys/server.key
option tls_auth "/etc/openvpn/keys/ta.key 0"
option dh /etc/openvpn/keys/dh1024.pem
option comp_lzo yes
option server "10.10.2.0 255.255.255.0"
option keepalive "10 60"
option persist_key 1
option persist_tun 1
option mute 20
option verb 3
option client_to_client 1
list push "dhcp-option DNS 10.10.2.1"
list push "route 192.168.2.0 255.255.255.0"

firewal.user file:

iptables -t nat -A prerouting_rule -i pppoe-wan -p udp --dport 1177 -j ACCEPT
iptables        -A input_rule      -i pppoe-wan -p udp --dport 1177 -j ACCEPT
iptables -A forwarding_rule -i tap+ -o br-lan -j ACCEPT
iptables -A forwarding_rule -i br-lan -o tap+ -j ACCEPT
iptables -A input_rule -i tap+ -j ACCEPT
iptables -A output_rule -o tap+ -j ACCEPT

Nekem tcp-n, de gondolom, ez nem lesz gond. Mi az a tap? Mitől lesz nekem olyanom? Azt mondod, mindenféle egyéb utility mellőzésével szögeljem bele a tűzfalba iptables szabályként? Mondjuk lehet, hogy ez a legegyszerűbb. A példát köszönöm, mert tényleg nagyon nem értek hozzá. Annyira bosszant, hogy a router authentikál, onnan megy a céges szerver felé a ping, de a router lan-ján lógó gépen már Destination Port Unreachable üzenetet kapok.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A tűzfal szabályok kellenek a te oldalad VPN szerverére (ami a openwrt). hogy töled menjen ki forgalom. És be is menjen a belső hálódra.

De ez kell a másik oldal VPN szerverére is ami valami. ha onnan akarsz inditani.

Ez kliens-kliens config. És a legegyszerűbb, ami elég volt nekem. De wireguarddal még egyszerűbb.

Olyan egyszerű, hogy első konfignál, OpenVPN után nem tudtam elhinni, illetve túl akartam bonyolitani és nem ment :). pl. firewal.user file nem kell, mert csak egy firewall szabály kell a firewall fájlba.

A firewall.user megvan, az egy include file, szebb külön szedni. Küzdök tovább, az imént vacsoráztam, talán kevésbé éhesen jobban megy. Érzem, hogy közel vagyok, mert a router sikeresen authentikál, onnan megy is a céges szerverre a ping.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Czo v | 2022. 03. 29., k – 20:59 )

A /etc/config/openvpn -ben vetted fel az openvpnt? Ha nem, akkor ott vedd fel es legyen neki fixen beirt 'dev' opcioja, pl 'tun1'. Majd a /etc/config/network -ben csinalj egy uj interfacet, aminel a 'device' legyen ugyonaz a tun, nyilvan legyen 'auto' 1, hogy bootnal felhuzza es a 'proto' pedig 'none'. Ezutan a /etc/config/firewall -ban kell neked egy uj zona, aminel  a 'network' nyilvan legyen ugyonaz, ami at az elozoleg letrehoztal. Itt elso korben az input/output/forward -ot acceptra raknam, illetve 'masq' es mtu_fix-et 1-re. Amire meg biztos, hogy szukseged lesz, az itt 1 fowarding rule, mert engedned kell a lanodat a vpnes halozat iranyaba forwardolni.

Szerintem ezen kivul, masra nem lesz szukseged, es kb ezek az opciok most is megvannak, mivel a lan-wan natolas valoszinuleg mukodik nalad.

Köszönöm, nagyjából értem. Az openvpn közvetlen configfile-ból van, mert onnan tűnt egyszerűbbnek, illetve arról volt egy korábbi mentésem még Fedorára, s az alapján azonnal fel is épült a vpn kapcsolat. Egyedül ez a route-olás fogott ki rajtam. Ezekből a részinfókból már csak összeszögelem valahogyan.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tehat, kulon van az openvpn configod. Ezt a configot hivod be a /etc/config/openvpn -ben? Mert ha igen, akkor az is ugyonolyan jo. Marmint, az lenne a lenyeg, hogy az openwrt tudjon rola, hogy elindul/folyamatban van a vpn csatlakozas. Mert akkor fogja figyelni ezt az interfacet es alkalmazni a tobbi definialt rulet. Itt annyi van meg, hogy a tun eszkoz egzakt megadasat ugye, at kell raknod a konfigba. 

Van egy /etc/openvpn/myvpn.conf file-om. Ebben csak a cert-ek elérési útját kellett javítanom, s már fel is épült a kapcsolat, amint a szolgáltatást elindítottam. Van egy tun0 device-om 192.168.160.170 IP címmel. A routing tábla valahol fentebb a topikban. Eleve zavaros nekem, mi milyen tartomány, mert a céges háló nem ez az alhálózat, de a saját itthonim sem.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ide valaszolok, mind a ketto kommentedre.

A konfigba probald meg explicite beirni a tun eszkozt, mert akkor tudod explicite "network"-hoz rendelni. ehhez csak annyi kell, hogy siman be legyen irva a konfigodba, hogy "dev tun1". A szolgaltatas elinditas alatt azt erted, ahogyan a /etc/init.d/openvpn -t start-olod? 

config forwardingbol kell egy ujabb bejegyzes, ahol az src ugyonugy a lan-od, a dest pedig a korabban letrehozott zona. Tehat valami ilyesmi:

/etc/config/network:

config interface 'vpnnet1'
	option proto 'none'
	option auto '1'
	option device 'tun1'


/etc/config/firewall:

config zone
	option name 'vpnnet1'
	option network 'vpnnet1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'vpnnet1'

 

Elvileg routeinggal nem kell semmit kezzel kezdened, mert a VPN felallasakor kapni fogsz route szabalyokat a tuloldaltol. Mivel a te gepeden a def gw ez a doboz, igy ami a VPN fele megy, az el fog jutni ide. A geped pedig egyszeruen be fogja natolni ide. 

( locsemege v | 2022. 03. 29., k – 21:45 )

Szerkesztve: 2022. 03. 29., k – 21:47

Hurrá, ping már megy a gépemről! Megpróbálom elérni a samba fileszervert, aztán kihúzni az svn repóból egy forráskódot. Utána meg beleszögelem a router image gyártó scriptjébe ezt a sok mindent.

Szerk.: Korai volt az öröm. Csak a ping megy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ha a routerről már megy az elérés, akkor a VPN konfig és az VPN servertől kapott routing jó.

 

Már csak neked kell a router csomagszűrőjén atengedni ÉS MASQUERADE-olni az érintett csomagokat.

Tehát ahol a SRC a LAN, a DST pedig a céges network.

(várhatóan default szabálykészlet csak az wan-on kilépő csomagokat masq-olja, de mindent enged. Így várhatóan tőled kimegy a csomag, de a céges tűzfal eldobja a saját belső SRC címek miatt. Ezért kell masqolás, hogy mingens src IP a VPN kliensed helyi IP-je legyen)

Ez grafikus felületen triviális, mert minden interface-haz rendel egy zónát, és egyből tudsz arra vonatkozó szabályokat is hozzáadni.

 

Ha CLI-ből akarod, ahhoz meg kell értened hogy működik a default csomagszűrője, hogyan kell manuálisan új zónat létrehozni, és ebbe engedélyező szabályokat adni.

(Én nem használom az openwrt saját tűzfalát, hanem 'mezítlábas' iptables-t saját scripttel felépítve, így konkrét példát nem tudok mutatni)

zrubi.hu

Valójában már minden megy, csak túl új a Fedora 36, ezért az smb elérés sem ment: smbXcli_negprot_smb1_done: No compatible protocol selected by server

De smbclient-tel parancssorból látom a céges szervert, illetve svn repóból ki tudtam húzni forráskódot. Jó volna még a Samba elérést megcsinálni, de ötletem sincs, hol tudom a gvfs-smb kliens protokollt konfigurálni. Kéne valami grafikus samba kliens, amelyben ez vagy konfigolható, vagy nem túl új, vagy csak működik. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( locsemege v | 2022. 04. 15., p – 12:08 )

Majdnem elfelejtettem mondani, Fedora 36-on is megoldódott ez:

openssl-3.0.2-2.fc36

- Allow disabling SHA1 signature creation and verification.
Set rh-allow-sha1-signatures = no to disable.
Allow SHA1 in TLS in SECLEVEL 1 if rh-allow-sha1-signatures = yes. This will support SHA1 in TLS in the LEGACY crypto-policy.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE