Il tuo portatile raggiunge la LAN di pfSense tramite la VPN e continua a non raggiungere un servizio due hop più in là, e la differenza è una decisione di routing per proprietario. Tre dispositivi devono essere d'accordo prima che un pacchetto completi il suo viaggio di andata e ritorno: il client, il firewall e il router che possiede davvero la rete di destinazione. Se ne manca uno, il sintomo sembra identico.

Segui un pacchetto attraverso queste tre decisioni prima di cambiare una regola, perché ogni proprietario ha un controllo diverso e una modalità di guasto diversa.

Un pacchetto, tre decisioni di routing

Il client decide se la destinazione appartiene al tunnel, e può decidere solo in base a ciò che sa: una rotta inviata, una rotta locale o una rotta predefinita che già copre tutto. pfSense decide dove inviare il pacchetto successivamente, il che per una rete dietro un altro router significa una rotta statica attraverso un gateway raggiungibile sull'interfaccia corretta. Il router a valle decide se conosce un percorso di ritorno al pool della VPN, e se non lo conosce la risposta viene scartata o inviata in un posto inutile. Ogni decisione è indipendente dalle altre due.

Il guasto di una qualsiasi di esse produce lo stesso resoconto dell'utente. Per questo l'ordine di debug conta più degli strumenti.

Dai al client un prefisso, non una supposizione

Su un server pfSense SSL/TLS con una rete tunnel IPv4 più grande di un /30, il campo IPv4 Local network(s) distribuisce le rotte ai client quando si connettono. Aggiungi lì il prefisso a valle invece di contare sul fatto che il client ne inventi uno. Poi leggi la tabella reale del client dopo la connessione, perché un profilo con route-nopull o un filtro di rotte può ignorare ciò che il server ha inviato. Il server può essere perfettamente corretto mentre il client non installa nulla.

Altri modi del server e topologie hanno limiti diversi, e una politica per client o per connessione può cambiare ciò che riceve un client specifico. Verifica sul client che conta, non su quello che hai provato per primo per caso.

Punta pfSense al router interno

Una rotta statica in pfSense richiede un gateway definito e raggiungibile, e l'interfaccia scelta per quel gateway deve essere quella che lo raggiunge davvero, come descrive la guida alle rotte statiche di Netgate. In una disposizione illustrativa il collegamento di transito è 192.168.77.1 sul firewall e 192.168.77.2 sul router interno, con la rete dei servizi a 172.16.30.0/25 dietro. La rotta allora nomina il prefisso e il prossimo hop, non l'indirizzo del servizio. Usare un indirizzo della rete remota come gateway è un modo comune di costruire una rotta che sembra corretta e non inoltra da nessuna parte.

Dare un nome a un'interfaccia non descrive le reti oltre di essa. La rotta statica è quella descrizione.

Il lato remoto deve conoscere il pool

Il router a valle ha bisogno di una rotta di ritorno per il pool, in questo esempio 10.55.0.0/24 via 192.168.77.1, a meno che una rotta predefinita o un protocollo dinamico ne fornisca già una. Il gateway dell'host del servizio stesso deve portare verso quel router, il che è normalmente vero quando il router è il suo gateway predefinito e falso quando l'host è stato configurato a mano. Il routing per policy sul firewall può anche ignorare la tabella per traffico specifico, quindi controlla se una regola seleziona un gateway diverso prima di concludere che la rotta è sbagliata.

Questa progettazione non richiede traduzione, e mantenere visibile l'indirizzo di origine del client permette alla rete a valle di applicare la propria politica.

Per l'accettazione, segui una richiesta nuova attraverso l'ingresso del tunnel, l'uscita interna del firewall e la risposta dalla destinazione. Se invece si usa deliberatamente la traduzione, annota quale origine vede la rete a valle e come ci si aspetta che torni la risposta.

Salva il piano dei tre proprietari accanto all'applicazione consentita, così il prossimo amministratore può ricostruire il percorso invece di riscoprirlo.

Articoli correlati