Server VPN Mac OS X 10.8: ignora VPN per il traffico LAN (instradamento del traffico LAN alla connessione secondaria)


10

Ho una configurazione un po 'strana per un server VPN con OS X Mountain Lion. Essenzialmente viene utilizzato come un ponte per bypassare il firewall della mia azienda alla nostra connessione Extranet - alcune cose che il nostro team deve fare richiede l'accesso illimitato all'esterno e cambiare i criteri IT per consentire il traffico attraverso il firewall principale non è un'opzione.

La connessione extranet viene fornita tramite un router Wireless-N (chiamiamolo Wi-Fi X). Il mio server Mac Mini è configurato con la connessione a questo router come connessione principale, quindi accesso illimitato a Internet tramite il router. Le connessioni a questo dispositivo sulla sottorete immediata sono possibili attraverso la porta LAN, ma al di fuori della sottorete le cose sono meno affidabili.

Sono stato in grado di configurare il server VPN per fornire indirizzi IP ai client nell'intervallo 192.168.11.150-192.168.11.200 utilizzando sia PPTP che L2TP e sono in grado di connettermi all'extranet tramite la VPN utilizzando la VPN standard di Mac OS X client in Preferenze di Sistema, anche se non sorprende che un indirizzo locale (chiamiamolo internal.company.com) non restituisca nulla.

Ho provato a bypassare la limitazione del server VPN impostando Rotte nelle impostazioni VPN. La nostra azienda utilizza 13.xxx per tutto il traffico interno, anziché 10.xxx, quindi la tabella di routing era simile alla seguente:

IP Address ---------- Subnet Mask ---------- Configuration
0.0.0.0               248.0.0.0              Private
8.0.0.0               252.0.0.0              Private
12.0.0.0              255.0.0.0              Private
13.0.0.0              255.0.0.0              Public
14.0.0.0              254.0.0.0              Private
16.0.0.0              240.0.0.0              Private
32.0.0.0              224.0.0.0              Private
64.0.0.0              192.0.0.0              Private
128.0.0.0             128.0.0.0              Private

Avevo l'impressione che se non fosse stato inserito nulla qui, tutto il traffico veniva instradato attraverso la VPN. Con qualcosa inserito, solo il traffico specificamente contrassegnato per passare attraverso la VPN passerebbe attraverso la VPN e tutto il resto del traffico spetterebbe al client per accedere utilizzando la propria connessione predefinita. Questo è il motivo per cui ho dovuto contrassegnare in modo specifico ogni sottorete tranne 13.xxx come privato.

Il mio sospetto è che dal momento che non riesco a raggiungere il server VPN dall'esterno della sottorete locale, non sta effettuando una connessione al server DNS principale e quindi non può essere raggiunto su una rete più grande. Sto pensando che l'immissione di nomi host come internal.company.com non venga respinta dal client per la risoluzione, perché il server non ha idea che l'indirizzo IP rientri nell'intervallo pubblico, dal momento che sospetto (probabilmente dovrebbe eseguire il ping ping ma non possono accedervi in ​​questo momento) che non può raggiungere il server DNS per scoprire qualcosa su quel nome host.

Mi sembra che tutte le mie opzioni per risolvere tutto si riducano allo stesso tipo di soluzione:

Scopri come raggiungere il DNS con la connessione secondaria sul server. Sto pensando che se sono in grado di fare [qualcosa] per far riconoscere al mio server che dovrebbe anche controllare il mio gateway locale (diciamo IP del server == 13.100.100.50 e IP del gateway == 13.100.100.1). Da lì l'IP gateway può dirmi di andare a trovare il server DNS al 13.1.1.1 e darmi informazioni sulla mia rete interna. Sono molto confuso su questo percorso - davvero non sono sicuro che abbia persino senso.

Ho pensato di provare a fare questo lato client, ma non ha nemmeno senso, dal momento che ciò aggiungerebbe tempo a ciascuna configurazione lato client. Inoltre, sembra più logico risolverlo sul server - potrei o liberarmi del tutto dalla mia tabella di routing o tenerlo - penso che l'unica differenza sarebbe che il traffico interno passerebbe anche attraverso il server - probabilmente un onere inutile per esso.

Qualche aiuto là fuori? O sono sopra la mia testa? Anche il proxy forward o proxy trasparente è un'opzione per me, anche se non ho idea di come impostare uno di questi. (Lo so, Google è mio amico.)


forse questo altro post può essere di aiuto: superuser.com/questions/453766/…
Lorenzo Von Matterhorn

Risposte:


2

Bene, ci provo:

Non sono sicuro di come ottenere solo un po 'di traffico per poter risolvere il tuo problema, ma ci vorrebbe un piccolo cambiamento della tua configurazione. Suppongo che il tuo Mac abbia due interfacce di rete, chiamiamole eth0 ed eth1 :-)

supponiamo che eth0 sia connesso alla tua rete di lavoro e abbia un indirizzo interno (rete di lavoro) di 13.1.1.6, sottorete 255.0.0.0.

supponiamo anche che eth1 sia connesso al tuo WiFi X e abbia un indirizzo (eth1 <---> rete WiFi X) di 192.168.1.10, sottorete 255.0.0.0, per semplificare le cose.

Ho configurato server VPN su BSD e Linux, ma non su Mac, tuttavia il concetto sarà sempre lo stesso, hai opzioni, ne elencherò uno:

1) Assicurati che la tabella di routing sul Mac abbia una voce come segue:

$>sudo route add 13.0.0.0/8 eth0

Quello che farà è assicurarsi che tutto il traffico in arrivo sull'interfaccia WiFi X o VPN destinato alla rete della tua azienda (la rete 13) lo farà lì. Senza questo, il Mac (che fornisce il bridge) non ha davvero modo di sapere come instradare il traffico tra le due interfacce e per impostazione predefinita proverà a inviarlo da qualsiasi interfaccia sia quella predefinita, che è WiFi X che hai dichiarato.

Annullerei ciò che hai fatto alla tabella di routing VPN sopra e proverei questo se non è (si spera) già lì.

Se quanto sopra non lo fa, ti preghiamo di aggiornare con la tabella di routing e l'elenco degli indirizzi IP del tuo server VPN o aggiornare con qualsiasi correzione che hai riscontrato. Spero che questo ti indichi nella giusta direzione.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.