Docker: reititä yksi kontti VPN:n läpi ja pidä toinen suorana

Yksi isäntä, kaksi työkuormaa ja vaatimus, joka erottaa ne: latausasiakas, jonka on tultava ulos kaupallisesta VPN:stä, ja hallintakäyttöliittymä, jonka on jatkettava isännän yhteyden käyttöä. VPN-asiakkaan asentaminen isäntään rikkoo vaatimuksen heti, koska silloin molemmat työkuormat jakavat yhden ulostulon. Kuvio, joka todella toimii, on siirtää tunneli omaan konttiinsa ja antaa vain sitä tarvitsevien työkuormien liittyä kyseisen kontin verkkonimiavaruuteen. Kaikki muu pitää tavallisen Docker-polun, ja seuraavat yksityiskohdat ovat seurauksia siitä, kuka nimiavaruuden omistaa.

Miksi jaettu nimiavaruus muuttaa sääntöjä

Kontti, joka liittyy toisen nimiavaruuteen, ei saa omaa verkkopinuaan. Se näkee samat rajapinnat, saman reititystaulun ja saman loopbackin kuin kontti, johon se liittyi, ja juuri siksi kuvio on hyödyllinen: työkuorma selvittää ja yhdistää normaalisti, ja alla oleva tunneli kaappaa liikenteen sovelluksen tietämättä. Hinta on, että jokaisella verkkotason asetuksella on nyt yksi omistaja, eikä liittyvä kontti ole se.

Tämä omistussääntö vastaa useimpiin kokoonpanokysymyksiin ennen kuin niitä kysytään. Jos asetus elää verkkopinussa, se kuuluu sivukontille. Jos se kuvaa prosessia, se pysyy työkuorman luona.

Loopback on se osa, joka yllättää ihmiset. Liittyvän kontin sisällä localhost selvitetään sivukontin loopbackiksi, ei omaksi yksityiseksi, joten palvelu, joka sitoutuu 127.0.0.1:een odottaen eristystä, jakaa nyt tuon osoitteen tunnelikontin kanssa.

Julkaise portit kontissa, joka omistaa nimiavaruuden

Porttimääritys kuuluu nimiavaruuden omistajalle, vaikka kuunteleva prosessi ajetaan toisessa kontissa. Ilmoita määritys sivukontissa ja anna työkuorman pitää oma prosessikokoonpanonsa koskemattomana. Liittyvän palvelun määritys ei voi tulla voimaan, hylkääkö moottori sen vai jättääkö se sen hiljaa huomiotta sen mukaan, miten kontti käynnistetään, ja siksi rajapinta, joka oli hetki sitten saavutettavissa, katoaa heti kun kuvio otetaan käyttöön.

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add: [NET_ADMIN]
    ports: ["8080:8080"]
  client-vpn:
    image: example/client
    network_mode: "service:gluetun"
  client-direct:
    image: example/client
    ports: ["8081:8080"]

Lue tämä lohko kolmena päätöksenä kolmen palvelun sijaan. Sivukontti omistaa tunnelin ja julkaistun portin; liittyvä asiakas ei ilmoita lainkaan verkkoa; suora asiakas pitää oman määrityksensä oletusverkossa. Kyvykkyys NET_ADMIN on se, mikä antaa sivukontille mahdollisuuden luoda rajapintoja ja muuttaa reittejä, ja siksi tämä kontti tarvitsee enemmän oikeuksia kuin työkuormat, joita se palvelee.

Suorana pysyvä palvelu pitää oman verkkonsa

Työkuorma, jonka ei pidä kulkea tunnelin läpi, pitää oletussillan tai oman käyttäjän määrittämän verkon, oman julkaistun portin ja oman ulostulon kanssa. Houkuttelevaa on liittää se sivukontin verkkoon, jotta kaksi konttia voisivat puhua nimellä, mutta se yksi askel siirtää sen liikenteen hiljaa tunneliin. Jos niiden on päästävä toisiinsa, rakenna erillinen käyttäjän määrittämä verkko, liitä molemmat siihen ja jätä sivukontti ainoaksi ulospäin vieväksi reitiksi.

Pidä kaksi kysymystä erillään: mitkä kontit voivat päästä toisiinsa ja mikä lähtee mistä. Niiden yhdistäminen on yleisin tapa, jolla tämä suunnittelu muuttuu takaisin koko isännän VPN:ksi.

Vikamatriisi ensimmäiselle tunnille

Useimmat ensimmäiset yritykset epäonnistuvat yhdellä neljästä tavasta, ja jokaisella on eri syy. Tarkista ne tässä järjestyksessä, koska kaksi ensimmäistä selittävät lähes jokaisen raportin.

Neljäs rivi on se, jonka ihmiset diagnosoivat väärin sovellusvirheeksi. Työkuorman omaan loopbackiin kirjoitettu tarkistus testaa nyt tunnelikonttia, joten se joko epäonnistuu tai raportoi täysin väärän palvelun.

Kun yksi isäntänimi tarvitsee tunnelin

Joskus täysi tunneli on liikaa: yhden sisäisen nimen on kuljettava yrityksen VPN:n läpi, kun paikallinen socket tai näyttöyhteys jatkaa toimintaansa. Kontin sisäinen täysi tunneli rikkoo tuon polun ja kaiken isännälle osoitetun, joten reititä vain se etuliite, joka sitä tarvitsee. Asiakkaan ympärillä oleva jaetun reitityksen kääre tekee sen lähettämällä nimetyn isännän tunnelin läpi ja jättämällä aiemman reitin koskemattomaksi kaikelle muulle.

Valitse tämä, kun sinun on päästävä vain yhteen palveluun etkä yritä siirtää kontin kaikkea liikennettä. Se on eri työkalu kuin sivukontti ja vastaa eri kysymykseen.

Varmista ja tee siitä sitten uudelleenkäynnistyksen kestävä

Kysy jokaiselta kontilta, miltä osoitteelta se näyttää tulevan. Tunnelin sisällä olevan pitäisi tulostaa palveluntarjoajan osoite ja suoran isännän ulostulo. Samat vastaukset tarkoittavat, että suora palvelu peri väärän nimiavaruuden tai isäntätason VPN kaappaa edelleen kaiken, ja ne kaksi korjausta ovat erilaisia. Aja tarkistus uudelleen jokaisen compose-muutoksen jälkeen, koska yksi kopioitu palvelulohko riittää tuomaan ongelman takaisin.

Kolme asiaa yleensä hajoaa myöhemmin. DNS seuraa nimiavaruuden omistajaa, joten resolverin ja hakutoimialueen asetukset kuuluvat sivukontille eivätkä isännälle. Portteja edelleenohjaava VPN vaihtaa kuunteluporttiaan uudelleenyhdistettäessä, joten palveluntarjoajan edelleenohjattu portti ja kontin puolen kuunteluportti on kirjoitettava takaisin asiakkaan kokoonpanoon tai porttimääritykseen, yleensä pienellä päivittäjällä, joka lukee palveluntarjoajan API:a. Ja mikä tahansa tarkistus, joka on kirjoitettu localhost vastaan, kysyy nyt tunnelikontilta eikä työkuormalta.

Kirjoita kuvio muistiin, mukaan lukien mikä kontti omistaa nimiavaruuden ja mitkä portit sille kuuluvat. Seuraava henkilö lisää palvelun, kopioi väärän lohkon ja toistaa tämän artikkelin ensimmäisen vian.