Reparierje Docker- en WSL-ferkier dat it host-VPN negearret

Ik haw dit foarjier it grutste part fan in moarn efter in kontener oan gien dy't gjin inkeld yntern namme oplosse koe, wylst de browser njonken it de wiki sûnder klacht iepene. De tunnel wie omheech, de browser bewiisde it, en de kontener siet yn in oare netwurk-nammeomte mei in oare rûtetabel en in oare resolver. Wat folget is de oarder dy't ik no kontrolearje: earst rûtetabellen, twadde oplossing, tredde trochstjoering en as lêste it hostplatfoarm. Stop by de earste stap dy't al mislearret, want regels leger yn de stack tafoegje ferberget de grins ynstee fan him te ferpleatsen.

Fergelykje de trije rûtetabellen foardat jo in regel feroarje

In kontener op 'e standertbrêge fan Docker hat ien standertrûte nei de docker0-poarte, en gjin idee dat tun0 bestiet. De host hat tun0, de rûtes dy't it VPN treaun hat, en miskien in beliedsregel dy't probef erkier oer in oare ynterface stjoert as jo ferwachtsje. WSL foeget in tredde tabel ta efter syn eigen firtuele adapater. Printsje alle trije foardat jo ien fan har bewurkje.

As de iennichste rûte fan 'e kontener de brêge is en tun0 nea yn syn nammeomte ferskynt, sil neat hjirûnder helpe: gjin nammetsjinnerferoaring makket in rûte, en gjin rûte makket in tunnelidentiteit dy't de peer akseptearret. De oarder is wichtich, want in DNS-flater en in rûteflater lykje fan binnen in shell identyk.

Rjochtsje de resolver op 'e tunnel ynstee fan op in publyk ien

Op 'e host, resolvectl status listet DNS-tsjinners per keppeling, en readlink -f /etc/resolv.conf fertelt jo oft it bestân de systemd-stub is, in NetworkManager-bestân, of eat dat in leveransierklant oerskreaun hat. Yn in kontener op in troch de brûker definiearre netwurk, /etc/resolv.conf neamt 127.0.0.11, de ynboude resolver fan Docker, dy't trochstjoert nei de upstream dêr't de daemon mei konfigurearre wie. In kontener op 'e standertbrêge krige krekt by it oanmeitsjen in kopy fan it hostbestân, en hâldt dy.

Dy kopy is de reden dat in tunnel dy't omheech komt nei't de kontener start is, de kontener by de âlde upstream freegje lit. Of jou de VPN-resolver eksplisyt mei docker run --dns 10.8.0.53, of set "dns": ["10.8.0.53"] yn /etc/docker/daemon.json en start de daemon opnij, of meitsje de kontener opnij as de tunnel omheech is. Opnij meitsjen is meastentiids goedkeaper as it debuggen fan in resolver dy't in oere lyn noch goed wie.

In publyk resolver yn it plak sette is de reparaasje dy't it symptoom hâldt. Hy oplost it ynternet en mislearret yn elke priveesône, en hy kin stil de filtering omsile dy't de tunnel bestiet om te hanthavenjen. As jo besykje te skriuwen yn /etc/resolv.conf fan in kuierjende kontener, ferwachtsje Device or resource busy: Docker bind-mountet dat bestân, dat de bewurking hat earst in unmount nedich. --dns by it oanmeitsjen sette is de searje dy't in werstart oerlibbet.

Stjoer troch en oersette as konteners de tunnel liene

Mei de standertbrêge is de host in router tusken docker0 en tun0, en hy docht by standert gjin fan beide taken. Set trochstjoering oan en oerset it boarneadres dat de peer in tunneladres fan 'e host sjocht ynstee fan ien dêr't hy gjin weromrûte nei hat (ferfang tun0 troch de namme dy't jo klant oan 'e ynterface jout):

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i docker0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o docker0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

De FORWARD-regels binne wichtich op hosts waans trochstjoerbelied DROP is. Docker foeget syn eigen keatlingen ta, dat test mei in pakket ynstee fan te lêzen iptables -S: fan 'e kontener, ip route get 10.8.0.20 moat de brêgepoarte neame, en nc -vz 10.8.0.20 443 moat op 'e tunnel ferbine of time-out ôfbrekke, net op 'e resolver.

Sûnder MASQUERADE hat de peer in weromrûte nei 172.17.0.0/16 nedich, dy't de measte fierte-tagongs-VPN's net treauwe sille. Hjir brekt ek in beliedsbasearre klant it plan: as hy allinnich ferkier fan bepaalde UID's of cgroups fangt, sjogge jo trochstjoerregels it pakket yn 'e tunnel nea, en de reparaasje heart yn it rûtebelied fan 'e klant, net yn iptables. Regels dy't mei de hân tafoege wurde ferdwine by in werstart, dat set se yn in systemd-ienheid of in netfilter-persistent-tabel en test opnij nei in werstart, want in tunnel dy't let omheech komt kin se fuortspiele.

