☰

IPSec auf OpenVZ mehrere IP-Adressen, Verwendung von 127.0.0.2 auf venet0

tag-icon • tag-icon ipsec openvz
IPSec auf OpenVZ mehrere IP-Adressen, Verwendung von 127.0.0.2 auf venet0

Ich habe eine OpenVZ-Box mit aktiviertem IPSec.

root@wa000:~# ipsec verify
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                 [OK]
Linux Openswan U2.6.38/K2.6.32-042stab094.7 (netkey)
Checking for IPsec support in kernel                            [OK]
 SAref kernel support                                           [N/A]
 NETKEY:  Testing XFRM related proc values                      [OK]
    [OK]
    [OK]
Checking that pluto is running                                  [OK]
 Pluto listening for IKE on udp 500                             [OK]
 Pluto listening for NAT-T on udp 4500                          [OK]
Two or more interfaces found, checking IP forwarding            [FAILED]
Checking NAT and MASQUERADEing                                  [OK]
Checking for 'ip' command                                       [OK]
Checking /bin/sh is not /bin/dash                               [WARNING]
Checking for 'iptables' command                                 [OK]
Opportunistic Encryption Support                                [DISABLED]

Ich habe OpenSwan und XL2TPD für L2TP VPN installiert. Wenn ich IPSec neu starte:

# service ipsec restart
ipsec_setup: Stopping Openswan IPsec...
ipsec_setup: Starting Openswan IPsec U2.6.38/K2.6.32-042stab094.7...
ipsec_setup: multiple ip addresses, using  127.0.0.2 on venet0

Es wurde erkannt 127.0.0.2, was meiner Meinung nach eine lokale IP-Adresse ist, die bedient werden soll. Ich möchte, dass es über meine öffentliche IP-Adresse bedient wird. Aber ich habe keine Ahnung, wie ich IPSec über die richtige IP bedienen kann. Ich habe gegoogelt, aber nichts scheint wirklich hilfreich zu sein.

Hier ist die ifconfig -aAusgabe. Ich habe die tatsächlichen IPs durch xxxx, yyyy und zzzz ersetzt

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:18:51:69:44:e6  
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gre0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          NOARP  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

gretap0   Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          BROADCAST MULTICAST  MTU:1476  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:118 errors:0 dropped:0 overruns:0 frame:0
          TX packets:118 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:18229 (18.2 KB)  TX bytes:18229 (18.2 KB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:127.0.0.2  P-t-P:127.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:126133 errors:0 dropped:0 overruns:0 frame:0
          TX packets:102937 errors:0 dropped:724 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:11322355 (11.3 MB)  TX bytes:40737353 (40.7 MB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:x.x.x.x  P-t-P:x.x.x.x  Bcast:x.x.x.x  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

venet0:1  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:y.y.y.y  P-t-P:y.y.y.y  Bcast:y.y.y.y  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

venet0:2  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:z.z.z.z  P-t-P:z.z.z.z  Bcast:z.z.z.z  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1

Antwort1

  1. Sie haben es nicht angegeben, aber aus Ihrem ifconfig -aAuszug können wir davon ausgehen, dass Sie IPSec in OpenVZ VE und nicht in einem Hardwareknoten (HN) ausführen. Nur um sicherzugehen – haben Sie sich derenEmpfehlungfür diese Art von Aufbau?
  2. Die Vorlagen von OpenVZ für VEs sind manchmal wirklich umwerfend. Ich habe die Entwickler gefragt, warum man IPs im Bereich 127/8 auf Nicht-Loopback-Schnittstellen verwenden sollte, aber ihre Antwort war: „Nun, wir wissen es nicht, jemand anderes hat es hinzugefügt und es ist jetzt veraltet.“ Absoluter Blödsinn. Sie können diesen 127.0.0.2-„Kludge“ sicher von der betreffenden Schnittstelle entfernen, er bewirkt nichts: ip ad del 127.0.0.2/32 dev venet0. Das Problem ist jedoch, dass dieser alberne Mist bei jedem Neustart des VE erneut hinzugefügt wird. Wenn Sie den Hardwareknoten steuern, können Sie die Vorlage auf etwas einstellen, das ihren „Kludge“ mit der Netzwerkkonfiguration nicht auslöst. Wenn Sie ihn nicht steuern, besteht die Problemumgehung darin, dieses „ip ad del“ in etwas wie „ip ad del“ zu setzen /etc/rc.localund dann ipsec neu zu starten.

Antwort2

Aushttps://lists.openswan.org/pipermail/users/2010-June/018901.html

Beim Start von Openswan sieht es so aus, als würde es die erste IP-Adresse auf der br0-Schnittstelle auswählen, um anzukündigen, was es auswählt. Falls es eines Tages eine falsche Adresse auswählt, wie kann ich ihm dann definitiv mitteilen, welche IP-Adresse auf welcher Schnittstelle liegt? Oder ist dies nur eine Eröffnungsankündigung und ich muss mir darüber keine Gedanken machen?

Es bindet an alle Adressen, die beim Start konfiguriert werden. Wenn später eine Adresse hinzugefügt wird, muss Pluto derzeit angewiesen werden, diese mit „ipsec whack --listen“ erneut zu binden.

ipsec_setup: mehrere IP-Adressen, Verwendung von 10.0.0.10 auf br0

Die Nachricht ist etwas verwirrend. Beim Antworten wird die IP-Adresse „verwendet“, von der das Paket empfangen wurde, und beim Initialisieren wird die „nächste“ IP-Adresse verwendet, wenn „%defaultroute“ verwendet wird. Es wird die IP oder der aufgelöste Hostname verwendet, wenn dieser in der Verbindung angegeben ist.

Es ist möglich, dass Ihre OpenVZ-Schnittstellen nicht automatisch gebunden werden, da sie beim Start nicht vorhanden sind.

Darüber hinaus können Sie es zwingen, nur auf einer IP zu lauschen, indem Sie Ihre /etc/ipsec.confDatei bearbeiten und die richtige XX.XX.XX.XX- oder Schnittstellenspezifikation venet0:X mit den listen=XX.XX.XX.XXoder interface=venet0:X-Direktiven unter dem config setupAbschnitt hinzufügen.

http://linux.die.net/man/5/ipsec.conf

verwandte Informationen