Background: LXD is a hypervisor that manages machine containers on Linux distributions. You install LXD on your Linux distribution and then you can launch machine containers into your distribution running all sort of (other) Linux distributions.
배경: LXD는 리눅스 배포판에서 머신 컨테이너를 관리하는 하이퍼바이저입니다. 리눅스 배포판에 LXD를 설치한 후, 다양한 (다른) 리눅스 배포판을 실행하는 머신 컨테이너를 배포판에 시작할 수 있습니다.
- Using
macvlan
. See https://blog.simos.info/how-to-make-your-lxd-container-get-ip-addresses-from-your-lan/ - Using
bridged
. It is this tutorial, you are reading it now.
bridged
. 당신이 지금 읽고 있는 이 튜토리얼입니다. - Using
routed
. See https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/
routed
. https://blog.simos.info/how-to-get-lxd-containers-get-ip-from-the-lan-with-routed-network/ - Using
ipvlan
. See https://blog.simos.info/how-to-get-lxd-containers-obtain-ip-from-the-lan-with-ipvlan-networking/
ipvlan
. https://blog.simos.info/how-to-get-lxd-containers-obtain-ip-from-the-lan-with-ipvlan-networking/
In this post, we are going to see how to use a bridge to make our containers get an IP address from the local network. Specifically, we are going to see how to do this using NetworkManager. If you have several public IP addresses, you can use this method (or the other with the macvlan) in order to expose your LXD containers directly to the Internet.
이 게시물에서는 브리지를 사용하여 컨테이너가 로컬 네트워크에서 IP 주소를 얻는 방법을 살펴보겠습니다. 구체적으로, NetworkManager를 사용하여 이를 수행하는 방법을 살펴보겠습니다. 여러 개의 공인 IP 주소가 있는 경우, 이 방법(또는 macvlan을 사용하는 다른 방법)을 사용하여 LXD 컨테이너를 인터넷에 직접 노출할 수 있습니다.
Creating the bridge with NetworkManager
NetworkManager로 브리지를 생성하기
See this post How to Configure and Use Network Bridge in Ubuntu Linux (new link, thanks Samuel) on how to create the bridge with NetworkManager. It explains that you
이 게시물을 참조하세요: Ubuntu Linux에서 네트워크 브리지를 구성하고 사용하는 방법(새 링크, 감사합니다 Samuel)에서 NetworkManager로 브리지를 만드는 방법을 설명합니다. 당신은
- Use NetworkManager to Add a New Connection, a Bridge.
NetworkManager를 사용하여 새 연결, 브리지를 추가합니다. - When configuring the Bridge, you specify the real network connection (the device, like eth0 or enp3s12) that will be the slave of the bridge. You can verify the device of the network connection if you run ip route list 0.0.0.0/0.
브리지를 구성할 때, 브리지의 슬레이브가 될 실제 네트워크 연결(eth0 또는 enp3s12와 같은 장치)을 지정합니다. ip route list 0.0.0.0/0을 실행하면 네트워크 연결의 장치를 확인할 수 있습니다. - Then, you can remove the old network connection and just keep the slave. The slave device (bridge0) will now be the device that gets you your LAN IP address.
그런 다음, 이전 네트워크 연결을 제거하고 슬레이브만 유지할 수 있습니다. 슬레이브 장치(bridge0)는 이제 LAN IP 주소를 가져오는 장치가 될 것입니다.
At this point you would have again network connectivity. Here is the new device, bridge0.
이 시점에서 다시 네트워크 연결이 가능해졌습니다. 새로운 장치인 bridge0이 있습니다.
$ ifconfig bridge0 bridge0 Link encap:Ethernet HWaddr 00:e0:4b:e0:a8:c2 inet addr:192.168.1.64 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::d3ca:7a11:f34:fc76/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:9143 errors:0 dropped:0 overruns:0 frame:0 TX packets:7711 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:7982653 (7.9 MB) TX bytes:1056263 (1.0 MB)
Creating a new profile in LXD for bridge networking
LXD에서 브리지 네트워킹을 위한 새 프로필 만들기
In LXD, there is a default profile and then you can create additional profile that either are independent from the default (like in the macvlan post), or can be chained with the default profile. Now we see the latter.
LXD에서는 기본 프로필이 있으며, 기본 프로필과 독립적인 추가 프로필(예: macvlan 게시물처럼)을 만들거나 기본 프로필과 연결된 프로필을 만들 수 있습니다. 이제 후자를 살펴보겠습니다.
First, get a list of all available existing profiles. There is a single profile, the default one from LXD, and is used by 11 LXD containers. This means that this LXD installation has 11 containers.
먼저, 사용 가능한 모든 기존 프로필의 목록을 가져옵니다. LXD의 기본 프로필이 하나 있으며, 11개의 LXD 컨테이너에서 사용됩니다. 이는 이 LXD 설치에 11개의 컨테이너가 있음을 의미합니다.
$ lxc profile list +---------------+---------+ | NAME | USED BY | +---------------+---------+ | default | 11 | +---------------+---------+
Then, create a new and empty LXD profile, called bridgeprofile.
그런 다음, bridgeprofile이라는 새롭고 빈 LXD 프로필을 만듭니다.
$ lxc profile create bridgeprofile
Here is the fragment to add to the new profile. The eth0 is the interface name in the container, so for the Ubuntu containers it does not change. Then, bridge0 is the interface that was created by NetworkManager. If you created that bridge by some other way, add here the appropriate interface name. The EOF at the end is just a marker when we copy and past to the profile.
여기 새 프로필에 추가할 조각이 있습니다. eth0는 컨테이너의 인터페이스 이름이므로 Ubuntu 컨테이너에서는 변경되지 않습니다. 그런 다음 bridge0는 NetworkManager에 의해 생성된 인터페이스입니다. 다른 방법으로 그 브리지를 생성한 경우, 여기에 적절한 인터페이스 이름을 추가하십시오. 끝의 EOF는 프로필에 복사하고 붙여넣을 때의 마커일 뿐입니다.
description: Bridged networking LXD profile devices: eth0: name: eth0 nictype: bridged parent: bridge0 type: nic EOF
Paste the fragment to the new profile.
새 프로필에 조각을 붙여넣습니다.
$ cat <<EOF | lxc profile edit bridgeprofile (paste here the full fragment from earlier)
The end result should look like the following.
결과는 다음과 같아야 합니다.
$ lxc profile show bridgeprofile config: {} description: Bridged networking LXD profile devices: eth0: name: eth0 nictype: bridged parent: bridge0 type: nic name: bridgeprofile used_by:
Now, list again the profiles so that we can verify the newly created profile, bridgeprofile. It is there, and it is not used yet by a LXD (lex-dee) container.
이제 새로 생성된 프로필인 bridgeprofile을 확인할 수 있도록 프로필을 다시 나열합니다. 그것이 있으며, 아직 LXD(렉디) 컨테이너에 의해 사용되지 않습니다.
$ lxc profile list +---------------+---------+ | NAME | USED BY | +---------------+---------+ | bridgeprofile | 0 | +---------------+---------+ | default | 11 | +---------------+---------+
If it got messed up, delete the profile and start over again. Here is the command.
문제가 생기면 프로필을 삭제하고 다시 시작하세요. 여기 명령어가 있습니다.
$ lxc profile delete profile_name_to_delete
Creating containers with the bridge profile
브리지 프로필로 컨테이너 생성하기
Now we are ready to create a new container that will use the bridge. We need to specify first the default profile, then the new profile. This is because the new profile will overwrite the network settings of the default profile.
이제 우리는 브리지를 사용할 새로운 컨테이너를 만들 준비가 되었습니다. 먼저 기본 프로필을 지정한 다음 새 프로필을 지정해야 합니다. 이는 새 프로필이 기본 프로필의 네트워크 설정을 덮어쓸 것이기 때문입니다.
$ lxc launch -p default -p bridgeprofile ubuntu:x mybridge Creating mybridgeStarting mybridge
Here is the result.
여기 결과가 있습니다.
$ lxc list +-------------+---------+---------------------+------+ | mytest | RUNNING | 192.168.1.72 (eth0) | | +-------------+---------+---------------------+------+ | ... | ... |
The container mybridge is accessible from the local network.
컨테이너 mybridge는 로컬 네트워크에서 접근 가능합니다.
Changing existing containers to use the bridge profile
기존 컨테이너를 브리지 프로필을 사용하도록 변경하기
Suppose we have an existing container that was created with the default profile, and got the LXD NAT network. Can we switch it to use the bridge profile?
기본 프로필로 생성된 기존 컨테이너가 LXD NAT 네트워크를 사용하고 있다고 가정해 보겠습니다. 이를 브리지 프로필로 전환할 수 있을까요?
Here is the existing container.
여기 기존 컨테이너가 있습니다.
$ lxc launch ubuntu:x mycontainer Creating mycontainerStarting mycontainer
Let’s assign mycontainer to use the new profile, “default,bridgeprofile”.
mycontainer를 새 프로필인 “default,bridgeprofile”을 사용하도록 지정합시다.
$ lxc profile assign mycontainer default,bridgeprofile
Now we just need to restart the networking in the container.
이제 컨테이너에서 네트워킹을 재시작하기만 하면 됩니다.
$ lxc exec mycontainer -- systemctl restart networking.service
This can take quite some time, 10 to 20 seconds. Be patient. Obviously, we could simply restart the container. However, since it can take quite some time to get the IP address, it is more practical to know exactly when you get the new IP address.
이 과정은 꽤 오랜 시간이 걸릴 수 있으며, 10초에서 20초 정도 소요됩니다. 인내심을 가지세요. 분명히 우리는 컨테이너를 단순히 재시작할 수 있습니다. 그러나 IP 주소를 얻는 데 꽤 오랜 시간이 걸릴 수 있기 때문에 새로운 IP 주소를 정확히 언제 받는지 아는 것이 더 실용적입니다.
Let’s see how it looks!
어떻게 보이는지 봅시다!
$ lxc list ^mycontainer$ +----------------+-------------+---------------------+------+ | NAME | STATE | IPV4 | IPV6 | +----------------+-------------+---------------------+------+ | mycontainer | RUNNING | 192.168.1.76 (eth0) | | +----------------+-------------+---------------------+------+
It is great! It got a LAN IP address! In the lxc list command, we used the filter ^mycontainer$, which means to show only the container with the exact name mycontainer. By default, lxc list does a substring search when it tries to match a container name. Those ^ and $ characters are related to Linux/Unix in general, where ^ means start, and $ means end. Therefore, ^mycontainer$ means the exact string mycontainer!
정말 멋져요! LAN IP 주소를 받았어요! lxc list 명령어에서 우리는 ^mycontainer$ 필터를 사용했는데, 이는 정확한 이름 mycontainer를 가진 컨테이너만 표시하라는 의미입니다. 기본적으로 lxc list는 컨테이너 이름을 일치시키려고 할 때 부분 문자열 검색을 수행합니다. ^와 $ 문자는 일반적으로 Linux/Unix와 관련이 있으며, ^는 시작을 의미하고 $는 끝을 의미합니다. 따라서 ^mycontainer$는 정확한 문자열 mycontainer를 의미합니다!
Changing bridged containers to use the LXD NAT
LXD NAT를 사용하도록 브리지 컨테이너 변경
Let’s switch back from using the bridge, to using the LXD NAT network. We stop the container, then assign just the default profile and finally start the container.
브리지 사용에서 LXD NAT 네트워크 사용으로 다시 전환합시다. 우리는 컨테이너를 중지한 다음 기본 프로필만 할당하고 마지막으로 컨테이너를 시작합니다.
$ lxc stop mycontainer $ lxc profile assign mycontainer default Profiles default applied to mycontainer $ lxc start mycontainer
Let’s have a look at it,
한번 살펴보자
$ lxc list ^mycontainer$ +-------------+---------+----------------------+--------------------------------+ | NAME | STATE | IPV4 | IPV6 | +-------------+---------+----------------------+--------------------------------+ | mycontainer | RUNNING | 10.52.252.101 (eth0) | fd42:cba6:...:fe10:3f14 (eth0) | +-------------+---------+----------------------+--------------------------------+
NOTE: I tried to assign the default profile while the container was running in bridged mode. It made a mess with the networking and the container could not get an IPv4 IP address anymore. It could get an IPv6 address though. Therefore, use as a rule of thumb to stop a container before assigning a different profile.
참고: 나는 컨테이너가 브리지 모드에서 실행되는 동안 기본 프로필을 할당하려고 했다. 그로 인해 네트워킹에 문제가 생겼고 컨테이너는 더 이상 IPv4 IP 주소를 받을 수 없었다. 그러나 IPv6 주소는 받을 수 있었다. 따라서 다른 프로필을 할당하기 전에 컨테이너를 중지하는 것을 기본 규칙으로 삼아야 한다.
NOTE #2: If your container has a LAN IP address, it is important to stop the container so that your router’s DHCP server gets the notification to remove the DHCP lease. Most routers remember the MAC address of a new computer, and a new container gets a new random MAC address. Therefore, do not delete or kill containers that have a LAN IP address but rather stop them first. Your router’s DHCP lease table is only that big.
참고 #2: 컨테이너에 LAN IP 주소가 있는 경우, 라우터의 DHCP 서버가 DHCP 임대 제거 알림을 받을 수 있도록 컨테이너를 중지하는 것이 중요합니다. 대부분의 라우터는 새 컴퓨터의 MAC 주소를 기억하며, 새 컨테이너는 새로운 무작위 MAC 주소를 받습니다. 따라서 LAN IP 주소가 있는 컨테이너를 삭제하거나 종료하지 말고 먼저 중지하십시오. 라우터의 DHCP 임대 테이블은 그리 크지 않습니다.
Conclusion 결론
In this post we saw how to selectively get ours containers to receive a LAN IP address. This requires to set the host network interface to be the slave of the bridge. It is a bit invasive compared to using a macvlan, but offers the ability for the containers and the host to communicate with each other over the LAN.
이 게시물에서는 선택적으로 컨테이너가 LAN IP 주소를 받도록 설정하는 방법을 보았습니다. 이를 위해 호스트 네트워크 인터페이스를 브리지의 슬레이브로 설정해야 합니다. 이는 macvlan을 사용하는 것에 비해 다소 침습적이지만, 컨테이너와 호스트가 LAN을 통해 서로 통신할 수 있는 기능을 제공합니다.
Jair Bolivar 2018년 3월 10일 13:54
Just noticed that for the LXD ver 2.21 the command to create the new bridge profile is:
LXD 버전 2.21에 대한 새로운 브리지 프로필을 생성하는 명령은 다음과 같습니다:
root@lxc1:~# lxc profile list
root@lxc1:~# lxc 프로필 목록
+———+———+
| NAME | USED BY |
| 이름 | 사용됨 |
+———+———+
| default | 0 |
| 기본값 | 0 |
+———+———+
root@lxc1:~# lxc profile create bridgeprofile
Profile bridgeprofile created
프로필 브리지 프로필 생성됨
root@lxc1:~# lxc profile list
root@lxc1:~# lxc 프로필 목록
+—————+———+
| NAME | USED BY |
| 이름 | 사용됨 |
+—————+———+
| bridgeprofile | 0 |
+—————+———+
| default | 0 |
| 기본값 | 0 |
+—————+———+
Simos Xenitellis 2018년 3월 12일 10:16
Author 저자
Thanks for pointing this out. It is an omission in this post, as it should show first any existing profilers, then create the new one and finally list again all profiles (to show the newly created one).
이 점을 지적해 주셔서 감사합니다. 이는 이 게시물에서 누락된 부분으로, 기존의 프로파일러를 먼저 보여준 다음 새 프로파일러를 생성하고 마지막으로 모든 프로파일을 다시 나열해야 합니다(새로 생성된 프로파일을 보여주기 위해).
I’ll update the post.
게시물을 업데이트하겠습니다.
Hristian 2018년 9월 10일 16:21
Hell. There is no lxc create. Ubuntu 18.04.
지옥. lxc create가 없습니다. 우분투 18.04.
Simos Xenitellis 2018년 9월 10일 18:23
Author 저자
Thanks pointing this out.
이 점을 지적해 주셔서 감사합니다.
Indeed, there is no
lxc create profile
subcommand because the subcommand islxc profile create
.실제로
lxc create profile
하위 명령은 없습니다. 하위 명령은lxc profile create
입니다.I have corrected the post on this.
이 게시물을 수정했습니다.
Hey thank you for useful posts. In your opinion which method is best to achieve dedicated LAN IP address, macvlan vs bridge? Was there anything changed since LXD 3.0?
안녕하세요, 유용한 게시물에 감사드립니다. 당신의 의견으로는 전용 LAN IP 주소를 얻기 위해 어떤 방법이 가장 좋다고 생각하십니까, macvlan 대 bridge? LXD 3.0 이후로 변경된 사항이 있습니까?
My ubuntu 18.04 host is wired to a switch and in that switch this host has its own VLAN with another computer. Given that physical port doesn’t change, is it safe to assume that all my containers will be sitting on that VLAN without being accessible by devices from other VLANs?
내 우분투 18.04 호스트는 스위치에 유선으로 연결되어 있으며, 그 스위치에서 이 호스트는 다른 컴퓨터와 함께 자체 VLAN을 가지고 있습니다. 물리적 포트가 변경되지 않는다고 가정할 때, 모든 내 컨테이너가 다른 VLAN의 장치에 접근할 수 없이 그 VLAN에 위치할 것이라고 안전하게 가정할 수 있습니까?
Do you recommend additional security practices for host and containers, given that they’re now on the LAN/VLAN and other computer can SSH into them? Would changing default password for root and ubuntu user inside each of the containers be enough?
호스트와 컨테이너가 이제 LAN/VLAN에 있고 다른 컴퓨터가 SSH로 접근할 수 있는 상황에서 추가적인 보안 관행을 추천하시나요? 각 컨테이너 내에서 root와 ubuntu 사용자에 대한 기본 비밀번호를 변경하는 것만으로 충분할까요?
Simos Xenitellis 2018년 9월 26일 20:49
Author 저자
Personally I would prefer macvlan because it has the feature of not isolating the host from the containers.
개인적으로 저는 macvlan을 선호합니다. 왜냐하면 호스트와 컨테이너를 격리하지 않는 기능이 있기 때문입니다.
Is there a performance issue between the two? There might be. Unless measured, I would say that both are OK.
두 가지 사이에 성능 문제가 있나요? 있을 수 있습니다. 측정하지 않는 한, 둘 다 괜찮다고 말할 수 있습니다.
macvlan over vlan should work. You can easily verify that the container is indeed isolated in the vlan.
macvlan은 vlan 위에서 작동해야 합니다. 컨테이너가 실제로 vlan에서 격리되어 있는지 쉽게 확인할 수 있습니다.
On SSH, it is important not to enable password authentication. The default with the Ubuntu images is to use public-key authentication, which is good. By doing so, you avoid to set passwords for the root or ubuntu default accounts. By default, the root and ubuntu accounts are locked (have no password).
SSH에서는 비밀번호 인증을 활성화하지 않는 것이 중요합니다. Ubuntu 이미지의 기본 설정은 공개 키 인증을 사용하는 것으로, 이는 좋습니다. 이렇게 하면 루트 또는 우분투 기본 계정에 대한 비밀번호를 설정할 필요가 없습니다. 기본적으로 루트 및 우분투 계정은 잠겨 있으며(비밀번호가 없습니다).
I’d love to see this guide include networkd configuration via Netplan. I have a hate/hate relationship with netplan right now, although that’s mostly due to a lack of clarity in Netplan’s docs, and limited examples online. In principle Netplan’s great, and I’m all over yaml standardization.
이 가이드에 Netplan을 통한 networkd 구성도 포함되었으면 좋겠습니다. 현재 Netplan의 문서에서 명확성이 부족하고 온라인에 제한된 예제 때문에 Netplan과는 미운 정이 들어 있습니다. 원칙적으로 Netplan은 훌륭하고, 저는 yaml 표준화에 열광하고 있습니다.
FWIW, this works for me, but I’m still not super happy with it:
내가 보기에는 이게 나에게 효과가 있지만, 여전히 그다지 만족스럽지는 않다
network: 네트워크:
version: 2 버전: 2
renderer: networkd
ethernets:
eno1:
dhcp4: false
dhcp6: false
bridges: 다리:
bridge0:
dhcp4: true
dhcp6: false
interfaces: 인터페이스:
– eno1
parameters:
stp: false
In this config I disable STP on the bridge (it’s on by default) so that my containers get an IP quickly, STP’s cleverness delays DHCP by 30+seconds and wreaks havoc on cloud-init scripts that depend on a link.
이 구성에서는 브리지에서 STP를 비활성화합니다(기본적으로 활성화되어 있음) 그래서 내 컨테이너가 IP를 빠르게 받을 수 있습니다. STP의 지능은 DHCP를 30초 이상 지연시키고 링크에 의존하는 클라우드 초기화 스크립트에 혼란을 초래합니다.
Trevor Rabie 2018년 12월 10일 04:28
Thank you for the time to prepare this Simos. It did not work for me on Ubuntu 18.10, not sure if its just me – been trying for days to get this working – no joy! Using macvlan, I get an IP from my router, but it is not accessible from the host. Using bridge, the host can access but it not is not accessible over the lan.
이 Simos를 준비할 시간을 주셔서 감사합니다. Ubuntu 18.10에서는 작동하지 않았습니다. 저만 그런 건지 잘 모르겠네요. 며칠 동안 이걸 작동시키려고 노력했지만, 성공하지 못했습니다! macvlan을 사용하면 라우터에서 IP를 받지만, 호스트에서 접근할 수 없습니다. 브리지를 사용하면 호스트에서 접근할 수 있지만, LAN을 통해서는 접근할 수 없습니다.
Configured a bridge on my host as per your post:
귀하의 게시물에 따라 내 호스트에 브리지를 구성했습니다:
ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.64 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::ecf2:6e7e:218e:4809 prefixlen 64 scopeid 0x20
ether 70:85:c2:72:83:25 txqueuelen 1000 (Ethernet)
RX packets 2724 bytes 799344 (799.3 KB)
RX 패킷 2724 바이트 799344 (799.3 KB)
RX errors 0 dropped 0 overruns 0 frame 0
RX 오류 0 드롭 0 오버런 0 프레임 0
TX packets 1302 bytes 183962 (183.9 KB)
TX 패킷 1302 바이트 183962 (183.9 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
TX 오류 0 드롭 0 오버런 0 캐리어 0 충돌 0
lxc profile show bridgeprofile
config: {}
description: Bridged networking LXD profile
브리징 네트워킹 LXD 프로필
devices: 장치:
eth0:
name: eth0
nictype: bridged
parent: br0
type: nic
root:
path: /
pool: default
type: disk 타입: 디스크
name: bridgeprofile
lxc list shows no IP and container has no network access.
lxc list는 IP를 표시하지 않으며 컨테이너는 네트워크 접근이 없습니다.
In container: 컨테이너 안:
ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::216:3eff:fe8d:9837 prefixlen 64 scopeid 0x20
ether 00:16:3e:8d:98:37 txqueuelen 1000 (Ethernet)
RX packets 11 bytes 580 (580.0 B)
RX 패킷 11 바이트 580 (580.0 B)
RX errors 0 dropped 2 overruns 0 frame 0
RX 오류 0 드롭 2 오버런 0 프레임 0
TX packets 13 bytes 2316 (2.3 KB)
TX 패킷 13 바이트 2316 (2.3 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
TX 오류 0 드롭 0 오버런 0 캐리어 0 충돌 0
If I change the nictype to macvlan, then I get an network access and IP.
macvlan으로 nictype을 변경하면 네트워크 접근과 IP를 얻습니다.
I had exactly the same problem. It turns out that iptables was dropping the packets, not allowing them to be forwarded. What was odd was that some ARP packets and IPv6 packets passed through fine!
저는 정확히 같은 문제를 겪었습니다. iptables가 패킷을 차단하여 전달되지 않도록 하고 있었습니다. 이상했던 것은 일부 ARP 패킷과 IPv6 패킷은 문제없이 통과했다는 것입니다!
https://superuser.com/questions/1211852/why-linux-bridge-doesnt-work
Simos Xenitellis 2019년 9월 6일 19:11
Author 저자
Thanks for reporting back. Which distribution are you running? I do not see such rules in a default setup in Ubuntu. Do you have ufw configured?
보고해 주셔서 감사합니다. 어떤 배포판을 사용하고 계신가요? 기본 설정의 Ubuntu에서는 그런 규칙을 보지 못했습니다. ufw가 구성되어 있나요?
I’m on Ubuntu 18.04, running without ufw. Also, this system has been upgraded over time over the past decade, so it’s not running NetworkManager or netplan – just configs in /etc/network. Perhaps NetworkManager creates the rules automatically when you create the bridge.
저는 Ubuntu 18.04를 사용하고 있으며, ufw 없이 실행 중입니다. 또한, 이 시스템은 지난 10년 동안 점진적으로 업그레이드되었기 때문에 NetworkManager나 netplan을 실행하지 않고 /etc/network에 있는 구성만 사용하고 있습니다. 아마도 NetworkManager는 브리지를 생성할 때 규칙을 자동으로 생성할 것입니다.
Alfred Certain 2020년 4월 16일 01:30
¿How to use static IP addresses on Ubuntu 18.04 with several LXD? ¿Why is so difficult to get good LXD networking documentation?
우분투 18.04에서 여러 LXD에 정적 IP 주소를 사용하는 방법은 무엇인가요? 좋은 LXD 네트워킹 문서를 얻는 것이 왜 이렇게 어려운가요?
Simos Xenitellis 2020년 4월 16일 17:19
Author 저자
¡Hola! 안녕하세요!
When you use an unmanaged network (such as this case using a bridge, or with macvlan), then the container is exposed to the LAN, and it is up to the LAN (your LAN’s router) to respond with a static DHCP lease.
관리되지 않는 네트워크(이 경우 브리지를 사용하거나 macvlan을 사용하는 경우)를 사용할 때, 컨테이너는 LAN에 노출되며, 정적 DHCP 임대에 응답하는 것은 LAN(귀하의 LAN 라우터)에 달려 있습니다.
If you use a managed network (the default private bridge, i.e.
lxdbr0
), then you can set the fieldipv4.address
for the container so that it receives a static DHCP lease from LXD.관리되는 네트워크(기본 개인 브리지, 즉
lxdbr0
)를 사용하는 경우, 컨테이너에 대해ipv4.address
필드를 설정하여 LXD로부터 정적 DHCP 임대를 받을 수 있습니다.If the container should really get a static IP without relying on any DHCP server, then you can use
cloud-init
in a LXD profile to set the networking configuration. In that case, use the/cloud
container images from theimages:
repository, or any container image from theubuntu:
repository.컨테이너가 DHCP 서버에 의존하지 않고 실제로 정적 IP를 가져야 한다면, LXD 프로필에서
cloud-init
를 사용하여 네트워킹 구성을 설정할 수 있습니다. 그런 경우images:
리포지토리의/cloud
컨테이너 이미지 또는ubuntu:
리포지토리의 모든 컨테이너 이미지를 사용하세요.Finally, you can hand-edit the container to get a static IP address.
마지막으로, 컨테이너를 수동으로 편집하여 정적 IP 주소를 얻을 수 있습니다.
Hi, great guide! It´s works so far for me, but when i create a container, it´s get an ipv6 address not ipv4.
안녕하세요, 훌륭한 가이드입니다! 지금까지 저에게 잘 작동하고 있지만, 컨테이너를 생성할 때 ipv4가 아닌 ipv6 주소를 받습니다.
I ran lxd init to set lxdbr0 with ipv4 ‘auto’ and ipv6 ‘none’, but i guess setting up lxdbr0 should not be related to this.
lxdbr0를 ipv4 'auto'와 ipv6 'none'으로 설정하기 위해 lxd init을 실행했지만, lxdbr0 설정은 이와 관련이 없다고 생각합니다.
I have the feeling, that something was missing, when setting up the bridge. i could not use the link you provided, cause it´s broken(“How to configure a Linux bridge with Network Manager on Ubuntu “).
브리지를 설정할 때 뭔가 빠진 것 같은 기분이 듭니다. 제공하신 링크를 사용할 수 없었습니다. 왜냐하면 그것이 깨졌기 때문입니다(“우분투에서 네트워크 관리자를 사용하여 리눅스 브리지를 구성하는 방법”).
Do you have an idea, where this could come from, that i get ipv6 and not ipv4 adresses?
이것이 어디서 올 수 있는지에 대한 아이디어가 있나요? 제가 ipv6 주소를 받고 ipv4 주소를 받지 않는 이유는 무엇인가요?
Simos Xenitellis 2020년 4월 26일 18:05
Author 저자
Hi Raymund! 안녕 레이먼드!
Thanks. Indeed, the settings for
lxdbr0
should not affect this. When you use a bridge (that is attached to an actual network interface compared tolxdbr0
which is a private bridge not attached to a network interface), then the container tries to get the network configuration from the LAN. There should be some DHCP server to give the configuration. Otherwise, you would need to provide some network configuration youself.감사합니다. 실제 네트워크 인터페이스에 연결된 브리지를 사용할 때
lxdbr0
의 설정이 영향을 미치지 않아야 합니다.lxdbr0
은 네트워크 인터페이스에 연결되지 않은 개인 브리지입니다. 그러면 컨테이너는 LAN에서 네트워크 구성을 가져오려고 합니다. 구성을 제공할 DHCP 서버가 있어야 합니다. 그렇지 않으면 직접 네트워크 구성을 제공해야 합니다.The IPv6 address is likely some link-local address and it is not routable?
IPv6 주소는 아마도 링크 로컬 주소일 것이며 라우팅이 불가능합니까?
Check that your LAN has a DHCP server that will serve the container.
컨테이너에 서비스를 제공할 DHCP 서버가 LAN에 있는지 확인하십시오.
Raymund Nickel 2020년 5월 4일 06:45
Hi Simos, 안녕 시모스,
thank you for your reply! I switched from creating the network bridge by network manager to defining it with netplan and since then it works. I do not know why and what i might have done wrong but at least everything is working now. Thank you!
답변해 주셔서 감사합니다! 네트워크 관리자를 통해 네트워크 브리지를 만드는 것에서 netplan으로 정의하는 것으로 전환했더니 그 이후로 잘 작동합니다. 왜 그런지, 제가 무엇을 잘못했는지는 모르겠지만, 적어도 이제 모든 것이 잘 작동합니다. 감사합니다!
Raymund
chris 2020년 9월 13일 12:31
liked your article about macvlan, worked well but i cant use because pihole seems to need communication between host and container.
macvlan에 대한 당신의 기사를 좋아했습니다. 잘 작동했지만 pihole이 호스트와 컨테이너 간의 통신이 필요한 것 같아서 사용할 수 없습니다.
so i liked to try this method but i can create a bridge0 device because the article you linked is down. if i look for any other article they are so different.
그래서 나는 이 방법을 시도해보고 싶었지만, 당신이 링크한 기사가 내려갔기 때문에 bridge0 장치를 만들 수 없습니다. 다른 기사를 찾아보면 너무 다릅니다.
could you write one simple docu how to create bridge0 ?
bridge0를 만드는 방법에 대한 간단한 문서를 작성해 주시겠습니까?
i love your articles
나는 당신의 기사들을 사랑합니다
thanks in advance 미리 감사드립니다
chris
Simos Xenitellis 2020년 9월 13일 14:33
Author 저자
The distro that you are running on the host should dictate how to create the network bridge.
호스트에서 실행 중인 배포판이 네트워크 브리지를 생성하는 방법을 결정해야 합니다.
Here is a list of network software that most Linux distros use, https://wiki.archlinux.org/index.php/Network_bridge
여기 대부분의 리눅스 배포판에서 사용하는 네트워크 소프트웨어 목록이 있습니다, https://wiki.archlinux.org/index.php/Network_bridge
For example, if you are running Ubuntu 20.04 desktop, you would be using NetworkManager.
예를 들어, Ubuntu 20.04 데스크탑을 실행하고 있다면, NetworkManager를 사용하고 있을 것입니다.
For person searching a link to setup a bridge with network manager UI :
네트워크 관리자 UI로 브리지를 설정하는 링크를 찾는 사람을 위해:
https://www.ubuntupit.com/how-to-configure-and-use-network-bridge-in-ubuntu-linux/
Don’t miss the last step, activate the bridge with nmcli…. It took me two day to make it work…..
마지막 단계를 놓치지 마세요, nmcli로 브리지를 활성화하세요…. 작동시키는 데 이틀이 걸렸어요…..
Simos Xenitellis 2020년 9월 17일 16:09
Author 저자
Thanks Samuel! 고마워, 사무엘!
I updated the post with the new working link that explains how to create a network bridge in Ubuntu.
우분투에서 네트워크 브리지를 만드는 방법을 설명하는 새로운 작업 링크로 게시물을 업데이트했습니다.
Hi Simos 안녕 시모스
tried this with Ubuntu 20.04, lxd version 4.0.5
this command doesn’t work
이 명령은 작동하지 않습니다
host ip is 172.17.1.24 host ip는 172.17.1.24입니다.
created a br0 in netplan
This is the network config written by ‘subiquity’
이것은 'subiquity'에 의해 작성된 네트워크 구성입니다
I am able to set static IP if I use lxdbr0 but can’t access the container from from other hosts on the lan
lxdbr0를 사용하면 정적 IP를 설정할 수 있지만 LAN의 다른 호스트에서 컨테이너에 접근할 수 없습니다
If I use br0 then the container does not get any IP or route
br0를 사용하면 컨테이너가 IP나 경로를 받지 않습니다
Any suggestions? 어떤 제안이 있나요?
if I use lxdbr0 I can’t reach the gateway
lxdbr0를 사용하면 게이트웨이에 도달할 수 없습니다
got it to work
작동하게 만들었어
on the container had to set the network settings
컨테이너에서 네트워크 설정을 설정해야 했다
Fabio 2023년 7월 3일 19:19
I believe the culprit was docker. I was having the same issue solved by adding the rule manually as described on the link. But what got me thinking was why the chain FORWARD was set to DROP. It was docker messing up with the iptables rules in the end.
나는 범인이 도커라고 믿는다. 나는 링크에 설명된 대로 규칙을 수동으로 추가하여 해결한 동일한 문제를 겪고 있었다. 하지만 내가 생각하게 만든 것은 왜 FORWARD 체인이 DROP으로 설정되었는가였다. 결국 도커가 iptables 규칙을 엉망으로 만들었다.
I end up installing iptables-persistent, no saving the default rules and adding this to my /etc/iptables/rules.v4 file
나는 결국 iptables-persistent를 설치하고 기본 규칙을 저장하지 않으며 이것을 내 /etc/iptables/rules.v4 파일에 추가합니다.
Forwarding rule for br0
br0에 대한 포워딩 규칙
*filter *필터
:FORWARD DROP
-A FORWARD -i br0 -o br0 -j ACCEPT
COMMIT 커밋