Docker: geen voorafbepaalde adrespoele oor tydens ’n VPN-sessie nie

Die fout is spesifiek: Docker kan nie ’n aanvaarbare outomatiese subnet vir ’n nuwe brugnetwerk vind nie. Dit sê nie dat die masjien se adresse op is nie, en dit sê ook nie dat die VPN stukkend is nie. Twee vrae bepaal die diagnose: watter kandidaatblokke die daemon kan sien, en watter daarvan sy toewyser in hierdie omgewing uitsluit. Werk hulle in daardie volgorde deur, want die tweede vraag is betekenisloos totdat die eerste beantwoord is.

Bevestig wat misluk het voordat jy iets verander

Voer die stappe hieronder uit op die gasheer wat die daemon laat loop. ’n Skulp wat met ’n afgeleë konteks praat, beskryf ’n ander masjien, en daardie fout alleen kan ’n uur mors.

Noteer terselfdertyd die Engine-weergawe in die kaartjie. Elke heuristiek in die res van hierdie runbook is aan ’n weergawe gekoppel, en ’n bewering sonder ’n weergawe is ’n gerug.

Tel die toewysings wat jy reeds het

Lys die netwerke en ondersoek dan die belangrike: docker network ls gevolg deur docker network inspect NETWORK_NAME. Lees hul IPAM-subnette en die houers wat aan elkeen gekoppel is. Verskeie Compose-projekte verbruik meer blokke as wat hul houertellings laat vermoed, want elke projek is geneig om sy eie versteknetwerk te skep. ’n Houer wat gestop is, stel nie sy netwerk se toewysing vry nie.

Kyk ook na die poelkonfigurasie, want ’n verstekpoel het ’n basisreeks en ’n voorvoegselgrootte per netwerk. Groot toewysings per netwerk put die beskikbare blokke vinniger uit, en dit is ’n kapasiteitsfeit, nie ’n roeteringsprobleem nie.

Skryf die telling neer. Dit is die basislyn wat jou sê of die volgende verandering gehelp het.

Vergelyk die daemon se siening van roetes

’n VPN kan kandidaatkeuse beïnvloed, maar die presiese implementering bepaal hoe. In Moby 28.2.2 op Linux versamel InferReservedNetworks naambedieneradresse en sekere on-link IPv4-roetes, en dit reserveer nie sommer elke roete uit elke tabel nie. Versamelde skakelroetes sluit ook ’n ongespesifiseerde bestemmingsadres uit, so ’n 0.0.0.0/1-roete alleen reserveer nie elke adres nie. ’n Ander breë on-link-voorvoegsel, soos 128.0.0.0/1, kan die bekende kandidaatreekse 172 en 192 sny.

Vergelyk ip -4 route show table all voor en nadat die VPN aanskakel, op die daemon se gasheer. Die verskil is die bewys, en die weergawe is die omvang van die bewering.

Moenie een weergawe se heuristiek na elke weergawe veralgemeen nie. Dis hoe ’n forumantwoord ’n beleidsverandering word.

Kies die kleinste oplossing wat werk

As ’n bevestigde ongebruikte netwerk ’n blok hou wat jy nodig het, beplan dan die gerigte aftrede daarvan saam met die eienaar eerder as om breed te snoei. Vir ’n nuwe netwerk vermy ’n uitdruklik hersiene ongebruikte subnet die afhanklikheid van outomatiese keuse heeltemal. Daardie subnet moet steeds regte Docker-, LAN- en vereiste VPN-bestemmings vermy, want privaat beteken nie veilig nie. Om ’n regte afgeleë voorvoegsel te roeteer, sou die toewysingsfout met gebreekte toegang ruil.

Om default-address-pools te verander, is ’n breër beleid oor toekomstige toewysings. Kies ’n nie-botsende basis en ’n geskikte toegewysde grootte, voeg dit by die bestaande daemon-instellings, en beplan die gedokumenteerde herbegin-impak. Bestaande netwerke word nie stilweg hernommer nie.

Moenie maatskappyroete-stuwings afskakel om toewysing te laat slaag nie. ’n Uitdruklike adresplan los gewoonlik die plaaslike probleem op sonder om ’n verpligte beleid te verswak.

Aanvaar toewysing en roetering afsonderlik

Ondersoek ná die verandering die subnet wat Docker werklik geskep het, en toets die toepassing se VPN- en plaaslike afhanklikhede. Suksesvolle toewysing en korrekte roetering tydens loop is twee verskillende aanvaardingstoetse, en om die eerste te slaag is nie bewys vir die tweede nie. As die toepassing nie ’n hulpbron agter die tonnel kan bereik nie, het jy ’n roeteringsprobleem wat die poelfout verberg het. Teken albei resultate in die kaartjie aan.

Hou die roeteverandering en die poeltelling by die veranderingsrekord, want die volgende VPN-kliëntopdatering kan die eerste verander sonder om Docker aan te raak.

Die runbook is voltooi wanneer iemand anders daardie twee kontroles kan herhaal en dieselfde antwoord kry.