A Docker-konténerek forgalma megkerüli a gazdagép VPN-jét: így ellenőrizheti
A gazdagép VPN-je csak a gazdagép névterét fedi le. Ezekkel az ellenőrzésekkel derítheti ki, hogy a hídon lévő konténerek forgalma belép-e az alagútba, vagy közvetlenül kimegy.
A gazdagépen a böngésző a VPN kilépési címét mutatja, a konténer az otthoni kapcsolatát jelenti, és valaki ezt szivárgásnak nevezi. Semmi nem szivárgott ki. A gazdagép alagútja interfészek, útvonalak és szabályok halmaza, amelyek a gazdagép hálózati névteréhez tartoznak, a hídon lévő konténer pedig egy másik névtér a saját alapértelmezett útvonalával. Ültem olyan Compose-veremen, ahol a VPN-kliens hetek óta csatlakozva volt, és egyetlen konténer-csomag sem lépett be soha oda.
Ellenőrizze a névteret a tálca ikonja előtt
A névterek adják az egész érvet. Amikor a Docker elindít egy konténert egy hídhálózaton, létrehoz egy hálózati névteret, becsatolja egy veth-pár egyik végét, és ad a névtérnek egy címet és egy alapértelmezett útvonalat. Az alagút interfésze, bármi is a neve, a gazdagép névterében él. A konténeren belüli forgalom nem látja, és egyetlen kliensbeállítás sem változtat ezen kívülről.
Két támogatott lépés visz ki az elszigeteltségből. A --network host a gazdagép névterébe helyezi a konténert, így örökli a gazdagép útvonalait és ezáltal az alagutat. A --network container:vpn egy másik konténer névterét osztja meg, és a legtöbb sidecar-terv így küldi a munkaterhelést VPN-konténeren keresztül. Mindkettő kifejezett választás; általában csak az egyikük az, amit a telepítést végző személy értett.
A gazdagép mód nem ingyenes frissítés. A konténer megszűnik saját címmel rendelkezni, a portközzététel nem érvényesül, és egy ott NET_ADMIN tartó folyamat átírhatja a gazdagép útválasztását. Ezt elfogadni lehet a helyes döntés. Azt feltételezni, hogy már be van kapcsolva, az az út, ahogy az emberek egy estét egy olyan alagút hibakeresésével töltenek, amely soha nem volt az útvonalon.
Kövesse a csomagot a hídról kifelé
A hídon lévő konténer a csomagját az alapértelmezett átjárójának küldi, ami a híd interfésze a gazdagépen. A gazdagép ezután továbbítja a csomagot, és az alapértelmezett konfigurációban a forráscímet a sajátjára fordítja, mielőtt a csomag elhagyná a gépet. Ez a fordítási lépés az, amely csendben meghiúsítja a házirendet.
Mire a csomag eléri az alagút végpontját, a gazdagép címét hordozza. Minden szabály, házirend-útvonal vagy osztott alagútra vonatkozó döntés, amely a konténer eredeti címére épül, megszűnik illeszkedni, és két különböző kijáraton távozni szándékozó konténer csak a forrás alapján nem különböztethető meg. Ha konténerenkénti útválasztásra van szüksége, a döntésnek a fordítás előtt vagy egy Ön által irányított névtérben kell megszületnie.
A Docker maga tartja karban ezeket a szabályokat, azon a tűzfal-háttéren keresztül, amellyel a daemon konfigurálva lett. A továbbított forgalom támogatott kampóján kívül kézzel írt szabályok, DOCKER-USER, átrendeződhetnek vagy eltűnhetnek, amikor a daemon újraindul vagy a gazdagép frissül. A Docker csomagszűrésről szóló dokumentációja mutatja a láncok sorrendjét; a gyakorlati lényeg az, hogy minden szabálynak kell egy tulajdonos és egy újratöltési útvonal, amelyet tényleg tesztelt.
Tesztelje a két rendszert külön
Az egyik névtérből származó bizonyíték semmit sem mond a másikról. A VPN-konténeren belül futtatott kérés bizonyítja, hogy az alagút működik az adott konténer számára. Ez nem bizonyíték a gazdagépről, és ugyanaz a parancs egy --network host konténerből futtatva nem bizonyíték a hídról.
# host namespace
ip route get 1.1.1.1
ip -brief addr show
# a fresh container on the same bridge network
docker run --rm --network appnet alpine sh -c 'ip route; cat /etc/resolv.conf; ip -6 route'Utána ismételje meg a tesztet a valódi alkalmazáskonténerben, ne egy hasonló image-ben. Az alkalmazás hordozhat extra útvonalat, proxy környezeti változót vagy más feloldót, és ezek mindegyike megváltoztatja a választ. Minden alkalommal ellenőrizze a névfeloldást és a második címcsaládot: a felhasználó által meghatározott hidakon lévő konténerek a Docker beépített feloldóján keresztül oldódnak fel a 127.0.0.11 címen, és a híd IPv6-os alapértelmezett útvonala kiviheti a forgalmat, miközben Ön éppen egy csak IPv4-es alagút tesztelésével van elfoglalva.
Olvassa el a mintát, mielőtt a hitelesítő adatokhoz nyúl
Amikor a gazdagép működik és a konténer nem, az ok szinte mindig szerkezeti, és a kulcsok forgatása vagy a kliens újratelepítése egy délutánt pazarol el. Először rendezze a tünetet, és a javítás általában magától megnevezi magát.
| What you see | Usual cause | First check |
|---|---|---|
| Host exits through the VPN, container shows the ISP address | The container never entered the tunnel | Default route inside the container |
| Container works until the daemon restarts, then stops | Rules outside the supported hook, or a changed backend | Daemon's reported firewall backend and DOCKER-USER |
| Container loses internal hosts after the tunnel comes up | VPN prefix overlaps the Docker bridge subnet | ip route on the host, then docker network inspect |
| Small replies arrive, large ones hang | Tunnel MTU or missing MSS clamping | Link MTU on both ends of the tunnel |
| Container falls back to the ISP address when the tunnel drops | Nothing enforces the kill switch for forwarded traffic | Stop the tunnel with a request in flight |
Az átfedés sora saját mondatot érdemel. Egy VPN-profil, amely útvonalat tol a 172.17.0.0/16 felé, vagy egy olyan 10.0.0.0/8 felé, amely véletlenül tartalmazza a híd előtagját, ráveszi az alagutat, hogy igényt tartson a konténer alhálózatára, és a lefordított címekre menő válaszok rossz irányba indulnak vagy eltűnnek. A Docker-hálózat újraszámozása általában tisztább, mint a kivételek halmozása.
Tegye kifejezetté a lefedettséget, majd szándékosan törje meg
Két terv állja meg a helyét felülvizsgálatkor. Ossza meg a VPN-konténer névterét, és minden lefedett munkaterhelés egy alagutat használ egy újraindítási határral, ami egyszerű mindaddig, amíg egy szolgáltatásnak más kijáratra vagy saját DNS-útvonalra nincs szüksége. Vagy irányítsa a konténerhálózatot a gazdagép VPN-átjárójára: továbbítás engedélyezve, a híd előtagja az alagútra irányítva, a visszatérő forgalom kifejezetten kezelve. Ez hálózatonkénti irányítást vásárol, és egy szabálykészletbe kerül, amelyet a daemon- és kliensfrissítések során karban kell tartania.
Akárhogy is, a döntő teszt a hibaeset. Állítsa le az alagutat úgy, hogy közben egy konténerkérés úton van, és figyelje, hová megy a csomag. Ha visszaesik a közvetlen útra, a lefedettség soha nem érvényesült, mert egy kliens kill switch-e a kliens saját forgalmát irányítja, nem a hídról továbbított csomagokat. Ezután indítsa újra a daemont és a gazdagépet, és másodszor is erősítse meg az eredményt; ez az a pillanat, amikor a kézzel írt szabályok eltűnnek.
Mielőtt késznek nyilvánítja, erősítsen meg négy dolgot: az alagút interfésze ugyanabban a névtérben van, mint a forgalom, a konténeres teszt a valódi konténerben futott, a névfeloldás és mindkét címcsalád ellenőrizve lett, és az alagút-hibateszt továbbra is zártan hibázik. Ezután írja le a tűzfal-háttér nevét, a kliens verzióját és minden szabály tulajdonosát. Ez a feljegyzés az, ami megakadályozza, hogy a következő frissítés egy dokumentálatlan keveréket hagyjon a régi feltevésekből.