Configurare un Mikrotik come un server OpenVPN

Da qualche tempo ho convertito tutte le VPN che usavo per la gestione dei clienti in OpenVPN, diventato oramai uno standard, al posto delle vecchie PPTP oramai non più sufficientemente sicure e così avendo quasi sempre un Mikrotik presso i clienti ho deciso di riassumere i passaggi per la configurazione in questo post.

Tutta la configurazione viene fatta direttamente nel Mikrotik, compresa la generazione dei certificati, quindi dopo esserci collegati con il Winbox possiamo iniziare.

Mi raccomando di sostituire gli indirizzi IP, gli utenti e le password con i vostri dati.

Per prima cosa creiamo una CA, firmiamo il relativo certificato ed esportiamolo:

/certificate
add name=CA common-name=CA key-usage=key-cert-sign,crl-sign days-valid=3600
sign CA ca-crl-host=192.168.0.1 name=CA
export-certificate CA

In questo modo all’interno della sezione File ci ritroveremo con il file cert_export_CA.crt.

Ora che abbiamo generato la CA possiamo generare il certificato per il nostro Mikrotik, quindi scriviamo:

/certificate
add name=Mikrotik common-name=mikrotik days-valid=3600
sign Mikrotik ca=CA name=mikrotik

A questo punto se tutto è andato a buon fine dovremmo ritrovarci con i due certificati appena generati:

Certificates

Ora dobbiamo creare un pool per l’assegnazione degli indirizzi IP ai client:

/ip pool add name=ovpn-pool range=192.168.131.10-192.168.131.200

Qui la scelta della classe è arbitraria, l’importante è che non sia una classe esistente in LAN.

Creaiamo poi il profilo per la connessione, definendo il nome, l’ip da usare per il mikrotik e il relativo pool di indirizzi:

/ppp profile add name=ovpn local-address=192.168.131.1 remote-address=ovpn-pool

Ora creiamo un utente abilitato a connettersi in OpenVPN:

/ppp secret add name=vpn_user password=qystQMf9TxhlVrq9vE00 profile=ovpn service=ovpn

E infine attiviamo il server OpenVPN:

/interface ovpn-server server set enabled=yes certificate=mikrotik auth=sha1 cipher=aes256 port=1194 netmask=24 require-client-certificate=no mode=ip default-profile=ovpn

A questo punto la configurazione lato Mikrotik è terminata, non ci rimane altro da fare che creare i due file di configurazione da usare sul client.

Lato client abbiamo bisogno di due file:

  • Nome_connessione.ovpn
  • auth.cfg

Nel file auth.cfg dobbiamo inserire due due righe diverse l’utente e la password che abbiamo impostato nel Mikrotik, quindi nel nostro caso conterrà queste due linee:

vpn_user
qystQMf9TxhlVrq9vE00

Il file Nome_connessione.ovpn invece conterrà questo:

proto tcp-client
remote <nome_o_indirizzo_pubblico_del_Mikrotik> 1194
dev tun
script-security 2

nobind
persist-key

tls-client
verb 1

cipher AES-256-CBC
auth SHA1
pull

auth-user-pass auth.cfg
route 192.168.0.0 255.255.255.0
dhcp-option DOMAIN dominio.local
dhcp-option DNS 192.168.0.20

<ca>
..
</ca>

Nel file dovrete mettere i vostri dati:

  • Nome o indirizzo pubblico del Mikrotik
  • La classe di IP che usate internamente per creare automaticamente una rotta
  • Il nome del dominio locale e l’IP del server DNS interno se volete risolvere i nomi
  • Nella sezione <ca></ca> dovrete incollare il contenuto del file cert_export_CA.crt che abbiamo esportato nelle fasi iniziali

Una volta effettuati queste modifiche potrete stabilire una connessione OpenVPN verso il vostro Mikrotik senza nessun problema.

Se il Mikrotik non ha un IP pubblico ma si trova dietro un NAT non dovrete far altro che nattare sul router a monte la porta TCP 1194.

 

Windows Search: Problema indicizzazione

Recentemente mi è capitato che in un File Server basato su Windows Server 2012 R12 l’indicizzazione non funzionasse più correttamente, l’indicizzazione veniva riportata come completa senza errore ma in realtà una buona parte dei file non era indicizzata.

Indexing Options

Cercando nella documentazione Microsoft ho trovato la risposta al problema, come riportato in questa pagina:

Windows Search doesn’t support Data Deduplication. Data Deduplication uses reparse points, which Windows Search can’t index, so Windows Search skips all deduplicated files, excluding them from the index. As a result, search results might be incomplete for deduplicated volumes.

In pratica succede che tutti i file oggetto di deduplica non possono essere indicizzati!!! Quidi delle due l’una o si usa la deduplica o si usa l’indicizzazione.

Nel mio caso ho dovuto disabilitare la deduplica nel volume interessato e dopo aver eseguito un rebuild da zero dell’indice tutto è tornato a funzionare correttamente.

 

Cambiare porta al Remote Desktop Web Access (RD Web Access)

L’RD Web Access (Remote Desktop Web Access) è uno strumento molto utile e si presta a molte applicazioni sia esternamente all’azienda sia internamente.

