Helló!
OPNsense alatt próbálok OpenVPN szervert összehozni. Kapcsolatot OP3-on teszteltem OpenVPN klienssel, illetve a telefon 4G-t hotspotként megosztva Win10-en is. Mindkét esetben sikeres a csatlakozás, de sem a belső hálót nem tudom elérni, sem internetezni nem tudok.
Mindenből az aktuális legújabb verzió van.
Az egészet ez alapján csináltam végig:
https://www.kirkg.us/posts/building-an-openvpn-server-with-opnsense/
De mellé néztem még ezeket:
https://docs.opnsense.org/manual/how-tos/sslvpn_client.html
https://www.sparklabs.com/support/kb/article/setting-up-an-openvpn-server-with-opnsense-and-viscosity/
https://networkshinobi.wordpress.com/2017/05/29/opnsense-as-a-vpn-server/
Mivel a kapcsolat létrejön csak érdemi adatforgalmat nem tudok produkálni ezért a tűzfal szabályokra tippelek, hogy valami gond lehet. A fenti tutorialok alapján a varázsló ezeket létrehozza. Látszik is...Így viszont elakadtam, hogy mi lehet a gond.
Van valami ötletetek, hogy mi lehet a gond?
Hozzászólások
Konfigurációs beállításokat (vpn, túzfal) és logokat láthatnánk esetleg?
Ma reggeli próbálkozásom Androidos kliens logban:
(Az érzékeny adatokat # karakterekkel takartam, vagy másra neveztem át, de látható)
Az otthonni belső hálóm 10.1.1.0/24... és most, hogy ezt leírtam nektek, leesett, hogy mit néztem be valószínűleg. Elírtam a belső háló címét, mert 10.0.0.0/24-es hálót adtam meg. (facepalm).
09:10:26.235 -- ----- OpenVPN Start -----
09:10:26.236 -- EVENT: CORE_THREAD_ACTIVE
09:10:26.260 -- Frame=512/2048/512 mssfix-ctrl=1250
09:10:26.272 -- UNUSED OPTIONS
0 [persist-tun]
1 [persist-key]
4 [tls-client]
7 [lport] [0]
8 [verify-x509-name] [server] [name]
09:10:26.273 -- EVENT: RESOLVE
09:10:26.288 -- Contacting ##### via UDP
09:10:26.288 -- EVENT: WAIT
09:10:26.291 -- Connecting to ###### [ via UDPv4
09:10:26.324 -- EVENT: CONNECTING
09:10:26.328 -- Tunnel Options:V4,dev-type tun,link-mtu 1570,tun-mtu 1500,proto UDPv4,comp-lzo,keydir 1,cipher AES-256-CBC,auth SHA256,keysize 256,tls-auth,key-method 2,tls-client
09:10:26.329 -- Creds: Username/Password
09:10:26.330 -- Peer Info:
IV_GUI_VER=OC30Android
IV_VER=3.2
IV_PLAT=android
IV_NCP=2
IV_TCPNL=1
IV_PROTO=2
IV_LZO=1
09:10:26.377 -- VERIFY OK : depth=1
cert. version : 3
serial number : 00
issuer name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=N
subject name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=N
issued on : 2018-05-08 15:57:17
expires on : 2028-05-05 15:57:17
signed using : RSA with SHA-256
RSA key size : 2048 bits
basic constraints : CA=true
09:10:26.378 -- VERIFY OK : depth=0
cert. version : 3
serial number : 01
issuer name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=N
subject name : C=HU, ST=Pest, L=Budapest, O=O, emailAddress=admin@O.com, CN=server
issued on : 2018-05-08 15:57:17
expires on : 2028-05-05 15:57:17
signed using : RSA with SHA-256
RSA key size : 2048 bits
basic constraints : CA=false
cert. type : SSL Server
key usage : Digital Signature, Key Encipherment
ext key usage : TLS Web Server Authentication, ???
09:10:26.796 -- SSL Handshake: TLSv1.2/TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
09:10:26.800 -- Session is ACTIVE
09:10:26.804 -- EVENT: GET_CONFIG
09:10:26.814 -- Sending PUSH_REQUEST to server...
09:10:26.843 -- OPTIONS:
0 [route] [10.0.0.0] [255.255.255.0]
1 [dhcp-option] [DNS] [10.1.1.12]
2 [route] [10.0.0.0] [255.255.255.0]
3 [route] [10.0.8.1]
4 [topology] [net30]
5 [ping] [10]
6 [ping-restart] [60]
7 [ifconfig] [10.0.8.6] [10.0.8.5]
8 [peer-id] [0]
9 [cipher] [AES-256-GCM]
09:10:26.844 -- PROTOCOL OPTIONS:
cipher: AES-256-GCM
digest: SHA256
compress: LZO
peer ID: 0
09:10:26.845 -- EVENT: ASSIGN_IP
09:10:26.866 -- Connected via tun
09:10:26.867 -- LZO-ASYM init swap=0 asym=0
09:10:26.872 -- EVENT: CONNECTED info='####@#####:#### (####) via /UDPv4 on tun/10.0.8.6/ gw=[10.0.8.5/]' trans=TO_CONNECTED
09:11:17.770 -- EVENT: DISCONNECTED trans=TO_DISCONNECTED
09:11:17.787 -- EVENT: CORE_THREAD_INACTIVE
09:11:17.788 -- Tunnel bytes per CPU second: 0
09:11:17.788 -- ----- OpenVPN Stop -----
Route/NAT szabályok rendben vannak?
Itt nezelodnek, a postrouting es masquerade szabalyokat is nezd meg.
Azokat kb fél óra múlva tudom csak betenni ide mert el kell mennem. De van még egy különös dolog. Most átírtam local network címeket mindenhol a jóra. Így már elérek bizonyos címeket és működik az internet is. Néhány címet elérek, néhányat nem. Pl 10.1.1.11 és 10.1.1.12 elérhető, de a 10.1.1.10 nem. A másik, hogy hívok egy what's my ip-t, akkor a Telekomos IP-m dobja, és nem az otthoni pulikus IP-m amire becsatlakoztam.
Két képet tudtam most lőni mobilról.
WAN
https://mega.nz/#!xyZGUJaB!D-WzCA3m8nH4bZ-gY0GQ026EOZhde2KhIsVadu6a0og
OPENVPN
https://mega.nz/#!RiY1SKob!YXthLvz51farLk2NfGEJzTk2EPaG2jruMRiuKDpnAV0
A NAT szabályoknál ennyi van: WAN -> LAN netwokrs, 127.0.0.0/8, 10.0.8.0/24
Még annyi, hogy a fenti logban bár nem látszik, de javítottam a helyi hálózat címet 10.1.1.0/24-re... Így már rálátok a helyi hálóra, bár az ESXI oldala nem jön be valamiért, a többi gép elérhető.
Viszont az IP-m kifelé továbbra is a mobilos 4g kapcsolat public ip-je, és nem az otthoni hálózat public IP-je.
Erre kene a masqueradeing. :)
Mármint melyikre? :) Összetett a problémám. Most elsőnek az a gond, hogy mobilon kapok a szolgáltatótól egy 37.x.x.x IP-t. Az otthoni wannak valami 172.x.x.x a publikus IP-je. Erre kapcsolódok VPN-en keresztül. Viszont ilyenkor továbbra is 37.x... kezdetű marad az IP-m. Ilyenkor nem a másikat kellene mutatnia?
Mi az, hogy ez marad az ip-d? Hol próbálod nézni ezt?
Kicsit egyértelműbben írj már légyszi
A kliensen nyilván ez marad, ha meg kimész a netre, és a távoli helyen nézed, az attól függ, hogy a kliensen beleroutoltad-e ezt a forgalmat a vpn-be vagy nem.
Persze, hogy távoli helyen. Már láttam a korábbi írásod, hogy nem routoltam bele a forgalmat a vpnbe.
Inkább először az kellene, hogy értelmesen megfogalmazza, mit szeretne. Aztán átgondolni, hogy az hogyan is működne, és beállítani a dolgokat a szerint. :-)
"Viszont az IP-m kifelé továbbra is a mobilos 4g kapcsolat public ip-je, és nem az otthoni hálózat public IP-je."
Én ebből azt feltételezem, hogy minden netes forgalámt a vpn-en akarná áttolni, de még mindig a mobilja ip-jét látja miden netes dolog. Nyilván az is kellene ( a masq/nat mellett), hogy belerouteolja a netes forgalmat a vpn-be. openvpn kapcsoló, default route rewrite vagy valami ilyesmi
Jogos. Tényleg nem fogalmazom meg értelmesen.
1. Igen, azt szeretném, hogy a VPN-en csatlakozott kliensek teljes hálózati forgalma a VPN-en át menjen.
2. A másik cél, hogy a VPN-re csatlakozott kliens a helyi gépeket is elérje, mintha ő is a helyi hálózat része lenne.
Csak egy kis rávezetésre van szükségem, hogy merre keresgéljek.
1. Erre írtam a gateway redirect vagy ilyemi opcióta szerver configba
2. Erre meg a push route körül nézelődj. a szerver a helyi háló ip tartományát a kliens csatlakozásánál áttolja a kliens routing táblájába ( bár ha az 1. miatt mindent áttolsz, akkor ez lehet, nem is kell már külön)
Meg valahogy a belső hálón lévő többi helyi gépnek, vagy azok gw-ének tudni kell, hogy a vpn kliensei felé menő válaszokat a vpn szervernek küldjék.
Persze, hogy kilásson a szerveren keresztül a vpn kliens, a szerveren az openvpn-től függetlenül meg kell oldani az ip forwardot és a natolást is kifelé
Amit írok, az sima openvpn-es megodás, nem tudom, hogy opnsense mennyivel másabb, de a logika ugyanez kell legyen.
Köszi szépen. Megpróbálom működésre bírni. :)
A push route parancshoz rendszergazdai jog kell a klienseken.
Androidon, nem rootolt rendszer esetén verziónként eltérő lehet a működése.
4.4 ota van vpn api tamogatas, nem kell root jog. Tobb eszkozon az OpenVPN for Androidot hasznalom root nelkul, tokeletesen megy a forgalom atiranyitas.
Köszi az infót ;] Jelly Bean-es időszakból emlékeztem még :)
Mobilon/tab-on pár hete használom root nélkül, hibátlan eddig. Egy kinti vps -en a szerver, oda csatlakozik otthonról egy gép, meg a mobil kintről. Gyönyörűen elérem a belső hálót, belső dns 'push'-sal a belső neveket is.
Köszi a rávezetést. :)
Ezt kellett még a confighoz hozzádobni és jó lett:
push "redirect-gateway def1"
push "dhcp-option DNS X.X.X.X"
remek;-)
OpenVPN-nél régebben a leggyakoribb hiba a route bejegyzések hiánya volt. Hiába jött létre kapcsolat, hacsak nem Layer2-es VPN, akkor marhára nem tudja a kliens, hogy merre az arra. Ez lehetett rosz konfig miatt, vagy jogosultsággondok miatt, utóbbi az újabb kliensekben le van kezelve, de attól még nem elvetendő a vizsgálata.
Magának a VPN tunnelnek a szerver oldalát tudod pingelni?
Route parancs jelzi, hogy merre van a távoli háló?
Igen a szerver oldalt tudom pingelni. Fentebb beszúrtam egy log részletet. Tehát a tunnel 10.0.8.1-es címén elérhető az OPNsense felülete.
tl;dr
pfSense / OPNsense-nél a bejövő VPN interfészre külön kell engedélyezni a forgalmat.
Firewall -> Rules -> Floating, LAN, WAN, <VPN típus>
--
trey @ gépház
Köszi.
Közben kiderültek a hibák, sorban:
1. Rossz hálózatot adtam meg helyi hálózatnak ( 10.1.1.0 helyett 10.0.0.0)
2. push route, redirect-gateway, dhcp-options DNS, kellett még bele.
Így már szépen megy.