Containere Windows și VPN: de ce se rupe rețeaua locală
Un container Windows folosește tabela de rutare a gazdei, așa că un VPN care blochează subrețeaua locală ia cu el și prefixul containerului. Modul Linux urmează altă cale.
Pe un singur laptop, cu un singur client VPN conectat, containerele Linux continuă să vorbească între ele, iar containerele Windows se opresc. Variabila nu este imaginea, ci calea pe care pachetele o iau spre gazdă. Containerele Windows din rețeaua implicită împrumută tabela de rutare și traducerea gazdei, așa că o politică ce schimbă rutarea gazdei le schimbă și pe ele. Confirmați asta cu o căutare de rută înainte de a reinstala ceva.
Unde intră pachetele unui container Windows în gazdă
Un container din rețeaua implicită nat primește o adresă dintr-un prefix al serviciului Host Networking Service, de obicei undeva în 172.16.0.0/12, și ajunge la gazdă printr-un adaptor virtual. Gazda deține ruta pentru acel prefix și traduce traficul către adaptorul care este activ. Nu există o mașină virtuală separată la mijlocul acelei căi.
Această construcție face defecțiunea mecanică. Când containerul trimite un pachet, gazda face o căutare de rută pentru prefixul containerului. Ruta care câștigă este locul unde merge pachetul, iar containerul nu are nicio părere despre asta.
Ce schimbă clientul VPN pe acea cale
Un client corporativ instalează adesea un set larg de rute și un filtru care refuză accesul la subrețeaua locală cât timp tunelul este activ. Intenția este defensivă: o rețea locală compromisă nu ar trebui să ajungă la o mașină protejată. Efectul secundar este că ruta gazdei către prefixul containerului nu mai este rețeaua NAT locală.
În schimb, căutarea se potrivește cu tunelul, iar pachetul este predat gateway-ului, care nu a auzit niciodată de acea adresă de container. Ping eșuează, aplicația ajunge la timeout, iar containerul pare stricat în timp ce pictograma VPN strălucește. Uitați-vă la tabela gazdei cât timp sunteți conectat și ruta concurentă este vizibilă.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
De ce containerele Linux se comportă diferit
Motorul Linux rulează containerele într-o mașină virtuală ușoară, iar conexiunile de ieșire din acea mașină sunt deschise de un proxy din partea gazdei în numele containerului. Gazda inițiază socketul, așa că regula VPN despre prefixul containerului nu se aplică în același fel, iar sarcina de lucru continuă să ajungă la rețea.
Această diferență explică și de ce rețetele Linux nu se transferă. Unui container Linux care are nevoie de propriul tunel i se dă un dispozitiv TUN plus capabilitatea NET_ADMIN. Containerele Windows nu expun nicio interfață ca dispozitiv, așa că acel model nu are echivalent pe acea parte.
Dovediți ruta, apoi alegeți o construcție
Strângeți dovezi de la gazdă, nu de la container, pentru că gazda face căutarea:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Rulați ieșirea rutelor o dată înainte ca VPN-ul să se conecteze și o dată după. Dacă în a doua ieșire prefixul containerului indică adaptorul tunelului, diagnosticul este complet și repornirea containerelor nu va ajuta.
Prima opțiune este o decizie de politică: întrebați proprietarul rețelei dacă accesul la LAN-ul local poate fi permis pentru acest dispozitiv. Câțiva clienți corporativi îl oferă ca setare, dar slăbește o graniță deliberată. Cereți-l ca o excepție documentată, cu proprietar și dată de revizuire. Un comutator pentru fiecare dispozitiv la care nimeni nu revine este modul în care o politică defensivă dispare în tăcere.
Acolo unde politica trebuie să reziste, mutați sarcina de lucru în loc să vă luptați cu ruta. O rețea transparentă cu subrețea și gateway explicite pune containerele pe legătura locală, o sarcină de lucru Linux rulează în spatele proxy-ului mașinii virtuale, și o mașină virtuală separată cu propriul client își păstrează propria politică. Alegeți una în mod deliberat și testați-o din interiorul containerului, pentru că acolo apare cererea utilizatorului.