İki ağlı konteyner yanlış ağ geçidini seçiyor

İki bağlantı, tek varsayılan rota ve yanlış ağ her seferinde kazanıyor. Çıkışı Compose gw_priority ile sabitleyin ve konteynerin içinden doğrulayın.

Konteyneriniz hâlâ kontrol köprüsünde yanıt veriyor, ancak her giden paket ofis macvlan'ından çıkıyor. Hiçbir şey bozulmadı. İki bağlantı birer ağ geçidi sağlıyor ve tek varsayılan rota amaçlamadığınız ağa gitti, bu yüzden hizmet çalışmaya devam ederken trafiği daha uzun bir yol izliyor. Biri fark ettiğinde kanıt bir hata mesajı değil, bir yönlendirme tablosudur.

Alışılmış açıklama Docker'ın ağı kazara seçtiğidir. Pratikte eski karar bağlı ağ adlarının alfabetik sırasını izliyordu, bu da yönlendirmeyi bir etiketin yan etkisi haline getirdi. gw_priority bunun yerine bilerek seçtiğiniz bir sayı koyar ve yerleşim yazıldıktan sonra benimsenmesi yaklaşık bir dakika sürer.

Varsayılan rota neden yanlış ağa düşer

Bir hizmetin katıldığı her ağ kendi ağ geçidini sunabilir ve konteyner yine de tam olarak bir varsayılan rota ile kalır. Compose 2.33.1 öncesinde beraberlik ağ adları sıralanarak çözülüyordu, bu yüzden control gibi office'ten önce gelen bir etiket trafiğin nereye gideceğini belirliyordu. Konteynerin içinde hiçbir şey kararın keyfi olduğunu kaydetmez, bu yüzden kod incelemesinden geçer ve sonra tuhaf bir yol olarak ortaya çıkar. compose dosyasına bir ilke koymak seçimi denetlenebilir kılmanın tek yoludur.

Hangi ağın kazanacağını gerçekten iki şey değiştirir: atadığınız gw_priority değerleri ve hangi ağların bağlı olduğu. Üçüncü bir ağ eklerseniz aday kümesi büyür; macvlan'ı çıkarırsanız köprüyle yarışacak bir şey kalmaz. İki hamleden hiçbiri uygulama günlüklerinde görünmez, çünkü yanlış varsayılan rota bağlantıyı nadiren tamamen koparır. Yalnızca yanıtların karşı tarafın belki beklemediği bir adresten gelmesine yol açar.

Ağ geçidini gw_priority ile sabitleyin

Compose, 2.33.1 sürümünden itibaren her hizmet-ağ bağlantısında gw_priority sunar ve en büyük sayı kazanır. Hizmet başına ayrı bir ağ geçidi anahtarı yoktur, bu yüzden değer hizmetin networks bloğuna aittir. Aşağıdaki örnek varsayılan rotayı control'e verirken office doğrudan bağlı LAN'ı için erişilebilir kalır.

services:
  vpn:
    networks:
      control:
        gw_priority: 1
      office:
        gw_priority: 0

networks:
  control:
    driver: bridge
    ipam:
      config:
        - subnet: 172.30.50.0/24
  office:
    driver: macvlan
    driver_opts:
      parent: eno1.120
      macvlan_mode: bridge
    ipam:
      config:
        - subnet: 192.168.120.0/24
          ip_range: 192.168.120.192/27
          gateway: 192.168.120.1

Bloğu iki ayrı denetim olarak okuyun: gw_priority varsayılan rotayı, ipam bölümü adreslemeyi belirler. Yalnızca subnet'i değiştirmek çıkış seçimini dokunulmadan bırakır ve bu düzeltmenin yarım uygulanmasının en yaygın yolu budur. Öncelikleri yönettikleri ağın yanında tutun ki bir sonraki okuyucu kararı aramak zorunda kalmasın.

gw_priority'yi yanındaki sıradan priority özelliğiyle karıştırmayın. O, bağlantı oluşturma sırasını düzenler ve yönlendirme hakkında hiçbir şey söylemez, bu yüzden varsayılan ağ geçidi seçemez ve arayüz adlarını düzeltmez. Biri trafiği yönlendirmek için priority'yi artırmayı öneriyorsa, sonuçtaki sıra tesadüfen doğru görünse bile öneri yanlıştır.

