Miksi macvlan-kontti ei voi vastata VPN-asiakkaalle

Kuvittele Linux-isäntä, joka päättää VPN:n ja ajaa samalla konttia macvlan-verkossa. LAN on 192.168.60.0/24, kontilla on 192.168.60.210 ja VPN-asiakkaat tulevat osoitteesta 10.95.0.0/24. Asiakas saavuttaa palvelun, vastausta ei koskaan tule takaisin ja jokainen isännän palomuurisääntö näyttää oikealta. Kaksi erillistä rajoitetta tuottaa tämän oireen, ja toisen korjaaminen jättää toisen paikalleen.

Kaksi rajoitetta, yksi oire

Ensimmäinen rajoite on eristys: Dockerin macvlan-ajuri ei salli kontin puhua oman isäntänsä kanssa yläliitännän kautta. Isännän pinon ja kontin välisellä liikenteellä ei ole reittiä, riippumatta siitä, miten isännän reitit on kirjoitettu.

Toinen rajoite on paluureitti. Kontin oletusyhdyskäytävä on yleensä LAN-reititin, joten VPN-asiakkaalle osoitettu vastaus lähtee sen reitittimen kautta. Jos reitittimellä ei ole reittiä takaisin VPN-pooliin, vastaus pudotetaan jossain välissä.

Nämä kaksi vikaa näyttävät asiakkaan puolelta samoilta: pyyntö saapuu eikä vastausta koskaan tule. Ne tarvitsevat erilaiset korjaukset, ja laaja masquerade-sääntö voi peittää, kumpi niistä on vielä rikki. Siksi ensimmäinen testi on kaappaus kontin puolella eikä uusi palomuurimuutos. Jos pyyntö ei koskaan ilmesty sinne, kyseessä on eristysrajoite.

Rakenna isännän puolen shim kapeasti

Toinen macvlan-liitäntä isännällä, kytkettynä samaan ylätasoon siltatilassa, antaa isännän pinolle oman identiteetin kyseisessä LAN-segmentissä. Varaa sille osoite DHCP-poolin ulkopuolelta ja kontin alueen ulkopuolelta ja reititä vain kontti sen kautta.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

Ensimmäinen komento luo liitännän siltatilaan, joka on tämän ajurin dokumentoitu oletus ja tila, jonka haluat isännän ja kontin väliselle liikenteelle. Toinen antaa /32:n, jotta osoite ei törmää LAN-etuliitteeseen, ja neljäs lähettää shimin kautta vain kontin osoitteen.

Älä ohjaa koko LAN:ia uuden liitännän kautta. Tavallinen yhdistetty reitti pysyy sellaisenaan, ja isännän reitti on tarkoituksella kapea, jotta yksi kontti saa reitin ilman että segmentin muu osa muuttaa käyttäytymistään. Shimin suuntaan osoittava oletusreitti olisi eri suunnittelu eri seurauksin. Pidä se täsmällisenä, niin vahingon säde pysyy pienenä.

Nämä komennot muuttavat verkkotunnuksia käynnissä olevalla isännällä. Käytä laitteella tai hallitulla alustalla kyseisen alustan tuettua määritysmekanismia, koska vuorovaikutteinen root-kuoren muutos ei välttämättä selviä päivityksestä.

Päätä, miten lähde säilytetään

Kun shim on paikallaan, kontti pääsee isännälle ja kysymykseksi tulee, mitä lähdeosoitetta vastaus kantaa. Alkuperäisen VPN-lähteen säilyttäminen on puhtaampi malli: kontti näkee asiakkaan todellisen osoitteen ja palvelun lokit ja käyttösäännöt voivat käyttää sitä.

Jotta tämä toimisi, kontin verkkomäärityksen on lähetettävä tälle reitille liikenne osoitteesta 10.95.0.0/24 osoitteeseen 192.168.60.250 yhdyskäytävänään. Se on tuettu reitti- tai yhdyskäytäväasetus kontin omassa määrityksessä, ei isännän puolen temppu. Vahvista se kontin sisältä sen sijaan että olettaisit asetuksen tulleen voimaan. Oletusyhdyskäytävä, joka osoittaa edelleen LAN-reitittimeen, lähettää vastaukset jatkossakin samaan reikään.

Jos hyväksytty suunnittelu sen sijaan piilottaa VPN-lähteet, rajaa käännös kapeasti: todellinen VPN-pooli, shim lähtevänä liitäntänä sekä tietty kontti ja palvelu.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Sovita shim lähteväksi liitännäksi, ei tunnelia. Sääntö, joka nimeää tunnelin lähteväksi liitännäksi, ei vastaa konttia kohti kulkevaa pakettia, ja juuri se virhe tällaisessa kokoonpanossa yleensä on. Pidä sääntö yhtä kapeana kuin yllä oleva lause ja tarkista se, kun pooli muuttuu.

Tarkista asiakkaalta, älä isännältä

Isännältä itseltään tuleva pyyntö, joka on sidottu shimin osoitteeseen, todistaa, että shim pääsee kontille. Se ei todista, että kontti voi palauttaa liikenteen säilytettyyn lähteeseen 10.95.0.x, koska lähdeosoite on siinä testissä shimin oma.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

Ensimmäinen komento testaa isännästä konttiin -osuuden, ja toinen näyttää, mitä shimin kautta todella kulkee, kun oikea VPN-asiakas tekee pyynnön. Katso lähdeosoitetta sisääntuloreitillä ja sitä, ilmestyykö vastaus samalla virtauksella.

Isännällä on oltava edelleenlähetys käytössä, ja edelleenlähetysreitti tarvitsee sallinnan VPN-poolilta shimille palvelun portilla sekä muodostetut vastaukset. Isännän INPUT-sääntö ei valtuuta edelleenlähetettyä liikennettä, mikä on tavallinen syy siihen, että paketti pudotetaan sen jälkeen, kun reititys näyttää oikealta.

Aja oikea sovellus oikeilla tunnuksilla ja tarkista sitten, että toinen, asiaankuulumaton palvelu samassa kontissa hylkää sinut edelleen. Jos ainoa tapa saada se toimimaan oli avata jokainen edelleenlähetyssääntö, suunnittelu ei ole valmis. Kirjaa myös, minkä lähdeosoitteen palvelu tallensi, koska sitä sen omat käyttösäännöt käyttävät tästä lähtien.