Docker se poeloorvleuelingsfout is nie 'n VPN-roeteprobleem nie

Docker weier om 'n netwerk te skep met die boodskap dat die poel met 'n ander een in hierdie adresruimte oorvleuel, en iemand besluit die VPN-roete moet die oorsaak wees. Dit kan nie. Daardie fout word geproduseer terwyl 'n poel toegewys word, voordat 'n enkele pakkie bestaan, en 'n handmatige kerngelroete het geen invloed daarop nie. Die VPN maak een stap later saak, wanneer 'n container wat reeds 'n adres het, ophou bereikbaar wees nadat 'n roete verskyn. Twee probleme, twee stelle bewyse, en om hulle te meng lewer 'n verandering op wat nie een van die twee regstel nie.

Twee foute wat dieselfde lyk

Die toewysingsfout is rekenkundig. Docker vergelyk die subnet wat jy aangevra het met die subnette wat dit reeds bestuur, vind 'n snypunt en weier. Niks loop nog nie, so daar is geen roete, geen container en geen verkeer om te ondersoek nie.

Die looptydsimptoom is 'n bereikbaarheidsvraag. 'n Container wat gister geantwoord het, antwoord nie nou nie, en iets het op die gasheer se roetetabel verander. Die container hou steeds sy adres; die vraag is watter pad daardie adres volg.

Albei is adresplanprobleme. Net een daarvan is 'n Docker-probleem.

Lees eers die toegewysde poele

Lys die netwerke en ondersoek diegene wat kan sny. Die subnet woon in die IPAM-konfigurasie, en die gekoppelde containers word apart gelys:

docker network ls
docker network inspect EXISTING_NETWORK

Vergelyk daardie subnet met die poel wat die nuwe netwerk aanvra, en onthou dat Compose sy eie versteknetwerk per projek skep. 'n Konflik met 'n projek wat jy vergeet het, lyk presies soos 'n konflik met die daemon.

'n Statiese ipv4_address op 'n diens is een container se adres, nie die poeldefinisie nie. Om dit te verander verwyder nie 'n oorvleueling nie, want die oorvleueling is tussen netwerksubnette eerder as tussen containers. Docker se netwerk-skepverwysing vereis nie-oorvleuelende subnette vir gewone brugtoewysing en dokumenteer hoe om een eksplisiet te kies.

Kies 'n voorvoegsel wat die VPN oorleef

Die onmiddellike konflik en die toekomstige roete word deur dieselfde keuse beslis, maak dit dus een keer. Vergelyk die kandidaatreeks met die LAN, met elke VPN-bestemming wat die gasheer kan bereik, en met enige ander overlay in gebruik.

'n Voorvoegsel wat Docker tevrede stel en met die afgeleë netwerk bots, gee jou 'n container wat skoon begin en onbereikbaar word die oomblik wanneer die tonnel op is. Dit is die tweede fout in hierdie artikel, en dit is baie moeiliker om later te diagnoseer as om dit nou te vermy.

Skryf die gekose reekse neer waar die volgende projek hulle kan lees. 'n Eenreëlige register van toegewysde voorvoegsels is goedkoper as 'n week van onverklaarde tydsverstrekkings.

Onttrek of verander 'n netwerk doelbewus

Vir 'n nuwe Compose-netwerk, stel die ongebruikte voorvoegsel in die netwerk se IPAM-konfigurasie. Vir 'n bestaande projek, beplan die hernommering: vaste adresse, afhanklike dienste en die stap om die netwerk te herskep moet alles in ag geneem word, want om YAML te wysig hernommer nie 'n lopende netwerk nie.

As 'n verouderde netwerk die botsende toewysing besit, ondersoek wie gekoppel is voordat jy dit verwyder. docker network rm weier terwyl aktiewe eindpunte bestaan, en docker stop neem containernames of ID's eerder as 'n netwerknaam. Om 'n container te stop verwyder ook nie die netwerkdefinisie wat die poel hou nie.

'n Breë prune is nie 'n diagnostiese hulpmiddel nie. Dit reik na onverwante projekte en vernietig die bewyse wat jy op die punt was om te versamel.

Verstekpoele help net die volgende toewysing

Die daemon se verstekadrespoelinstelling verbeter toekomstige outomatiese toewysings deur hulle uit reekse te hou wat jy reserveer. Dit her-adresseer nie netwerke wat reeds bestaan retroaktief nie, en dit los nie 'n eksplisiete subnet op wat 'n ander eksplisiete subnet oorvleuel nie.

Behandel daardie instelling as 'n afsonderlike, beplande verandering met sy eie herbegin, nie as deel van die herstel van een projek nie. Om die twee te meng beteken 'n daemon-herbegin beland in die middel van 'n onverwante ondersoek. Skeduleer dit in sy eie venster. Bevestig dan dat een nuwe outomatiese toewysing werklik buite die reekse beland wat jy gereserveer het.

Sodra die skepping slaag, verifieer die subnet wat werklik loop en maak dan een werklike toepassingsversoek met die VPN in sy beoogde toestand. As die poel geldig is en toegang steeds misluk, is die oorblywende werk roeteseleksie, filter en die terugpad. Dit is 'n looptydondersoek, en dit maak nie die toewysingsfout retroaktief betekenisloos nie.

Orde van werk: lees die toegewysde poele, kies 'n voorvoegsel wat sowel Docker as die VPN-bestemmings vermy, herskep die netwerk doelbewus, en toets dan een versoek met die tonnel op.