Il server VPN Windows può comunicare con i client VPN, ma non invierà pacchetti dalla sua rete locale ai client VPN

Voglio configurare Windows Server 2012 e i suoi client VPN Windows 7 e Windows 8, con una VPN SSTP che utilizza il tunneling diviso e l'indirizzamento off-subnet, ma sto riscontrando un problema: il server RRAS non invierà pacchetti alla VPN clienti da qualsiasi macchina diversa da se stessa.

Il mio server VPN è in esecuzione sul "Virtual Private Cloud" di Amazon, quindi ha solo una scheda NIC con un indirizzo IP su una rete privata RFC1918 condivisa con tutti gli altri miei server Amazon VPC e un IP pubblico che inoltra tutto il traffico a quell'indirizzo privato tramite NAT (Amazon chiama questo "IP elastico").

Ho installato RRAS e impostato una VPN. La sottorete privata su Amazon è 172.16.0.0/17 (questo è ciò che io chiamo "Amazon LAN"), ma voglio che tutti i client VPN utilizzino l'intervallo 10.128.0.0/20 (ciò che io chiamo " VPN LAN ").

Nel mio pannello di controllo di Amazon, ho fatto quanto segue:

• Disabilitato il controllo di origine / destinazione per il server VPN
• Aggiunta una voce nelle tabelle di instradamento per il pool 10.128.0.0/20 che punta all'interfaccia di rete del server VPN.

All'interno del MMC Routing e Accesso remoto, all'interno del menu delle proprietà per il nome del server, ho fatto quanto segue:

• Scheda Generale -> Router IPv4 (selezionato), abilitato per LAN e routing con connessione a richiesta
• Scheda Generale -> Server di accesso remoto IPv4 (selezionato)
• Scheda IPv4 -> Abilita inoltro IPv4 (selezionato)
• Scheda IPv4 -> Pool di indirizzi statici e specificare 10.128.0.1-10.128.15.154

Sul mio client e su tutti i miei server, mi sono assicurato che ICMP sia esplicitamente consentito nel firewall o che il firewall sia completamente disabilitato (ovviamente non con il piano permanente).

Sul client, per abilitare il tunneling diviso, sono andato alle proprietà per la connessione VPN -> Rete -> IPv4 -> Proprietà -> Avanzate -> scheda Impostazioni IP e deselezionato "Usa gateway predefinito su rete remota", e spuntato "Disabilita aggiunta rotta basata sulla classe".

A questo punto, i miei client possono connettersi utilizzando il client VPN Windows 7/8. A loro viene assegnato un IP dal pool 10.128.0.0/20, ma poiché non impostano automaticamente alcuna route, non possono comunicare con la rete remota. Posso impostare percorsi verso la rete remota e verso la rete VPN, in questo modo (sul client):

route add 172.16.0.0/17 <VPN IP ADDRESS> 
route add 10.128.0.0/20 <VPN IP ADDRESS> 

Ora il client può eseguire il ping dell'indirizzo LAN VPN del server VPN (10.128.0.1) e anche l'indirizzo LAN Amazon (172.16.1.32). Si verifica tuttavia un problema quando si tenta di parlare con altre macchine sulla LAN di Amazon: i ping non ricevono risposte.

Quindi, ad esempio, se il client tenta di eseguire il ping di un sistema che so essere attivo e risponde a ping come 172.16.0.113, non vedrà quelle risposte (dice "Richiesta scaduta"). Wireshark sul server VPN conferma che vede il ping dal client e vede persino una risposta inviata dal 172.16.0.113, ma quella risposta apparentemente non lo fa mai tornare al client.

Inoltre, se eseguo il ping dell'indirizzo LAN VPN del client da 172.16.0.113, Wireshark sul server VPN vede il ping, ma non vede una risposta.

Quindi, per ricapitolare:

• Il server VPN può eseguire il ping di altre macchine sulla LAN di Amazon (172.16.0.0/17) e ricevere risposte, e altre macchine su quella rete possono fare lo stesso con essa.
• Un client VPN può eseguire il ping dell'indirizzo Amazon LAN del server e ricevere risposte, dopo che i client hanno aggiunto il percorso corretto come descritto in precedenza.
• Un client VPN può eseguire il ping dell'indirizzo LAN VPN del server 10.128.0.1 e il server VPN può eseguire il ping dell'indirizzo LAN VPN del client nell'intervallo 10.128.0.0/20, dopo che il client aggiunge il percorso corretto del percorso come descritto in precedenza.
• Un client VPN può inviare ping a una macchina sulla LAN di Amazon, ma quando tali macchine inviano risposte, si fermano sul server VPN - non vengono inoltrati al client, dando luogo a messaggi "Richiesta scaduta" sul client . Al contrario, quando una macchina sulla LAN di Amazon tenta di eseguire il ping dell'indirizzo LAN VPN 10.128.0.0/20 del client, il server VPN vede il ping, ma il client non lo fa mai e quindi non genera una risposta.

Perché il server VPN non sta inviando pacchetti dalla LAN di Amazon ai suoi client sulla LAN VPN? Può sicuramente parlare con i client sulla LAN VPN e il routing è abilitato ed è disposto a instradare i pacchetti dalla LAN VPN -> Amazon LAN, ma non viceversa. Cosa mi sto perdendo qui?

Itinerari

