Gabimi i mbivendosjes së pool-it në Docker nuk është problem i rrugës VPN

Docker refuzon të krijojë një rrjet me mesazhin se pool-i mbivendoset me një tjetër në këtë hapësirë adresash, dhe dikush vendos që rruga VPN duhet të jetë shkaku. Nuk mund të jetë. Ai gabim prodhohet ndërsa alokohet një pool, përpara se të ekzistojë edhe një paketë e vetme, dhe një rrugë manuale e kernelit nuk ka asnjë ndikim mbi të. VPN-i ka rëndësi një hap më vonë, kur një kontejner që tashmë ka një adresë nuk arrin më të jetë i arritshëm pasi shfaqet një rrugë. Dy probleme, dy grupe provash, dhe përzierja e tyre prodhon një ndryshim që nuk rregullon asnjërin.

Dy gabime që duken njësoj

Gabimi i alokimit është aritmetik. Docker krahason nënrrjetin që kërkuat me nënrrjetet që tashmë administron, gjen një kryqëzim dhe refuzon. Asgjë nuk po funksionon ende, kështu që nuk ka rrugë, as kontejner, as trafik për të inspektuar.

Simptoma në kohën e ekzekutimit është një pyetje arritshmërie. Një kontejner që përgjigjej dje nuk përgjigjet tani, dhe diçka ka ndryshuar në tabelën e rrugëzimit të hostit. Kontejneri vazhdon të mbajë adresën e tij; pyetja është se cilën rrugë merr ajo adresë.

Të dyja janë probleme të planit të adresave. Vetëm njëri prej tyre është problem i Docker-it.

Lexoni së pari pool-et e alokuara

Listoni rrjetet dhe inspektoni ato që mund të kryqëzohen. Nënrrjeti jeton në konfigurimin IPAM, dhe kontejnerët e lidhur listohen veçmas:

docker network ls
docker network inspect EXISTING_NETWORK

Krahasoni atë nënrrjet me pool-in që kërkon rrjeta e re, dhe mbani mend se Compose krijon rrjetin e vet të parazgjedhur për çdo projekt. Një konflikt me një projekt që e keni harruar duket saktësisht si një konflikt me daemon-in.

Një ipv4_address statik në një shërbim është adresa e një kontejneri, jo përkufizimi i pool-it. Ndryshimi i tij nuk heq një mbivendosje, sepse mbivendosja është midis nënrrjeteve të rrjetit dhe jo midis kontejnerëve. Referenca network-create e Docker-it kërkon nënrrjete që nuk mbivendosen për alokimin e zakonshëm përmes urës dhe dokumenton si të zgjidhet një në mënyrë eksplicite.

Zgjidhni një prefiks që i mbijeton VPN-së

Konflikti i menjëhershëm dhe rruga e ardhshme vendosen nga e njëjta zgjedhje, prandaj bëjeni një herë. Krahasoni intervalin kandidat me LAN-in, me çdo destinacion VPN që hosti mund të arrijë dhe me çdo overlay tjetër në përdorim.

Një prefiks që kënaq Docker-in dhe përplaset me rrjetin e largët ju jep një kontejner që niset pastër dhe bëhet i paarritshëm në momentin që tuneli ngrihet. Ky është gabimi i dytë në këtë artikull, dhe është shumë më e vështirë ta diagnostikosh më vonë sesa ta shmangësh tani.

Shkruani intervalet e zgjedhura diku ku projekti tjetër mund t'i lexojë. Një regjistër një-rreshtor i prefikseve të alokuara është më i lirë se një javë skadimesh të pashpjeguara.

Tërhiqni ose ndryshoni një rrjet qëllimisht

Për një rrjet të ri Compose, vendosni prefiksin e papërdorur në konfigurimin IPAM të rrjetit. Për një projekt ekzistues, planifikoni rinumerimin: adresat fikse, shërbimet e varura dhe hapi i rikrijimit të rrjetit duhet të merren të gjitha parasysh, sepse redaktimi i YAML nuk rinumeron një rrjet në punë.

Nëse një rrjet i vjetëruar zotëron alokimin konfliktual, inspektoni kush është i lidhur përpara se ta hiqni. docker network rm refuzon përderisa ekzistojnë endpoint-e aktive, dhe docker stop merr emrat ose ID-të e kontejnerëve dhe jo një emër rrjeti. Ndalimi i një kontejneri gjithashtu nuk heq përkufizimin e rrjetit që mban pool-in.

Një prune i gjerë nuk është mjet diagnostikimi. Ai arrin projekte të palidhura dhe shkatërron provat që ishit gati të mblidhnit.

Pool-et e parazgjedhura ndihmojnë vetëm alokimin tjetër

Cilësimi i pool-it të adresave të parazgjedhura të daemon-it përmirëson alokimet automatike të ardhshme duke i mbajtur jashtë intervaleve që rezervoni. Ai nuk i riadreson në mënyrë retroaktive rrjetet që ekzistojnë tashmë, dhe nuk zgjidh një nënrrjet eksplicit që mbivendoset me një nënrrjet tjetër eksplicit.

Trajtojeni atë cilësim si një ndryshim të veçantë e të planifikuar me rinisjen e vet, jo si pjesë e riparimit të një projekti. Përzierja e të dyjave do të thotë që një rinisje e daemon-it bie në mes të një hetimi të palidhur. Planifikojeni në dritaren e vet. Më pas konfirmoni që një alokim i ri automatik bie vërtet jashtë intervaleve që rezervuat.

Pasi krijimi të ketë sukses, verifikoni nënrrjetin që funksionon vërtet dhe më pas bëni një kërkesë të vërtetë aplikacioni me VPN-in në gjendjen e synuar. Nëse pool-i është i vlefshëm dhe aksesi ende dështon, puna e mbetur është zgjedhja e rrugës, filtrimi dhe rruga e kthimit. Ky është një hetim në kohën e ekzekutimit, dhe ai nuk e bën gabimin e alokimit retroaktivisht të pakuptimtë.

Rendi i punës: lexoni pool-et e alokuara, zgjidhni një prefiks që shmang si Docker-in ashtu edhe destinacionet VPN, rikrijoni rrjetin qëllimisht, pastaj provoni një kërkesë me tunelin lart.