[Techinfo] windows active directory efop wifi over vpn sh....t

[Fehér Sándor]

Kicsit felmelegíteném ezt a szálat.
Azóta is dolgozom ezen.
Erre jutottam:

Linux szerver openvpn legfrisebb kiadás
windows 10 kliens
a szerver bridge ként konfigurálva

a windows-nál, ha az openvpn service nevű szolgáltatást engedélyezem és 
a többi openvpn nevűt tiltom, akkor a config mappában lévő 
konfigurációhoz automatán kapcsolódik az openvpn kliens.

Szóval sikerült megoldani, hogy vpn keresztül az eduroam hálózatból 
működjenek a laptopok.
Csak az az egy probléma van, hogy a win a bejelentkező képernyőn nem 
kapcsolódik automatán az eduroam wifihez, ha tartományban van a gép. 
(egyébként igen és manuálisan is rákapcsolódik, ha rákattintok)
Bejelentkezés után viszont rácsatlakozik automatikusan az eduroam nevű 
hálózatra.
Ez csak fél megoldás, bár működik.

Tudtok ötletet adni, hogy mit nézzek meg?
Szóval az a gond, hogy a bejelentkező képen nem kapcsolódik a windows10 
automatán a wifire. Csak manuálisan.
Így a gpo-k egy része nem fut le.

Próbáltam ütemezett feladatban megadni rendszerindításkor:
netsh wlan connect eduroam
netsh wlan connect ssid=eduroam name=eduroam
A parancsok win alatt bejelentkezve működnek, de rendszerindításkor így 
sem kapcsoldott a laptop a wifire automatán.

Esetleg másik service létrehozni és batch fájlt futtatni a fenti 
parancsokkal, de ennyire már nem vágom a win-t.

Szerintetek?



2018. 09. 11. 16:28 keltezéssel, Tiba Csaba írta:
> Bocsi félre ment a hozzászólás!
>
> Tiba Csaba <tibacsaba at gmail.com <mailto:tibacsaba at gmail.com>> ezt írta 
> (időpont: 2018. szept. 11., K 16:26):
>
>     A sulixnál a webes guin kell jelszót változtatni.
>
>     Fehér Sándor <fehersandor at madach-starjan.sulinet.hu
>     <mailto:fehersandor at madach-starjan.sulinet.hu>> ezt írta (időpont:
>     2018. szept. 11., K 15:49):
>
>
>         Sziasztok!
>
>         Tudtok valami használható módszert az új efop (eduroam)
>         wifiről kapcsolódott laptopok ad-hez kapcsolására interneten
>         keresztül vpn segítségével?
>
>         Openvpnel kezdtem és eddig jutottam:
>         linux serveren fut egy openvpn a belső hálózaton. A másik
>         "lába" internethez kapcsolt és portforwardal jönnek rá
>         kívülről a laptopok.
>         A belső ip címre bridge-t tettem (tap mód) és így olyan a
>         külső gép, mintha virtuálisan bedugnám a belső hálózatba.
>         (ipv6 dhcp, broadcast minden átjön a tunnelbe)
>         A lényeg, hogy ez működik, de a f*s windows-okkal megint baj van.
>         Az openvpn-gui bejelentkezéskor automatán felcsatolja a vpn
>         adaptert és kiépíti a kapcsolatot.
>         Ott a baj, hogy a gpo frissítések idején a bejelentkezés alatt
>         még nem aktív a vpn.
>         Az utolsó lépés csak ezek után a vpn csatlakozása, akkor már
>         késő. A computer policyk sem futnak le teljesen, csak egy
>         részük  okés.
>
>         Példa:
>         Megváltoztatom a laptop jelszavát az ad-ben és pár perc
>         elteltével kijelentkezek majd vissza és nem változik meg a
>         jelszó, a régivel enged be.
>         gpupdate /force parancs hatására a jelszó változtatás után a
>         felhasználói policy nem fut le (mivel nem jó a jelszó) de nem
>         is frissül közvetlen bejelentkezéskor.
>         Ha a gépet saját wifire engedem vagy kábelre (lan) dugom
>         minden frissül azonnal és teljesen jól működik.
>         A vpn is teljesen jó, sajnos a win-el van a baj.
>
>         Megoldás:
>         Ha nem néznének minket hülyének és adnának hozzáférést az
>         eszközökhöz, akkor egy site-to-site vpn-el meglehetne ezt
>         oldani, hogy ne a windows "jelentkezgessen" be a vpn-be, hanem
>         mindig ott legyen a kapcsolat.
>
>         Kérdésem, hogy ti megoldottátok már, van ötletetek vagy
>         esetleg nem is érdekel a dolog és marad minden "local" verziós
>         ad nélkül.
>
>
>
>         openvpn-server.conf:
>
>         port 1192
>         proto tcp
>         dev tap0
>         ca /etc/openvpn/CA/keys/ca.crt
>         #crl-verify /etc/openvpn/crl.pem
>         cert /etc/openvpn/CA/keys/eduvpn.crt
>         key /etc/openvpn/CA/keys/eduvpn.key
>         dh /etc/openvpn/CA/keys/dh2048.pem
>         #plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so login
>         verify-client-cert
>         #client-cert-not-required
>         #username-as-common-name
>         server-bridge 172.21.254.118 255.255.0.0 172.21.203.1
>         172.21.203.100
>         up /etc/openvpn/bridge-up.sh
>         script-security 2
>         #ifconfig-pool-persist /etc/openvpn/bridge.ipp
>         keepalive 10 120
>         #comp-lzo
>         user nobody
>
>         bridge-up script
>
>         #!/bin/bash
>
>         /sbin/ifconfig $1 up
>         /sbin/brctl addif br0 $1
>
>
>
>         ezenkívül ensx (lan) adaptert bridge-be kell tenni interfaces
>         fájl konfigurálással
>         serverbridge ha simán van kiadva mindenféle ip/mask nélkül
>         üresen, akkor a saját-meglévő dhcp szervered oszt ip-t a vpn
>         kliensnek a tunnelen keresztül.
>         _______________________________________________
>         Techinfo mailing list
>         Techinfo at lista.sulinet.hu <mailto:Techinfo at lista.sulinet.hu>
>         Fel- és leiratkozás:
>         http://lista.sulinet.hu/mailman/listinfo/techinfo
>         Illemtan: http://www.szag.hu/illemtan.html
>         Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
>
>
>
> _______________________________________________
> Techinfo mailing list
> Techinfo at lista.sulinet.hu
> Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo
> Illemtan: http://www.szag.hu/illemtan.html
> Ügyfélszolgálat FAQ: http://sulinet.niif.hu/

--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lista.sulinet.hu/pipermail/techinfo/attachments/20181019/c495ecd6/attachment.html>