Op ien laptop, mei ien ferbûne VPN-klant, bliuwe Linux-containers mei elkoar prate en Windows-containers stopje. It byld is net de fariabele; it paad dat de pakketten nei de host nimme is dat. Windows-containers op it standertnetwurk liene de rûtetabel en oersetting fan de host, dus in belied dat it rûtsjen fan de host feroaret, feroaret har ek. Befestigje dat mei in rûtesyktocht foardat jo eat opnij ynstallearje.

Wêr't de pakketten fan in Windows-container de host ynkomme

In container op it standertnetwurk nat krijt in adres út in prefiks fan 'e Host Networking Service, meastal earne binnen 172.16.0.0/12, en berikt de host fia in firtuele adapter. De host hat de rûte foar dat prefiks en oerset ferkear nei de adapter dy't op dat stuit aktyf is. Der is gjin aparte firtuele masine yn 'e midden fan dat paad.

Dat ûntwerp is wat de flater meganysk makket. As de container in pakket stjoert, docht de host in rûtesyktocht foar it container-prefiks. Hokker rûte ek wint, dêr giet it pakket hinne, en de container hat dêr gjin miening oer.

Wat de VPN-klant oan dat paad feroaret

In bedriuwsclient ynstallearret faak in breed stel rûtes en in filter dat tagong ta it pleatslike subnet wegeret salang't de tunnel iepen is. De bedoeling is ferdigenjend: in kompromittearre pleatslik netwurk soe in beskerme masine net berikke moatte. It by-effekt is dat de rûte fan de host nei it container-prefiks net mear it pleatslike NAT-netwurk is.

Ynstee dêrfan past de syktocht by de tunnel en wurdt it pakket oerjûn oan 'e gateway, dy't nea fan dat containeradres heard hat. Ping mislearret, de applikaasje rint troch de tiid en de container liket stikken wylst it VPN-ikoan gloeit. Sjoch nei de tabel fan 'e host wylst jo ferbûn binne en de konkurrearjende rûte is sichtber.

Container modeOutbound pathTypical result behind the VPN
Windows, default natHost routes and translates container trafficContainer prefix follows the tunnel and fails
Windows, transparentContainer sits on the physical linkDepends on the local subnet being allowed
Linux engine on Docker DesktopVM egress proxied by a host processOften keeps working

Wêrom't Linux-containers har oars hâlde

De Linux-motor draait containers binnen in lichte firtuele masine, en útgeande ferbiningen fan dy masine wurde iepene troch in proxy oan 'e hostkant namens de container. De host begjint de socket, dus de regel fan 'e VPN oer it container-prefiks jildt der net op deselde wize, en de wurklêst berikt it netwurk noch altyd.

Dat ferskil ferklearret ek wêrom't Linux-resepten net oerdrage. In Linux-container dy't syn eigen tunnel nedich hat, krijt in TUN-apparaat plus de NET_ADMIN-mooglikheid. Windows-containers eksponearje gjin ynterface as apparaat, dus dat patroan hat gjin ekwivalint oan dy kant.

Bewiis de rûte en kies dan in ûntwerp

Sammele bewiis fan 'e host, net fan 'e container, want de host docht de syktocht:

docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"

Rin de rûte-útfier ien kear foardat de VPN ferbynt en ien kear dêrnei. As it container-prefiks yn 'e twadde útfier nei de tunneladapter wiist, is de diagnose folslein en sil it opnij starten fan containers net helpe.

De earste opsje is in beliedsbeslissing: freegje de netwurkeigener oft pleatslike LAN-tagong foar dit apparaat tastien wurde kin. Ferskate bedriuwsclients biede dat as ynstelling oan, mar it ferswakket in bewuste grins. Freegje derom as in dokumintearre útsûndering mei in eigner en in resinsjedatum. In skeakel per apparaat dêr't nimmen wer by weromkomt is hoe't in ferdigenjend belied stil weiwurdt.

Wêr't it belied stean moat, ferpleats de wurklêst ynstee fan tsjin 'e rûte te fjochtsjen. In transparant netwurk mei in eksplisyt subnet en gateway set containers op 'e pleatslike skeakel, in Linux-wurklêst draait efter de VM-proxy, en in aparte firtuele masine mei syn eigen klant hâldt syn eigen belied. Kies ien mei opsetsin en test it fan binnenút de container, want dêr ûntstiet it fersyk fan 'e brûker.

Relatearre artikelen