Set de tunnel yn 'e kontener as isolaasje it doel is

As ien kontener troch in bepaald knooppunt nei bûten moat, rin de klant yn dy kontener. Hy hat --cap-add NET_ADMIN en --device /dev/net/tun nedich, en dan besit hy syn eigen tun0, rûtes en fjoermuorre. As oare konteners der trochhinne geane, hat hy ek trochstjoering en in MASQUERADE-regel yn 'e kontener nedich, en dy peers hawwe in eksplisite rûte of proxy nedich dy't dêrnei wiist; de standertbrêge fan Docker foeget dy rûte net foar jo ta.

Host-netwurking, docker run --network host, is de goedkeape ferzje: de kontener komt by de nammeomte fan 'e host en sjocht de tunnelrûtes direkt. Hy smyt ek netwurkisolaasje fuort, noeget poartebotsingen út en is yn 'e praktyk in Linux-opsje. In publisearre poarte is gjin ferfanging. -p 8080:80 makket in tsjinst berikber fan 'e host ôf; it makket ynterne 10.x-adressen net berikber fan binnen de kontener, en de beide trochinoar helje is hoe't in rûteprobleem in bleatleine databankpoarte wurdt.

Skied in namme-flater fan in oerlappende subnet

De standertbrêge fan Docker is 172.17.0.0/16, en in protte bedriuws-VPN-pools lizze yn 172.16.0.0/12. Sadree't de tunnel dat berik besit, kin ferkier bedoeld foar in kontener ynstee de tunnel yn rûte wurde. Nammen mislearje, de flater liket op DNS, en de adressen binne it probleem. Kontrolearje it bestimmingsplak, net de resolver: ip route get 172.17.0.5 op 'e host, fergelykje dan it brêgeprefiks mei de VPN-pool en mei docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'.

De reparaasje is ien fan 'e berikken te ferpleatsen: of in oare standertadrespools foar Docker yn daemon.json of in oare pool op 'e konsintrator. In oare nammetsjinner tafoegje docht hjir neat, en ssh -b ek net: de klant oan in ynterface bine feroaret it boarneadres, net in bestimmingsrûte dy't de tunnel yn wiist. Flugge wurkdieling: in namme dy't op 'e host oplost mar net yn 'e kontener is in resolverprobleem, wylst in direkte IP-ferbining dy't yn 'e kontener hinget mar op 'e host wurket in rûte- of trochstjoerkeatlingprobleem is.

WSL en Docker Desktop folgje de Linux-regels net

Yn syn standert NAT-modus sit WSL efter syn eigen firtuele adapater en krijt hy de ynterne rûtes of DNS-suffiksen fan it Windows-VPN net, dêrom wurket de browser en ping yn 'e distribúsje net. Spegele netwurking, beskikber yn resinte Windows 11-builds, dielt ynstee de ynterfaces fan 'e host, mar it moat ynskeakele wurde yn .wslconfig en de distribúsje opnij start mei wsl --shutdown. Befêstigje de aktive modus mei wslinfo --networking-mode foardat jo in reparaasje tapasse, want it NAT-antwurd is ferkeard foar spegele modus en oarsom.

Docker Desktop foeget noch in laach ta. Linux-konteners op Windows sitte efter in NAT-ymplemintaasje dy't histoarysk vpnkit hjit, en har paad ferskilt fan in native Linux-host. Windows-konteners ferbine fia in firtuele Hyper-V-skeakelder, en in bedriuwsclient kin ferkier fan dy skeakelder blokkearje, dat Linux-konteners op deselde masine kinne it netwurk berikke wylst Windows-konteners neat hawwe. In eksterne skeakelder bûn oan 'e fysike adapater is de gewoane oplossing, en hy feroaret de netwurkidentiteit fan 'e kontener op manieren dy't belied miskien net tastean.

Foardat jo noch in regel skriuwe, rin de fjouwer lagen yn oarder troch en stop dêr't ien fan har ferkeard is:

• Yn 'e kontener: berikt ip route it priveeprefiks, en neamt /etc/resolv.conf in upstream dy't it oplost?
• Op 'e host: is trochstjoering oan, is NAT bûn oan 'e tunnel-ynterface, en akseptearret de trochstjoerkeatling brêge nei tunnel?
• Op 'e peer: ken hy in werompaad, of fertrouwe jo op NAT om it kontenersubnet te ferbergjen?
• Op it platfoarm: is WSL yn NAT- of spegele modus, en is de kontener Linux of Windows?

Rin elke test opnij yn in nije kontener of shell. In langrinnend proses mei in cache-antwurd of in fêstige ferbining sil mislearje bliuwe nei't de konfiguraasje goed is, en dy flater liket krekt op in reparaasje dy't net wurke hat.