Varsayılan rotayı gerçekte hangi ağın taşıdığını doğrulayın

Çalışan konteynerin içinde denetleyin, çünkü ana makinenin yönlendirme tablosu ana makineyi tanımlar, hizmetin kullandığı ad alanını değil. Önce yapılandırma denetimini çalıştırın ki bir yazım hatası yeniden başlatmadan önce yakalansın, sonra konteynerin gerçekte kurduğu rotayı okuyun.

docker compose config --quiet
docker exec vpn ip -4 route show default
docker exec vpn cat /proc/net/route

Doğru sonuç köprü aygıtını ve 172.30.50.1'i adlandırır; yanlış olan 192.168.120.1'i ve macvlan aygıtını adlandırır. İmajda iproute2 paketi yoksa /proc dosyası yine varsayılan rotayı bildirir; hedef 00000000 ve ağ geçidi baytları terstir. Aygıt adları belirsizse arayüz sütununu docker inspect ile karşılaştırın.

Macvlan fiziksel bir bağlantı noktasıdır, köprünün kopyası değildir

Macvlan konteynere kabloda ikinci bir kimlik verir ve yerel aygıtlara erişimi çalışır kılan tam olarak budur. Ayrıca anahtar bağlantı noktasının ve hipervizörün ek bir MAC adresini kabul etmesi gerektiği anlamına gelir; birçok bulut ağı bunu sessizce reddeder. Bir filo planlamadan önce tek bir konteyner deneyin, çünkü reddedilen MAC genellikle yukarıda olan ama hiçbir şey geçirmeyen bir bağlantı olarak görünür.

macvlan_mode: bridge ayarı macvlan sürücüsünün bir kipidir; Docker'ın yazılım köprüsü değildir ve passthru varsayılan değil, ayrı ve özelleşmiş bir kiptir. Linux ayrıca bir macvlan konteynerinin kendi ana makinesine ulaşmasını engeller aynı üst öğe üzerinden, bu yüzden tek bir bağlantının iki işi yapmasını beklemek yerine kontrol köprüsü korunur.

VLAN üst öğesini Compose görmeden adlandırın

Docker, eno1.120 gibi noktalı bir üst öğeyi 802.1Q alt arayüzü olarak ele alır ve VLAN aygıtını kendisi oluşturur. Bu kolaylığın sınırları vardır: türetilen ad fiziksel arayüzün adına bağlıdır ve uzun adlar sonucu çevredeki araçların beklediğinin ötesine itebilir. Ana makinenin ağ yapılandırmasında adlandırılmış bir VLAN arayüzü oluşturup parent'ı ona yönlendirmek iki ucu da öngörülebilir kılar.

networks altındaki anahtarın bir Compose adı olduğunu, Linux aygıtı olmadığını unutmayın. Ana makinede office adlı bir arayüz aramak başarısız olur, çünkü çekirdek yalnızca üst arayüzü ve konteynerin arkasındaki veth çiftini görür.

Üstte VPN için yer açın

VPN istemcisi bu ağlar var olduktan sonra bağlanır, bu yüzden gw_priority'den bağımsız olarak daha özel rotalar, ilke kuralları ve filtreler ekleyebilir. Uzak önekleri iki yerel subnet'e göre planlayın; kontrol yolunun ihtiyaç duyduğu yanıtlar da dahil. Uzak bir önek ofis LAN'ıyla çakıştığında tünelden tüm özel aralığı koparmak yerine adres planını düzeltin.

VPN başladıktan sonra ve yeniden bağlandıktan sonra adresleri, rotaları ve hizmet yolunu yeniden denetleyin, çünkü elle eklenen bir rota tam da yeniden bağlanmada kaybolur. İlk testten önce beklenen tabloyu yazın ki sonraki karşılaştırma bir hafıza alıştırması değil diff olsun. Ağın kalıcı sahipliğini Compose'ta tutun ve VPN yapılandırmasının yalnızca kendi ilkesine sahip olmasına izin verin.

İlgili makaleler