Kahden verkon kontti valitsee väärän yhdyskäytävän

Kaksi liitosta, yksi oletusreitti ja väärä verkko voittaa aina. Kiinnitä lähtö Compose gw_prioritylla ja varmista se kontin sisältä.

Konttisi vastaa edelleen ohjaussillallaan, mutta jokainen lähtevä paketti poistuu toimiston macvlanin kautta. Mikään ei ole vioittunut. Kaksi liitosta antavat kumpikin oman yhdyskäytävän, ja ainoa oletusreitti meni verkkoon, jota et tarkoittanut, joten palvelu toimii edelleen samalla kun sen liikenne kulkee pidempää reittiä. Kun joku huomaa sen, todisteena on reititystaulu eikä virheilmoitus.

Tavallinen selitys on, että Docker valitsi verkon vahingossa. Käytännössä vanha päätös noudatti liitettyjen verkkojen nimien aakkosjärjestystä, mikä teki reitityksestä tunnisteen sivuvaikutuksen. gw_priority korvaa sen luvulla, jonka valitset tarkoituksella, ja sen käyttöönotto kestää noin minuutin, kun asetelma on kirjoitettu muistiin.

Miksi oletusreitti päätyy väärään verkkoon

Jokainen verkko, johon palvelu liittyy, voi tarjota oman yhdyskäytävänsä, ja kontille jää silti täsmälleen yksi oletusreitti. Ennen Compose-versiota 2.33.1 tasapeli ratkaistiin lajittelemalla verkkonimien mukaan, joten tunniste kuten control, joka tulee ennen officea, määräsi mihin liikenne menee. Mikään kontin sisällä ei kirjaa, että päätös oli mielivaltainen, ja siksi se läpäisee koodikatselmoinnin ja nousee myöhemmin esiin outona reittinä. Käytännön kirjaaminen compose-tiedostoon on ainoa tapa tehdä valinnasta tarkistettava.

Kaksi asiaa todella muuttaa sitä, mikä verkko voittaa: määrittämäsi gw_priority-arvot ja se, mitkä verkot ylipäätään on liitetty. Lisää kolmas verkko, niin ehdokasjoukko kasvaa; poista macvlan, niin sillan kanssa ei ole enää kilpailijaa. Kumpikaan siirto ei näy sovelluslokissa, koska väärä oletusreitti harvoin katkaisee yhteyden kokonaan. Se vain saa vastaukset saapumaan osoitteesta, jota toinen osapuoli ei ehkä odota.

Kiinnitä yhdyskäytävä gw_prioritylla

Compose tarjoaa gw_priorityn jokaisessa palvelu-verkko-liitoksessa versiosta 2.33.1 lähtien, ja suurin luku voittaa. Palvelukohtaista yhdyskäytäväavainta ei ole, joten arvo kuuluu palvelun networks-lohkoon. Alla oleva esimerkki antaa oletusreitin controlille ja jättää officen tavoitettavaksi sen suoraan kytketylle LANille.

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

Lue lohko kahtena erillisenä säätimenä: gw_priority päättää oletusreitin ja ipam-osio päättää osoitteistuksen. Pelkän subnetin muuttaminen jättää lähtövalinnan koskemattomaksi, ja se on yleisin tapa, jolla tämä korjaus jää puolitiehen. Pidä prioriteetit sen verkon vieressä, jota ne ohjaavat, jotta seuraavan lukijan ei tarvitse etsiä päätöstä.

Älä sekoita gw_prioritya vieressä olevaan tavalliseen priority-ominaisuuteen. Se järjestää yhteyksien luontia eikä kerro reitityksestä mitään, joten se ei voi valita oletusyhdyskäytävää eikä korjaa liittymien nimiä. Jos joku suosittelee priorityn nostamista liikenteen ohjaamiseksi, suositus on väärä, vaikka tuloksena oleva järjestys sattuisikin näyttämään oikealta.

Varmista, mikä verkko todella kantaa oletusreitin

Tarkista käynnissä olevan kontin sisältä, koska isäntäkoneen reititystaulu kuvaa isäntää eikä nimiavaruutta, jota palvelu käyttää. Aja ensin kokoonpanon tarkistus, jotta kirjoitusvirhe epäonnistuu ennen uudelleenkäynnistystä, ja lue sitten reitti, jonka kontti todella asensi.

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

Oikea tulos nimeää sillan laitteen ja 172.30.50.1; väärä nimeää 192.168.120.1:n ja macvlan-laitteen. Jos imagessa ei ole iproute2-pakettia, /proc-tiedosto raportoi silti oletusreitin, kohteena 00000000 ja yhdyskäytävän tavut käännettyinä. Vertaa liittymäsaraketta docker inspectiin, kun laitenimet ovat epäselviä.

Macvlan on fyysinen portti, ei sillan klooni

Macvlan antaa kontille toisen identiteetin johdolla, ja juuri se saa paikallisten laitteiden käytön toimimaan. Se tarkoittaa myös, että kytkimen portin ja hypervisorin on hyväksyttävä ylimääräinen MAC-osoite, ja monet pilviverkot kieltäytyvät siitä hiljaa. Testaa yksi kontti ennen laivaston suunnittelua, koska hylätty MAC näkyy yleensä linkkinä, joka on ylhäällä eikä välitä mitään.

Asetus macvlan_mode: bridge on macvlan-ajurin tila, ei Dockerin ohjelmistosilta, ja passthru on erillinen erikoistunut tila eikä oletus. Linux estää myös macvlan-konttia tavoittamasta omaa isäntäänsä saman parentin kautta, ja siksi ohjaussilta pidetään sen sijaan, että odotettaisiin yhden liitoksen hoitavan molemmat tehtävät.

Nimeä VLAN-parent ennen kuin Compose näkee sen

Docker kohtelee pisteen sisältävää parentia kuten eno1.120 802.1Q-aliliittymänä ja luo VLAN-laitteen itse. Sillä mukavuudella on rajansa: johdettu nimi riippuu fyysisen liittymän nimestä, ja pitkät nimet voivat työntää tuloksen ympäröivien työkalujen odotusten ulkopuolelle. Nimetyn VLAN-liittymän luominen isännän verkkokokoonpanoon ja parentin osoittaminen siihen pitää molemmat päät ennustettavina.

Muista, että networks-avaimen alla oleva on Compose-nimi, ei Linux-laite. Isännästä ei löydy office-nimistä liittymää, koska ydin näkee vain parent-liittymän ja kontin takana olevan veth-parin.

Tee tilaa VPN:lle päälle

VPN-asiakas liittyy sen jälkeen kun nämä verkot ovat olemassa, joten se voi lisätä tarkempia reittejä, käytäntösääntöjä ja suodattimia gw_prioritysta riippumatta. Suunnittele etäprefiksit molempia paikallisia subnetejä vasten, mukaan lukien vastaukset, joita ohjauspolku tarvitsee. Kun etäprefiksi menee toimiston LANin päälle, korjaa osoitesuunnitelma sen sijaan että repisit kokonaisen yksityisen alueen tunnelista.

Tarkista osoitteet, reitit ja palvelun polku uudelleen VPN:n käynnistyttyä ja vielä kerran sen yhdistettyä uudelleen, koska juuri uudelleenyhdistämisessä käsin lisätty reitti katoaa. Kirjoita odotettu taulu muistiin ennen ensimmäistä testiä, jotta vertailu jälkeenpäin on diff eikä muistiharjoitus. Pidä verkon pysyvä omistajuus Composessa ja anna VPN-kokoonpanon omistaa vain oma käytäntönsä.

Aiheeseen liittyvät artikkelit