Docker konteiners nav sasniedzams VPN tīklā? Salīdziniet apakštīklus

Docker izsniedz apakštīklu, uz kuru pretendē arī VPN. Salīdziniet abus adrešu plānus un izvēlieties labojumu, kas izturēs atkārtotu savienojumu.

Konteinieri atbild biroja lokālajā tīklā, bet pārstāj atbildēt tieši tajā brīdī, kad pieslēdzas uzņēmuma VPN. Konteinerā nekas nav mainījies: nav restarta, nav attēla atjauninājuma, nav konfigurācijas labojuma. Mainījusies ir resursdatora maršrutēšanas tabula, kurā tuneļa pievienotais maršruts tagad aptver adresi, ko izsniedza Docker. Pirms labojat apakštīklu vai pieprasāt VPN izņēmumu, nolieciet abus adrešu plānus blakus, jo labojumi prasa ļoti atšķirīgu laiku.

Izlasiet maršrutu pirms konfigurācijas maiņas

Sāciet ar tīklu, ko Docker faktiski izveidoja. IPAM bloks ir adrešu plāns, un apakštīkls ir tā rinda, kas ir svarīga:

docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]

Compose pēc noklusējuma katram jaunam projektam piešķir /16, tāpēc divi servisi var iekļauties 65,536 adrešu diapazonā. Tieši šī platuma dēļ pārklāšanās ir bieža: nejauši izvēlēts /16 ir pietiekami liels, lai aprītu vietni, kuru sasniedzat caur tuneli, un neviens to nepamana, kamēr tunelis nepaceļas.

Pēc tam salīdziniet maršruta izvēli vienai konteinera adresei — vienu reizi ar izslēgtu tuneli un vienu reizi ar ieslēgtu:

ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1

Divas atbildes formas ved uz dažādām vietām. Ja izvadē ir tun0, wg0 vai cita tuneļa ierīce, VPN prefikss ir vismaz tikpat konkrēts kā tilta maršruts, un pakete nekad nesasniedz konteineru. Ja tajā joprojām ir tilts, resursdators var sasniegt konteineru, un jūsu vaina ir filtrēšana, DNS vai atgriešanās ceļš, kas sabojājas tikai vienā virzienā.

Kāpēc /16 sadursmi ir viegli panākt

Docker ņem tilta tīklus no privātajiem baseiniem, un noklusējuma baseins nāk no 172.16.0.0/12 bloka /16 šķēlēs. Uzņēmumu tīkli bieži izmanto to pašu privāto telpu, un attālinātās piekļuves VPN nosūta šos prefiksus katram klientam, kas pieslēdzas. Kad abas puses uzskata, ka tām pieder 172.18.0.0/16, vienā maršrutēšanas tabulā ir divi pretrunīgi apgalvojumi.

Uzvarētāju izšķir prefiksa garums, nevis maršrutu secība. Tunelis, kas nosūta 10.0.0.0/8, neuzveic tilta maršrutu 172.18.0.0/16, jo /8 ir mazāk konkrēts. Tunelis, kas nosūta 172.18.0.0/16 vai 172.18.5.0/24 tajā, uzveic. Tāpēc viens portatīvais dators strādā biroja tīklā un neizdodas viesnīcas Wi-Fi ar to pašu VPN: klients saņem dažādus prefiksus.

Tā pati tabula pārvalda arī pretējo virzienu. Konteiners, kuram vajadzīgs iekšējais resursdators adresē 10.8.4.20, sūta paketi savai tilta vārtejai, un resursdators pēc tam maršrutē to tunelī. Šis ceļš parasti darbojas, jo NAT veic resursdators, bet tas neizdodas, ja uzņēmuma puse pieņem tikai portatīvā datora VPN adresi vai ja reversā ceļa filtrēšana izmet asimetrisko atbildi.

Salīdziniet trīs labojumus

Ir tikai trīs izejas, un tās atšķiras ar to, kam tās jāapstiprina un kas salūzt, kamēr vienu piemērojat.

RepairWho owns itWhat it costs
Renumber the container networkYouRecreates the network, restarts services, invalidates literal addresses in configs and scripts
Exclude your range from the tunnelNetwork teamChanges what every laptop sees, needs a change request and a client profile update
Reach the service through a published portYou and the clientOne port only, no direct container-to-container routing across the tunnel

Pārnumurēšana ir vienīgais labojums, ko var pabeigt bez pieteikuma, tāpēc lielākā daļa aprakstu ar to arī beidzas. Jaunā projektā tas ir lēti, bet kļūst dārgi, tiklīdz migrācijas rīks vai saglabāta savienojuma virkne norāda uz burtisku adresi. Saskaitiet šīs atsauces pirms YAML labošanas, nevis pēc tam.

