Docker Swarm oor VPN: take loop, diensoproepe misluk

Drie bestuurders en vyf werkers oor twee terreine, verbind deur 'n tonnel, en docker service ls wys take wat aan albei kante loop terwyl oproepe tussen dienste verstryk. Niks in die Swarm-logboeke lyk verkeerd nie. Daardie kombinasie is die kenmerk van 'n datavlakprobleem: die beheervlak het die nodusse gevind, en die ingekapselde rame het nooit die reis gemaak nie.

Die mesh moet bestaan voordat die overlay dit doen

Swarm se overlay stoot ingekapselde rame direk tussen node-adresse, wat beteken elke node het 'n adres nodig wat elke ander node sonder vertaling kan bereik, op die koppelvlak wat die tonnel verskaf. 'n Tonnel wat net kliënte na 'n gepubliseerde poort dra, is nie genoeg nie. Die onderlaag moet node na node in beide rigtings routeer.

Toets dit voordat jy aan Swarm raak. Van elke node af, kyk na die roete na 'n eweknie se tonneladres, ping dit, en toets dan die beheerpoort. As ping werk en die poort nie, is die tonnel reg en is 'n filter in die pad.

ip -brief address
ip route get 10.20.0.12
ping -c3 10.20.0.12
nc -vz 10.20.0.12 2377

As die roete na die fisiese koppelvlak wys in plaas van tun0 of wg0, sal die overlay op 'n adres inkapsel wat die verre terrein nie kan bereik nie, en die simptoom sal soos pakketverlies lees.

Kyk watter adres elke node adverteer

Die daemon adverteer een adres, en eweknieë gebruik dit vir die datavlak. Op 'n gasheer met meerdere netwerke is dit maklik om die LAN- of publieke adres te adverteer terwyl die tonnel iets anders dra. Ondersoek dit eerder as om aan te neem, en spyker dit by aansluitingstyd met --advertise-addr wanneer die verstek verkeerd is. 'n Node wat 'n adres adverteer wat net hy kan bereik, sluit steeds by die swarm aan, en die fout wys later as dienste wat nie oor terreine kan praat nie.

Om die geadverteerde adres later te verander is nie 'n konfigurasiewysiging nie, want die node moet verlaat en weer aansluit.

Teken die geadverteerde adres per node in jou notas aan, want dit verduidelik die meeste asimmetriese foute.

Masquerade is die gewone skuldige

Wanneer 'n poort tussen die nodes en die tonnel sit, is die algemene fout om alles wat die fisiese koppelvlak verlaat te masquerade. Dit herskryf ook die overlay se binneste adresse, so elke eweknie lyk of hy van die poort kom en VXLAN-eweknieë hou op om mekaar te herken. Die resultaat is ontbrekende of eenrigting-ingekapselde verkeer terwyl gewone pings nog werk.

Routeer die overlay-voorvoegsel deur die poort en laat dit onvertaal. As vertaling werklik vir 'n ander voorvoegsel nodig is, beperk dit daar en nooit tot die reeks wat die overlay gebruik nie.

ip route add 172.16.0.0/22 via 10.20.0.1
iptables -t nat -I POSTROUTING -o tun0 -s 172.16.0.0/22 -j ACCEPT

Kyk na die reëlorde sowel as die reëlteks, want 'n breë MASQUERADE vroeër in die ketting wen oor 'n smal uitsondering later.

VXLAN het ruimte in die pakket nodig

VXLAN voeg 50 grepe by die rame wat dit dra. 'n Onderlaag van 1500 grepe wat 'n binneraam van 1500 grepe dra, produseer 'n ingekapselde pakket wat geen pad sal aflewer nie, en die fout lyk soos afwisselende diensontdekking eerder as 'n grootteprobleem. Verlaag die tonnel-MTU aan albei kante of stel die overlay-MTU sodat die drywer 'n loonvrag adverteer wat pas.

docker network create --driver overlay --attachable --opt com.docker.network.driver.mtu=1400 swarm-overlay

Die ingress-netwerk word outomaties geskep, so om dit te verander beteken om dit te verwyder en te herskep eerder as om dit in plek te wysig.

As jy net een kant van die tonnel regmaak, moet die kleiner MTU steeds die een wees wat saak maak.

Kyk na die datavlak, nie die logboeke nie

Vang die VXLAN-poort aan albei kante. Rame wat een kant verlaat en aan die ander kant aankom, beteken die onderlaag is reg en die probleem is binne die overlay. Rame wat vertrek en nooit aankom nie, beteken 'n roete of 'n filter. Rame wat glad nie vertrek nie, beteken die bronadres is verkeerd.

Diensontdekkingsfoute wat na 'n paar sekondes verdwyn, dui gewoonlik op die pakketbegroting of 'n wapperende pad, nie op raft-kworum nie.

Hou die opname van 'n werkende venster, want om dit met die gebreekte een te vergelyk is vinniger as om konfigurasie weer te lees.