Windows контејнери и VPN: зашто се локална мрежа ломи
Windows контејнер користи табелу рутирања хоста, па VPN који блокира локалну подмрежу носи са собом и префикс контејнера. Linux режим иде другим путем.
На једном лаптопу, са једним повезаним VPN клијентом, Linux контејнери настављају да разговарају међусобно, а Windows контејнери се заустављају. Променљива није слика, већ пут којим пакети улазе у хост. Windows контејнери на подразумеваној мрежи позајмљују табелу рутирања и превођење хоста, па политика која мења рутирање хоста мења и њих. Потврдите то претрагом руте пре него што било шта поново инсталирате.
Где пакети Windows контејнера улазе у хост
Контејнер на подразумеваној мрежи nat добија адресу из префикса услуге Host Networking Service, обично негде унутар 172.16.0.0/12, и стиже до хоста преко виртуелног адаптера. Хост поседује руту за тај префикс и преводи саобраћај ка адаптеру који је тренутно активан. У средини тог пута нема засебне виртуелне машине.
Управо овај дизајн чини квар механичким. Када контејнер пошаље пакет, хост извршава претрагу руте за префикс контејнера. Која рута победи, тамо пакет иде, а контејнер о томе нема мишљење.
Шта VPN клијент мења на том путу
Корпоративни клијент често инсталира широк скуп рута и филтер који одбија приступ локалној подмрежи док је тунел активан. Намера је одбрамбена: компромитована локална мрежа не треба да стигне до заштићене машине. Нежељени ефекат је да рута хоста до префикса контејнера више није локална NAT мрежа.
Уместо тога претрага се поклапа са тунелом и пакет се предаје мрежном пролазу који никада није чуо за ту адресу контејнера. Ping не пролази, апликација истиче, а контејнер изгледа покварено док VPN икона светли. Погледајте табелу хоста док сте повезани и конкурентска рута је видљива.
| 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 |
Зашто се Linux контејнери понашају другачије
Linux машина покреће контејнере унутар лагане виртуелне машине, а одлазне везе са те машине отвара прокси на страни хоста у име контејнера. Хост покреће сокет, па се VPN правило о префиксу контејнера не примењује на њега на исти начин и радно оптерећење наставља да долази до мреже.
Та разлика објашњава и зашто се Linux рецепти не преносе. Linux контејнеру коме треба сопствени тунел даје се TUN уређај плус могућност NET_ADMIN. Windows контејнери не излажу ниједан интерфејс као уређај, па тај образац нема еквивалент на тој страни.
Докажите руту, па одаберите дизајн
Прикупљајте доказе са хоста, не из контејнера, јер претрагу изводи хост:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"Покрените излаз рута једном пре него што се VPN повеже и једном после. Ако у другом излазу префикс контејнера показује на адаптер тунела, дијагноза је завршена и поновно покретање контејнера неће помоћи.
Прва опција је одлука о политици: питајте власника мреже може ли се локални LAN приступ дозволити за овај уређај. Неколико корпоративних клијената то излаже као подешавање, али оно слаби намерну границу. Затражите то као документовани изузетак са власником и датумом прегледа. Прекидач по уређају који нико више не прегледа начин је на који одбрамбена политика тихо нестаје.
Где политика мора да остане, преместите радно оптерећење уместо да се борите са рутом. Транспарентна мрежа са експлицитном подмрежом и пролазом ставља контејнере на локалну везу, Linux радно оптерећење ради иза проксија виртуелне машине, и засебна виртуелна машина са сопственим клијентом задржава сопствену политику. Одаберите једну намерно и тестирајте је из унутрашњости контејнера, јер ту кориснички захтев настаје.