eapol_test su una VPN: lo scambio RADIUS richiede il livello 2?
eapol_test esegue peer e client RADIUS in un solo processo, quindi una VPN instradata trasporta UDP 1812. Controllate l'elenco dei metodi compilato, poi provate l'accesso reale separatamente.
Chiedete una porta di switch di laboratorio per poter eseguire eapol_test e probabilmente avete frainteso lo strumento. Il peer e il client RADIUS vivono entrambi dentro quell'unico binario, quindi l'unica conversazione che lascia la macchina è lo scambio RADIUS stesso. Un tunnel instradato tra l'host di test e il server di autenticazione è l'intero requisito di rete. Il percorso fisico 802.1X è un'altra cosa che potreste dover ancora testare, e non è questa.
Perché il nome spinge a cercare una porta di switch
EAPOL è il formato di trama che un supplicant e uno switch usano su una LAN, e lo strumento prende in prestito il nome perché è cresciuto da quel mondo. Ciò che viene distribuito è un programma di test che porta la macchina a stati del peer e il client RADIUS in un solo processo, quindi le due metà di una conversazione 802.1X non si incontrano mai su un cavo. Il nome è storia, non un requisito di topologia.
Le persone chiedono ancora la porta perché il programma si basa sul comportamento di un autenticatore, e questo suona come hardware. La sua colla riproduce la macchina a stati dell'autenticatore, quindi un test si completa senza alcun punto di accesso nella stanza; il binario compilato collega il peer EAP di wpa_supplicant al client RADIUS di hostapd. Togliere lo switch toglie il salto EAPOL, non la logica di autenticazione. Ciò che resta è uno scambio client-server tra due host IP.
Seguite uno scambio RADIUS salto per salto
Seguite un solo tentativo e il percorso è breve. Il peer dentro eapol_test produce una EAP-Response per il metodo che avete configurato, e il client RADIUS nello stesso processo la mette in una Access-Request, portando il carico utile in attributi EAP-Message accanto a un Message-Authenticator. Quel datagramma è indirizzato al server sulla porta UDP 1812 e lascia l'host come qualsiasi altro pacchetto IP, ed è lì che entra il tunnel. Il server lo valuta secondo la sua politica e i suoi moduli di metodi, poi risponde con Access-Challenge, Access-Accept o Access-Reject.
eapol_test -c peap-mschapv2.conf -a 198.51.100.20 -p 1812 \
-s REPLACE_WITH_RADIUS_SECRET -t 30Il binario prende l'indirizzo del server, la porta e il segreto condiviso dalla riga di comando, e il metodo e le credenziali da un blocco di configurazione in stile wpa_supplicant. Nulla in quella chiamata dipende da un'adiacenza di livello 2: -a si raggiunge per instradamento, e basta una VPN che lo instradi. Se il tunnel scarta il datagramma, il test fallisce esattamente come contro un server irraggiungibile su una LAN piatta.
Il binario e la politica del server sono elenchi diversi
Due elenchi indipendenti decidono se un metodo può passare, e confonderli costa una giornata. Il primo elenco è compilato nel binario: la configurazione di build sceglie quali metodi EAP esistono, quindi una build senza un metodo non può negoziarlo qualunque cosa il server consenta. Il secondo elenco vive sul server, dove la politica dice quali dei metodi supportati questa classe di client può usare. Per passare serve un'intersezione, e nessun elenco può colmare una lacuna nell'altro.
Controllate quel primo elenco prima di dare la colpa al server. Cercate il nome del metodo nel binario installato o leggete la configurazione di build da cui proviene. Se il metodo manca, ricompilate invece di modificare la politica RADIUS; se è presente e lo scambio fallisce ancora, il problema si è spostato su credenziali, politica o fiducia nel certificato.
Cosa non copre ancora un superamento
Un'esecuzione riuscita dimostra un metodo, per un insieme di credenziali, contro una politica RADIUS, su un percorso di rete. Non esercita la radio del punto di accesso, la gestione EAPOL di uno switch, l'assegnazione di VLAN che segue l'autenticazione, né il modo in cui un concentratore VPN si integra con lo stesso server. Quei componenti non sono mai stati sul percorso testato. Trattate il risultato come prova limitata e dite quale limite copre quando lo riportate.
Il registro utile è ciò che il server e il processo hanno osservato ciascuno: quale metodo è stato negoziato, dove lo scambio si è fermato e cosa ha registrato il server. Tenete segreti condivisi e chiavi private fuori da quel registro.
Lista di controllo prima di citare il risultato
Prima che qualcuno tratti l'output come un'approvazione, confermate quattro cose. La build include il metodo in prova, l'endpoint RADIUS e il segreto condiviso appartengono all'ambiente in prova, la politica del server ammette questa identità di test e il percorso di rete è della stessa classe di quello usato dai client di produzione. Poi nominate ciò che l'esecuzione non ha toccato: punto di accesso, switch, VLAN e integrazione del concentratore hanno ciascuno bisogno della propria riga nel piano di test.
Due test con due responsabili battono un'approvazione ambigua. L'esecuzione di eapol_test risponde alla domanda del metodo e del server; il servizio di accesso risponde alla domanda dell'applicazione.