L’RD Web Access è sostanzialmente un portale che risiede su un server interno e che viene pubblicato verso l’esterno:

RDWeb

tramite questo portale l’utente può effettuare il login utilizzando le sue credenziali di Active Directory e successivamente può collegarsi in RDP a un qualunque host interno all’azienda o lanciare direttamente le applicazione installate su un server tramite RemoteApp.

RemoteApp

Il grande vantaggio dell’RD Web Access è quello di utilizzare una sola porta in ingresso, HTTPS (443), sul quale far veicolare sia le connessioni RDP internet sia le RemoteApp tramite l’RD Gateway:

RD Gateway

Il problema sorge quando abbiamo un solo indirizzo IP pubblico e magari un server Exchange che pubblica già OWA sulla porta 443, in questo caso non possiamo pubblicare l’RD Web Access con le impostazioni standard ma dobbiamo cambiare porta.

Il cambio della porta è relativo sia al portale Web Access sia alla porta usata dall’RD Gateway.

Per modificare la porta di ascolto del portale Web Access la procedura è molto semplice e consiste nel modificare il Binding del website su una porta diversa dalla 443, ad esempio 444:

Site Binding

Una volta IIS potete provare a collegarvi sulla nuova porta e dovreste riuscire a collegarvi al portale.

A questo punto dobbiamo modificare anche la porta usata dall’RD Gateway, altrimenti se provate a lanciare una RemoteApp riceverete un errore.

Per far questo aprire una console PowerShell e usate il comando:

Set-RDSessionCollectionConfiguration –CollectionName "Your Collection" -CustomRdpProperty "gatewayhostname:s:<GATEWAY.FQDN>:<Port, e.g. 9999>" -ConnectionBroker <Your Connection Broker>

questo modificherà la porta di default da 443 a quella che avete impostato.

Una volta fatto questo potete pubblicare le varie applicazioni e tutto dovrebbe funzionare senza problemi.

Quello che ci rimane da configurare è l’accesso a un PC interno, infatti se proviamo a collegarci con un PC interno tramite il tab Connect to a remote PC, otteniamo l’errore:

Remote Desktop Connection

perchè di default viene passata la porta standard (443) per l’RD Gateway. Per modificarla dobbiamo aprire IIS e modificare le Application Settings per sito RDWeb, in particolare dobbiamo impostare il parametro DefaultTSGateway con l’host e la porta corrette:

Application Settings

Microsoft Edge non si avvia

Recentemente mi è capitato di impattermi in un paio di situazioni su macchine con Windows 10 Professional e Enterprise, da clienti diversi, dove a seguito di non si sa bene quale evento Microsoft Edge smettesse di funzionare ovvero lanciandolo dall’icona si apriva per 1 o 2 sec. per poi richiudersi immediatamente dopo.

Andando ad esaminare il log degli eventi viene registrato un crash di Edge, nello specifico si possono vedere due eventi di errore:

Application Error (ID 1000)
Faulting application name: MicrosoftEdge.exe, version: 11.0.10240.16644, time stamp: 0x568b2642
Faulting module name: eModel.dll, version: 11.0.10240.16644, time stamp: 0x568b2264
Exception code: 0xc0000409
Fault offset: 0x00000000001122a3
Faulting process ID: 0x2558
Faulting application start time: 0x01d15ff2c31391e3
Faulting application path: C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\MicrosoftEdge.exe
Faulting module path: C:\Windows\SystemApps\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\eModel.dll
Report ID: 2bd852e0-d98a-48b9-9c1b-fb29e63655a1
Faulting package full name: Microsoft.MicrosoftEdge_20.10240.16384.0_neutral__8wekyb3d8bbwe
Faulting package-relative application ID: MicrosoftEdge

e

Apps (ID 5973)
Activation of application Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge failed with error: The remote procedure call failed. See the Microsoft-Windows-TWinUI/Operational log for additional information.

Il problema è dovuto al fatto che il package dell App Microsoft Edge si è corrotto, per ripristinarla basta seguire questi due passi:

  1. Cancellare il contenuto della cartella
    C:\Users\%username%\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe
  2. Aprire una console PowerShell e digitare il comando:
    Get-AppXPackage -Name Microsoft.MicrosoftEdge | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$($_.InstallLocation)\AppXManifest.xml” -Verbose}

Terminata l’esecuzione provate ad avviare Microsoft Edge, dovrebbe partire senza problemi.

UPDATE 14/10/2016

In alcune circostanze il metodo sopra non risolve il problema, recentemente mi è capitato lo stesso problema e la soluzione è stata questa:

  1. Aprire il regedit
  2. Scorrere l’albero fino alla chiave:

    HKEY_CURRENT_USER\SOFTWARE\Classes\LocalSettings\Software\Microsoft\Windows\
    CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe

  3. Tasto destro sul nome della chiave stessa
  4. Selezionare la terza voce Account Unknown(S-1-15-3-2624051433-..) 
    Regedit
  5. Selezionare Full Control per l’utente selezionato
  6. Chiudere il Regedit e provare

The New Microsoft Lumia 950 and 950 XL