Jak skonfigurować zewnętrzne adresy IP dla gości LXC?


18

Eksploruję funkcje LXC w Ubuntu 12.04 i naprawdę chcę skonfigurować taką sieć:

client1:   192.168.56.101/24
lxc-host:  192.168.56.102/24
guest1     192.168.56.201/24
guest2     192.168.56.202/24
guest3     192.166.56.203/24

Chcę tylko „płaskiej” sieci, w której goście mają pełny dostęp do sieci LAN i są widoczni dla klientów. Jestem przyzwyczajony do mostkowania sieci z libvirt / KVM, jak opisano tutaj: http://libvirt.org/formatdomain.html#elementsNICSBridge

Na hoście:

# /etc/network/interfaces
auto br0
iface br0 inet static
    address 192.168.56.102
    netmask 255.255.255.0
    broadcast 192.168.56.255
    bridge_ports eth1

lxc.conf dla pierwszego gościa:

# /var/lib/lxc/guest1/config:
lxc.network.type=veth
lxc.network.link=br0
lxc.network.flags=up
lxc.network.hwaddr=00:16:3e:13:48:4e
lxc.network.ipv4=192.168.56.201/24

Wygląda na to, że 192.168.56.201 jest niewidoczny dla świata zewnętrznego, czego nie chcę. Wygląda na to, że muszę zrobić jedną z tych rzeczy:

1) Ręcznie skonfiguruj routing na hoście i gościu

2) Zrób coś hokey ... utwórz wirtualne interfejsy na hoście z wyprzedzeniem i skonfiguruj gości, aby z nich korzystali lxc.network.type=phys. Nie wiem, czy to by faktycznie działało.

Koncentruję się na Ubuntu, ale odpowiedzi na RHEL / Fedora też byłyby przydatne ...


1
Kontynuacja: Ustawiłem br0 w tryb rozwiązły i wydaje się, że robię to, co chcę teraz. Myślę, że to standardowa praktyka, ale nie została opisana w żadnym z wielu samouczków LXC, które przeczytałem. Pozostawię to pytanie otwarte na jakiś czas, na wypadek, gdyby otrzymałem jakieś uwagi ...
twblamer,

Zrobiłem w przybliżeniu to samo (z wyjątkiem nieco większej ręcznej konfiguracji): skrypt netup w każdej konfiguracji lxc, aby dodać veth do mostu (na hoście), ręczna konfiguracja IP w każdym kontenerze, dodatkowy skrypt / interfejs w każdym kontenerze do ustawienia up routing (przez przekierowanie IP4 na hoście). Jednak, o ile widzę, oba rozwiązania oznaczają, że kontener może ustawić własny adres IP na prawie wszystko (a także dodanie podstawowego interfejsu hosta do mostu jest nieco niewygodne). Więc jestem również zainteresowany opiniami / rozwiązaniami.
HoverHell,

Odpowiedzi:


13

Jest to całkiem słuszne - choć brakuje Ci takiej linii:

lxc.network.ipv4.gateway = X.X.X.X

Mam gościa LXC działającego na Debianie. Najpierw skonfiguruj most hosta (prosty sposób) w /etc/network/interfaces:

auto wan
iface wan inet static
        address 72.X.X.X
        netmask 255.255.255.0
        gateway 72.X.X.1
        bridge_ports wan_phy    # this line is important.
        bridge_stp off
        bridge_fd 2
        bridge_maxwait 20

W twoim przypadku tak to nazwałeś br0, a ja to nazwałem wan. Most można nazwać jak chcesz. Najpierw działasz - jeśli się nie powiedzie, zbadaj za pomocą (np.)brctl

Następnie twoja konfiguracja LXC jest skonfigurowana do dołączenia do tego mostu:

lxc.utsname = FOO
lxc.network.type = veth
lxc.network.link = wan                  # remember, this is what I call my bridge
lxc.network.flags = up
lxc.network.name = v-wan                # optional, I believe
lxc.network.ipv4 = 72.X.X.Y/24          # different IP than the host
lxc.network.ipv4.gateway = 72.X.X.1     # same as on the host

Jak zauważa HoverHell, osoba z rootem w kontenerze może zmienić adres IP. Tak. To most (aka przełącznik Ethernet). Jeśli chcesz temu zapobiec, możesz użyć reguł zapory na hoście - przynajmniej w moim przypadku pakiety muszą przejść przez iptables hosta.


10
Dziękuję wszystkim. To trochę smutne, ale właśnie wróciłem do tego, znalazłem to przez google i zapomniałem, że byłem pierwotnym
pytającym

2
@derobert: nie jestem pewien, czy było to wtedy dostępne, ale autojest to również poprawna wartość lxc.network.ipv4.gatewayi, o ile rozumiem, domyślnie jest to adres IP mostu, z którym łączy się interfejs veth.
0xC0000022L

