Tunneling di un IP pubblico a una macchina remota

Ho un server Linux A con un block di 5 indirizzi IP pubblici, 8.8.8.122/29 . Attualmente, 8.8.8.122 è assegnato a eth0 e 8.8.8.123 è assegnato a eth0:1 .

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

  • La connessione VPN fa sì che il DNS utilizzi un server DNS sbagliato
  • È ansible chiudere un socket con un command di shell?
  • C'è una soluzione per eseguire l'authentication OpenVPN con Google ID?
  • Come rendere httpd accessibile solo attraverso la VPN?
  • Tunnel VPN tramite IPSec
  • Suggerimenti e suggerimenti Indirizzo IP Re-Addressing?
  • OpenVPN è probabilmente la risposta, ma non riesco piuttosto a capire come impostare le cose ( topology subnet topology p2p o topology p2p potrebbe essere appropriata oppure dovrei utilizzare l'over Ethernet bridge?). La sicurezza e la crittografia non sono una grande preoccupazione a questo punto, quindi GRE sarebbe andata bene – la macchina B verrà da un indirizzo IP noto e può essere autenticato in base a questo.

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

    2 Solutions collect form web for “Tunneling di un IP pubblico a una macchina remota”

    Ho finito per andare con il ponte Ethernet. Un sacco di esempi estremamente esaurienti per passare attraverso online, ma risulta essere abbastanza facile:

    In primo luogo, su A , /etc/network/interfaces stato modificato da:

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

    a:

     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 colbind eth0 (l'interface reale WAN) con tap0 (una nuova interface tunnel) all'avvio.

    Quindi, su A , eseguire il server openvpn con:

     openvpn --dev tap0 

    Su B , collegatelo 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 configuration super semplice che stavo cercando e funziona – B è ora accessibile al pubblico a 8.8.8.123, e le connessioni in output derivano dallo stesso indirizzo.

    Aggiungi sicurezza ( --secret , --tls-server , ecc.) Come necessario, naturalmente.

    Avrai difficoltà a pensare. La maggior parte dei firewall avrà difficoltà a instradare il traffico OpenVPN se entrambi i lati della VPN sono nella stessa substring.

    Se stai tentando di percorrere l'accesso pubblico, spingo entrambi i server in sottoreti diversi dagli indirizzi pubblici e quindi utilizzo IP virtuali (da 1 a 1 Nat) per collegarli. Per colbind i due siti, OpenVPN functionrebbe o un tunnel IP-Sec.

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

    Sito al sito: http://doc.pfsense.org/index.php/VPN_Capability_IPsec

    Modifica in base ai commenti:

    Personalmente installerei pfSense sulla casella A e darti la port che volevi per la sua WAN. Quindi impostare un server OpenVPN su una substring locale (che è tutto pronto per l'interface web pfSense) e impostare l'altra macchina con un IP virtuale puntato al suo OpenVPN ip locale. Questo vi permetterà di espandere più tardi (aggiungere più macchine con IP virtuali, spedire in modo logico le porte specifiche a diversi server, avere una configuration LAN / WAN / DMZ piena con OpenVPN per l'accesso virtuale. router pieno soffiato così sarebbe probabilmente più sicuro.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.