Ecco le tabelle di routing da un client VPN. Il client è una VM VirtualBox che esegue Windows 8. L'indirizzo IP dell'adattatore vbox è 10.0.2.15 su a / 24. Questo client è dietro NAT (in realtà, è dietro double-NAT, perché l'adattatore vbox è NAT'd per la mia rete locale, che è NAT'd per Internet). Questa tabella di instradamento proviene da dopo aver aggiunto manualmente gli instradamenti a 10.128.0.0/20 e 172.16.0.0/17.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.0.2.2        10.0.2.15     10
         10.0.2.0    255.255.255.0         On-link         10.0.2.15    266
        10.0.2.15  255.255.255.255         On-link         10.0.2.15    266
       10.0.2.255  255.255.255.255         On-link         10.0.2.15    266
       10.128.0.0    255.255.240.0         On-link        10.128.0.3     15
       10.128.0.3  255.255.255.255         On-link        10.128.0.3    266
    10.128.15.255  255.255.255.255         On-link        10.128.0.3    266
    54.213.67.179  255.255.255.255         10.0.2.2        10.0.2.15     11
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
       172.16.0.0    255.255.128.0         On-link        10.128.0.3     15
   172.16.127.255  255.255.255.255         On-link        10.128.0.3    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link         10.0.2.15    266
        224.0.0.0        240.0.0.0         On-link        10.128.0.3    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link         10.0.2.15    266
  255.255.255.255  255.255.255.255         On-link        10.128.0.3    266
===========================================================================
Persistent Routes:
  None

Ecco le tabelle di routing dal server RRAS, che esegue Windows Server 2012. Questo server è anche dietro NAT, come discusso sopra. Ha solo una scheda di rete. Il suo indirizzo IP privato è 172.16.1.32, su un / 23 (che è esso stesso parte di una rete più grande / 17; credo sia giusto ignorare le parti del / 17 al di fuori del / 23, poiché altre macchine sul / 23 non può raggiungere o essere raggiunto neanche dai client VPN).

L'adattatore virtuale VPN ha un proprio indirizzo, 10.128.0.1, che viene assegnato automaticamente alla prima connessione di un client. Le route per 10.128.0.1 (a se stesso) e 10.128.0.2 (al suo unico client) che vedi vengono anch'esse aggiunte automaticamente in quel momento. Nessuna route viene aggiunta manualmente al server VPN.

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.0.1      172.16.1.32     10
       10.128.0.1  255.255.255.255         On-link        10.128.0.1    286
       10.128.0.2  255.255.255.255       10.128.0.2       10.128.0.1     31
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  169.254.169.250  255.255.255.255       172.16.0.1      172.16.1.32     10
  169.254.169.251  255.255.255.255       172.16.0.1      172.16.1.32     10
  169.254.169.254  255.255.255.255       172.16.0.1      172.16.1.32     10
       172.16.0.0    255.255.254.0         On-link       172.16.1.32     11
      172.16.1.32  255.255.255.255         On-link       172.16.1.32    266
     172.16.1.255  255.255.255.255         On-link       172.16.1.32    266
       172.16.2.0    255.255.254.0      172.168.0.1      172.16.1.32     11
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       172.16.1.32    266
        224.0.0.0        240.0.0.0         On-link        10.128.0.1    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       172.16.1.32    266
  255.255.255.255  255.255.255.255         On-link        10.128.0.1    286
===========================================================================
Persistent Routes:
  None

Ecco le tabelle di routing per un altro computer sulla rete privata del server, che esegue anche Server 2012. Ha una scheda NIC, che ha un indirizzo IP privato 172.16.1.177, il che significa che è sul server / 23 che si trova sullo stesso server VPN. (Si noti che il percorso per 10.128.0.0/20 è impostato sul gateway, che è controllato da Amazon, quindi non lo vedrai qui. Ho aggiunto il percorso corretto ad Amazon, evidenziato dal fatto che Wireshark sul Il server VPN vede i pacchetti.)

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       172.16.0.1     172.16.1.177     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  169.254.169.250  255.255.255.255       172.16.0.1     172.16.1.177     10
  169.254.169.251  255.255.255.255       172.16.0.1     172.16.1.177     10
  169.254.169.254  255.255.255.255       172.16.0.1     172.16.1.177     10
       172.16.0.0    255.255.254.0         On-link      172.16.1.177    266
     172.16.1.177  255.255.255.255         On-link      172.16.1.177    266
     172.16.1.255  255.255.255.255         On-link      172.16.1.177    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      172.16.1.177    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      172.16.1.177    266
===========================================================================
Persistent Routes:
  None

Ecco i percorsi nella console di Amazon. Penso che questi siano corretti - il traffico sta tornando al server VPN, dopo tutto, solo per scomparire al suo interno - ma nel caso qualcuno voglia vederli, eccoli qui. (Amazon fa le cose un po 'strane. Si eni-2f3e8244 / i-77e26440riferisce alla scheda NIC sul server VPN e si igw-d4bc27bcriferisce al NAT / gateway Internet controllato da Amazon che tutte le mie istanze usano per parlare con Internet.)

10.128.0.0/20   eni-2f3e8244 / i-77e26440   
172.16.0.0/17   local   
0.0.0.0/0       igw-d4bc27bc

Che cosa succede se aggiungi una route statica sui tuoi server dicendo loro che per raggiungere 10.128.0.0/20 devono passare attraverso l'indirizzo LAN del server VPN?

route add 10.128.0.0 mask 255.255.240.0 a.b.c.d

Sostituire abcd con l'indirizzo LAN del server VPN.

Questo, almeno, escluderà problemi con il routing di Amazon.