Izņēmums no tuneļa ir tīrākā atbilde, ja pārklāšanās atrodas diapazonā, kas patiešām pieder jūsu uzņēmumam. Tas ir arī lēnākais, un tas ir bezjēdzīgs darbuzņēmējam, kurš nevar mainīt klienta profilu. Publicēts ports vai neliels reversais starpniekserveris izvairās no strīda: klients sazinās ar adresi, kuru tunelis jau maršrutē pareizi, un sasniedzamam jābūt tikai šim portam.

Piespraudiet diapazonu apzināti

Vienam projektam deklarējiet apakštīklu compose failā, lai projekts pārstātu ņemt no koplietotā baseina:

networks:
  default:
    ipam:
      config:
        - subnet: 10.201.7.0/24

Ņemiet šo diapazonu no reģistra, ko uztur jūsu komanda, nevis no piemēra, ko atradāt meklējot. Pārbaudiet to pret prefiksiem, ko nosūta VPN, mājas tīkliem, no kuriem cilvēki strādā, un citiem konteinera tīkliem tajā pašā resursdatorā. Pēc tam plānojiet atjaunošanu, jo esošais tīkls saglabā savu veco apakštīklu: docker compose down, pēc tam up -d. docker network rm atsakās, kamēr ir pievienoti galapunkti, un jebkuram ipv4_address ierakstam failā jāiekļaujas jaunajā diapazonā.

Tīkliem, ko Docker izveido pats, iestatiet dēmona baseinu failā /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.201.0.0/16", "size": 24 },
    { "base": "10.202.0.0/16", "size": 24 }
  ]
}

Baseins attiecas uz tīkliem, kas izveidoti pēc dēmona restartēšanas, un jau esošie tilti saglabā savas adreses. Tas ir ērti un viegli aizmirstami, tāpēc uzskatiet vecu projektu par joprojām pārklājošos, līdz kāds atjauno tā tīklu. Docker dzinēja tīklošanas dokumentācija apraksta piešķiršanas noteikumus, ja pārskatā jāsargā baseins.

Linux tilts un Docker Desktop sabojājas atšķirīgi

Linux resursdatorā konteinieri atrodas uz tiltiem resursdatora vārdu telpā. Vienā tabulā tiek izlemts viss, tāpēc iepriekš minētais salīdzinājums ir viss stāsts: izlasiet tilta maršrutu, izlasiet tuneļa maršrutu un noskaidrojiet, kurš uzvar īstai konteinera adresei.

Docker Desktop ievieto konteinerus aiz virtuālās mašīnas ar savu NAT. Resursdatoram vispār nav maršruta uz konteinera adresi; servisu tas sasniedz caur publicētu portu, parasti piesaistītu 127.0.0.1. Tāpēc VPN klients var sabojāt servisu bez jebkādas apakštīklu pārklāšanās: vai nu uzstādot maršrutu virtuālās mašīnas iekšējam diapazonam, vai bloķējot loopback trafiku, kamēr tunelis ir pieslēgts. Ja ip route get resursdatorā ziņo, ka konteinera adresei nav maršruta, tas ir gaidīti, nevis kļūda.

Praktiskās sekas ir tas, kur skatāties vispirms. Linux gadījumā sāciet ar maršrutēšanas tabulu. Desktop gadījumā sāciet ar publicēto portu un VPN klienta ugunsmūra noteikumiem, pēc tam pārbaudiet, vai virtuālās mašīnas iekšējais apakštīkls nepārklājas ar kaut ko, ko nosūta tunelis.

Pārbaudiet ar ieslēgtu tuneli

Pirms saucat to par salabotu, divreiz atkārtoti pieslēdzieties VPN, jo profils, kas pieslēdzoties pievieno maršrutus un atvienojoties tos atsauc, pēc pirmā mēģinājuma var izskatīties pareizs. Pēc tam veiciet pārbaudes, ko klients faktiski veic:

  1. ip route get no resursdatora, izmantojot konteinera īsto adresi.
  2. Pieprasījums no cita konteinera, lai pierādītu, ka pats serviss ir vesels.
  3. curl -sv http://127.0.0.1:8080/ no klienta ar ieslēgtu tuneli, pēc tam traceroute -n uz konteinera adresi no mašīnas lokālajā tīklā.
  4. sysctl net.ipv4.conf.all.rp_filter, ja pieprasījums sasniedz resursdatoru, bet atbilde pazūd.

Visbeidzot, ierakstiet izvēlēto diapazonu tajā pašā reģistrā, no kura to izvēlējāties, ar datumu un projektu, kuram tas pieder. Nākamā pārklāšanās nāks no projekta, ko neviens nav dokumentējis, un vienīgā aizsardzība ir tā, ka diapazons tika rezervēts apzināti, nevis izvēlēts nejauši.

Saistītie raksti