Czy interfejs mostu wymaga własnego adresu IP? Jeśli wan_phyjest skierowany do Internetu, wówczas mostkowy adres IP musiałby być kolejnym ważnym, publicznym adresem IPv4, ponieważ musi on znajdować się w tej samej podsieci, co inne publiczne adresy IPv4, z którymi będę konfigurował moich gości lxc, prawda? Ale to wydaje się dość marnotrawstwem. askubuntu.com/a/884293/394569 sugeruje, że konfiguracja adresu mostu nie jest ściśle wymagana.
josch

@josch W tym przykładzie wan_phy nie ma adresu IP, zamiast tego jest na moście. Wątpię, aby w ogóle potrzebował adresu IP, jeśli nie chcesz, aby „host” miał zewnętrzny adres IP.
derobert

6

Nie wdałem się w pełni w LXC,

ale skonfigurowałem wiele kontenerów z własnymi statycznymi adresami IP w sieci LAN, które zapewniają usługi internetowe dla niektórych moich stron internetowych ...

Może to może pomóc w tym, czego chcesz dla swojego.

Prowadzę wiele kontenerów, tak jak

NA HOST MACHINE Edytowałem plik hosta, dodając każdy kontener i maszynę hosta: vi / etc / hosts

lxc host machine:   192.168.1.100
container1:   192.168.1.101
container2:     192.168.1.102
container3:   192.168.56.102
container4:   192.166.56.103

po zapisaniu ...

Ponownie, na hoście ustawiam sieć i most na:

# /etc/network/interfaces
auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
        bridge_maxwait 0
        **address** 192.168.1.100
        netmask 255.255.255.0
        **network 192.168.1.1**
        **broadcast** 192.168.1.100
        gateway 192.168.1.1
        dns-nameservers 8.8.8.8 8.8.4.4

powyżej sieci jest mój router IP dla LAN. (wewnętrzny) adres i emisja to host, wewnętrzny ip, którego później używam VHOST do dostępu do Internetu, serwerów WWW, ftp itp.

W POJEMNIKACH LXC 1-4 KONFIGURACJA PODOBNIE TAK:

LXC CONFIG
lxc.network.type=veth
lxc.network.link=br0
lxc.network.flags=up
lxc.network.hwaddr=00:16:3e:13:48:4e
**lxc.network.ipv4=192.168.1.101**

teraz kontener 1 IP = 192.168.1.101

Powtarzam, aby dodatkowe pojemniki miały własne statyczne IP na LAN ..

w pojemniku 1-4

zaloguj się z hosta:

lxc-console -n CONTAINERNAME,

& i ustawiam każdą sieć kontenerów na statyczną, eth0 na:

auto eth0
iface eth0 inet static
        address 192.168.1.101
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.1.101
        gateway 192.168.1.1
        dns-nameservers 8.8.8.8 8.8.4.4

KAŻDY Z POJEMNIKÓW MA WŁASNY IP, (lokalny) DOSTĘPNY W LAN. MOŻESZ SSH KAŻDY INDYWIDUALNY LOKALNY IP, ABY TESTOWAĆ ZA POMOCĄ PUTTY!

Po tym jestem pewien, że powinieneś dowiedzieć się, jak uruchomić je przez Internet po, na przykład, vhost do kontenera ip / load balancers / proxy / etc ..

Być może ta konfiguracja i tak może pomóc.


Jeśli skonfigurujesz adres IP, bramę itp. W konfiguracji kontenera LXC, nie musisz powtarzać tego w kontenerze. Zamiast tego ustaw ifacezwrotkę na manual(nie staticlub dhcp). up, down, dns-nameserversEtc mogą być nadal używane w Debianie itp
0xC0000022L

1

Nie grałem jeszcze w LXC, ale ten artykuł powinien ci pomóc: konfiguracja sieci za pomocą mostków Ethernet (sprawdź metodę 2).

Aby dać ci podpowiedź na temat konfiguracji (zakładam, że masz już poprawnie skonfigurowaną br0):

  1. Musisz utworzyć parę urządzeń veth przy użyciu ip link add type veth
  2. Poprzednie polecenie utworzyło 2 interfejsy wirtualne: veth0 i veth1
  3. Teraz dodaj wirtualny interfejs veth0 do mostka: brctl addif br0 veth0
  4. w swojej powłoce lxc wpisz: ns_exec -nm -- /bin/bash
  5. Teraz musimy ustawić inne wirtualne, jeśli do przestrzeni nazw sieciowych powłoki lxc: ip link set veth1 netns PID_OF_LXC_SHELL
  6. Teraz, konfigurując veth1 w powłoce lxc na pożądany adres IP (np. 192.168.56.201) powinieneś mieć wszystko ustawione.

W ogóle tego nie testowałeś? Prawdopodobnie dostaniesz nagrodę, ale twoja odpowiedź wcale mi nie pomaga i mam dokładnie taką samą konfigurację jak OP.
Jonas G. Drange

Jak mogę ci więcej pomóc? Czy w mojej odpowiedzi był jeden krok, który nie zadziałał, czy wykonałeś je i nie rozwiązał problemu? Nie, jak powiedziałem w mojej odpowiedzi, LXC jest na mojej liście życzeń rzeczy do zrobienia, ale jeszcze nie zacząłem prawdziwych testów.
Huygens
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.