Tunneling di un IP pubblico su una macchina remota


8

Ho un server Linux Una con un blocco di 5 indirizzi IP pubblici, 8.8.8.122/29. Attualmente 8.8.8.122è assegnato a eth0ed 8.8.8.123è assegnato a eth0:1.

Ho un'altra macchina Linux B in una posizione remota, dietro NAT. Vorrei impostare un tunnel tra i due in modo che B possa utilizzare l'indirizzo IP 8.8.8.123come indirizzo IP primario.

OpenVPN è probabilmente la risposta, ma non riesco proprio a capire come impostare le cose ( topology subneto topology p2ppotrebbe essere appropriato. O dovrei usare il bridging Ethernet?). La sicurezza e la crittografia non sono un grosso problema a questo punto, quindi anche GRE andrebbe bene - la macchina B proviene da un indirizzo IP noto e può essere autenticata in base a quello.

Come posso fare questo? Qualcuno può suggerire una configurazione OpenVPN, o qualche altro approccio, che potrebbe funzionare in questa situazione? Idealmente, sarebbe anche in grado di gestire più client (ad es. Condividere tutti e quattro gli IP di riserva con altre macchine), senza consentire a quei client di utilizzare IP a cui non hanno diritto.


Quali sono i firewall in entrambe le posizioni?
Robert,

1
Spero che tu abbia appena inventato quegli indirizzi, piuttosto che lavorare effettivamente su Google. In caso contrario, non sarai in grado di utilizzare il loro spazio degli indirizzi.
Michael Hampton,

Robert: A è un server Linux con alcune semplici iptablesregole. B è dietro un NAT che è un altro server Linux in esecuzione shorewall.
Jim Paris,

Michael: Sì, ho cambiato i primi tre ottetti in 8 per offuscarli, ma indico ancora che sono pubblici. Siamo spiacenti, Google.
Jim Paris,

1
Per riferimento futuro, abbiamo un RFC per questo .
Michael Hampton,

Risposte:


7

Ho finito per andare con il bridging Ethernet. Molti esempi estremamente dettagliati da approfondire online, ma risulta essere abbastanza semplice:

Innanzitutto, su A , è /etc/network/interfacesstato modificato da:

auto eth0
iface eth0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121

per:

auto br0
iface br0 inet static
    address 8.8.8.122
    netmask 255.255.255.248
    gateway 8.8.8.121
    pre-up openvpn --mktun --dev tap0
    bridge_ports eth0 tap0
    bridge_fd 3

per eseguire il bridge eth0(la vera interfaccia WAN) con tap0(una nuova interfaccia tunnel) all'avvio.

Quindi, su A , esegui il server openvpn con:

openvpn --dev tap0

Su B , connettiti ad esso con:

openvpn --remote 8.8.8.122 --dev tap0 --route-gateway 8.8.8.121 \
        --redirect-gateway def1 --ifconfig 8.8.8.123 255.255.255.248

Questa è la configurazione super semplice che stavo cercando e funziona: B è ora pubblicamente accessibile a 8.8.8.123 e le connessioni in uscita provengono dallo stesso indirizzo.

Aggiungere la sicurezza ( --secret, --tls-server, ecc), se necessario, naturalmente.


Bello! Ci proverò. Hai trovato un modo per configurarlo: "senza lasciare che quei client usino gli IP a cui non hanno diritto"?
Bastian,

Non mi sono preoccupato della mia configurazione (che era temporanea), ma immagino che tu possa farlo con ebtables.
Jim Paris,

Molto utile. Una domanda: cosa devo cambiare in una configurazione se devo indirizzare due IP da A: A => B e A => C (dove C è un altro host)? Devo configurare un altro bridge?
Frhack,

2
Si. Aggiungere un'altra pre-up openvpnlinea per creare tap1troppo, aggiungere tap1a bridge_ports, ed eseguire un'altra istanza di OpenVPN con openvpn --dev tap1.
Jim Paris,

Che ne dite se voleste rendere locale il gateway di A tramite B in modo che qualsiasi sistema sulla LAN possa usare B e assegnare il gateway predefinito remoto e utilizzare IP pubblici?
Areeb Soo Yasir

1

Penso che avrai delle difficoltà. La maggior parte dei firewall avrà difficoltà a instradare il traffico OpenVPN se entrambi i lati della VPN si trovano nella stessa sottorete.

Se stai cercando di instradare per l'accesso pubblico, sposterei entrambi i server su diverse subnet dai tuoi indirizzi pubblici e quindi utilizzerei IP virtuali (da 1 a 1 Nat) per collegarli. Per connettere i due siti, OpenVPN funzionerebbe o un tunnel IP-Sec.

IP virtuali: http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F

Da sito a sito: http://doc.pfsense.org/index.php/VPN_Capability_IPsec

Modifica in base ai commenti:

Installerei personalmente pfSense sulla casella A e gli darei la porta che volevi per la sua WAN. Quindi configurare un server OpenVPN su una sottorete locale (che è tutto pronto per andare nell'interfaccia web pfSense) e configurare l'altra macchina con un IP virtuale puntato al suo IP OpenVPN locale. Questo ti darebbe spazio per l'espansione in seguito (aggiungere più macchine con IP virtuali, inoltrare logicamente porte specifiche a server diversi, avere davvero una configurazione LAN / WAN / DMZ completa con OpenVPN per l'accesso virtuale. Per non parlare del fatto che avresti un router in piena regola, quindi sarebbe probabilmente più sicuro.


Non capisco come siano coinvolti i firewall intermedi; certamente non saranno alla ricerca all'interno dei pacchetti OpenVPN tra A e B . Per la stessa configurazione OpenVPN, mi aspettavo che qualcosa del genere push "route 50.7.19.122 255.255.255.255 net_gateway"avrebbe assicurato che i dati VPN fossero ancora trasferiti sulla rete normale.
Jim Paris,

Per essere chiari, voglio creare un tunnel direttamente tra A e B , non su firewall separati a ciascuna estremità.
Jim Paris,

1
Ma quando il computer A vuole instradare al computer B non saprà se dovrebbe usare la WAN (con i tuoi IP pubblici), la LAN (con il suo IP statico) o OpenVPN (anche con i tuoi IP pubblici) perché sono tutti stessa sottorete. Da B ad A dovrebbe funzionare comunque.
Robert,

1
Inoltre c'è questo, l'ho fatto funzionare ma non con IP pubblici. Penso che l'IP virtuale sarà molto meglio in entrambi i casi. openvpn.net/index.php/open-source/documentation/miscellaneous/…
Robert

"Per essere chiari, voglio creare un tunnel direttamente tra A e B, non su firewall separati ad ogni estremità." Dovrai aprire una porta da qualche parte per un server OpenVPN
Robert,
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.