Docker: rûte ien container troch in VPN en hâld in oare direkt

Ien host, twa wurklasten en in eask dy't se skiedt: in downloadkliïnt dy't út in kommersjele VPN komme moat, en in behearinterface dy't de ferbining fan 'e host bliuwe moat brûken. It ynstallearjen fan 'e VPN-kliïnt op 'e host lit de eask daliks mislearje, want dan diele beide wurklasten ien útgong. It patroan dat wol wurket is de tunnel yn syn eigen container te pleatsen en allinnich de wurklasten dy't it nedich hawwe diel nimme te litten oan 'e netwurknammeromte fan dy container. Al it oare hâldt it gewoane Docker-paad, en de details dy't folgje binne gefolgen fan wa't de nammeromte besit.

Wêrom in dielde nammeromte de regels feroaret

In container dy't diel nimt oan 'e nammeromte fan in oar krijt gjin eigen netwurkstapel. Hy sjocht deselde ynterfaces, deselde rûtetabel en deselde loopback as de container dêr't er oan dielnaam, en krekt dêrom is it patroan nuttich: de wurklast oplost en ferbynt normaal, en de tunnel dêrûnder fangt it ferkear op sûnder dat de applikaasje it wit. De kosten binne dat elke netwurkyndeling no ien eigner hat, en de dielnimmende container is dat net.

Dy eignerskipregel beantwurdet de measte konfiguraasjefragen foardat se steld wurde. As in ynstelling yn 'e netwurkstapel libbet, heart er by de sidecar. As er it proses beskriuwt, bliuwt er by de wurklast.

Loopback is it part dat minsken ferrast. Binnen de dielnimmende container wurdt localhost oplost nei de loopback fan 'e sidecar, net nei in eigen privee ien, sadat in tsjinst dy't him oan 127.0.0.1 bynt en isolaasje ferwachtet no dat adres mei de tunnelcontainer dielt.

Publisearje poarten op 'e container dy't de nammeromte besit

De poartmapping heart by de eigner fan 'e nammeromte, ek as it harkjende proses yn 'e oare container rint. Ferkaarje de mapping op 'e sidecar, en lit de wurklast syn eigen proseskonfiguraasje ûnoantaast litte. In mapping op 'e dielnimmende tsjinst kin net fan krêft wurde, itsij de motor it ôfwiist of it stilwei negearret ôfhinklik fan hoe't de container start wurdt, en dêrom ferdwynt in ynterface dy't in momint lyn berikber wie sadree't it patroan tapast wurdt.

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"]

Lês dat blok as trije besluten ynstee fan trije tsjinsten. De sidecar besit de tunnel en de publisearre poarte; de dielnimmende kliïnt ferklearret hielendal gjin netwurk; de direkte kliïnt hâldt in eigen mapping op it standertnetwurk. De bekwamens NET_ADMIN is wat de sidecar yn steat stelt ynterfaces te meitsjen en rûtes te feroarjen, en dat is de reden dat dizze container mear foarrjochten nedich hat as de wurklasten dy't er tsjinnet.

De tsjinst dy't direkt bliuwt hâldt syn eigen netwurk

De wurklast dy't net troch de tunnel moat hâldt de standertbrêge of in eigen troch de brûker definiearre netwurk, mei syn eigen publisearre poarte en syn eigen útgong. It is ferliedlik om it oan it netwurk fan 'e sidecar te keppeljen sadat de twa containers by namme prate kinne, mar dy iene stap ferpleatst syn ferkear stilwei de tunnel yn. As se inoar berikke moatte, bou dan in apart troch de brûker definiearre netwurk, keppelje beide deroan en lit de sidecar de iennichste útgong wêze.

Hâld de twa fragen apart: hokker containers inoar berikke kinne, en hokker wêr út giet. Se gearfoegje is de meast foarkommende manier wêrop dit ûntwerp wer in hostbrede VPN wurdt.

In flatermatrix foar it earste oere

De measte earste besykjen mislearje op ien fan fjouwer manieren, en elk hat in oare oarsaak. Kontrolearje se yn dizze folchoarder, want de earste twa ferklearje hast elk rapport.

De fjirde rige is dy't minsken ferkeard diagnostearje as in applikaasjeflater. In probe skreaun tsjin 'e eigen loopback fan 'e wurklast testet no de tunnelcontainer, dus hy mislearret of rapportearret in folslein ferkearde tsjinst.

As ien hostnamme de tunnel nedich hat

Soms is in folsleine tunnel te folle: ien ynterne namme moat troch in bedriuws-VPN wylst in lokale socket of displayferbining trochgiet. In folsleine tunnel yn 'e container brekt dat paad en alles dat oan 'e host rjochte is, dus rûte allinnich it foarheaksel dat it nedich hat. In split-routing-wrapper om 'e kliïnt docht dat, stjoert de neamde host troch de tunnel en lit de foarige rûte ûnoantaast foar al it oare.

Kies dit as jo allinnich ien tsjinst berikke moatte en net besykje al it ferkear fan 'e container te ferpleatsen. It is in oar helpmiddel as de sidecar en it beantwurdet in oare fraach.

Ferifiearje, en meitsje it dan oerlibjend foar in werstart

Freegje elke container fan hokker adres oft er liket te kommen. De tunnelene moat it adres fan 'e provider printsje en de direkte de útgong fan 'e host. Identike antwurden betsjutte dat de direkte tsjinst de ferkearde nammeromte urven hat of dat in VPN op hostnivo noch alles fangt, en dy twa reparaasjes binne ferskillend. Rin de kontrôle opnij nei elke compose-bewurking, want ien kopiearre tsjinstblok is genôch om it probleem wer yn te fieren.

Trije dingen brekke letter faak. DNS folget de eigner fan 'e nammeromte, dus ynstellingen foar resolver en sykdomein hearre by de sidecar ynstee fan by de host. In VPN mei portforwarding feroaret syn harkpoarte by opnij ferbinen, dus de trochstjoerde poarte fan 'e provider en de harkpoarte oan 'e containerkant moatte wer yn 'e kliïntkonfiguraasje of de poartmapping skreaun wurde, meastentiids troch in lytse bywurker dy't de API fan 'e provider lêst. En elke probe skreaun tsjin localhost freget no de tunnelcontainer ynstee fan 'e wurklast.

Skriuw it patroan op, ynklusyf hokker container de nammeromte besit en hokker poarten derby hearre. De folgjende persoan foeget in tsjinst ta, kopiearret it ferkearde blok en reprodusearret de earste flater yn dit artikel.