Docker-houerverkeer omseil jou gasheer-VPN: hoe om dit te kontroleer

Jou gasheer se blaaier wys die VPN-uitgangsadres, die houer rapporteer jou tuisverbinding, en iemand noem dit 'n lek. Niks het gelek nie. 'n Gasheertonnel is 'n bondel koppelvlakke, roetes en reels wat aan die gasheer se netwerknaamruimte behoort, en 'n houer op 'n brug is 'n ander naamruimte met sy eie verstekroete. Ek het op 'n Compose-stapel gesit waar die VPN-kliënt weke lank gekonnekteer was en nie een houerpakkie ooit daarin beland het nie.

Kontroleer die naamruimte voor die taakbalkikoon

Naamruimtes is die hele argument. Wanneer Docker 'n houer op 'n brugnetwerk begin, skep dit 'n netwerknaamruimte, heg een punt van 'n veth-paar daarin vas, en gee daardie naamruimte 'n adres en 'n verstekroete. Die tonnelkoppelvlak, wat dit ook al genoem word, woon in die gasheer se naamruimte. Verkeer binne die houer kan dit nie sien nie, en geen kliëntinstelling verander dit van buite nie.

Twee ondersteunde skuiwe kry jou uit die isolasie. --network host plaas die houer binne die gasheer se naamruimte, sodat dit die gasheer se roetes erf en dus die tonnel. --network container:vpn deel 'n ander houer se naamruimte, wat is hoe die meeste sidecar-ontwerpe 'n werklading deur 'n VPN-houer stuur. Albei is eksplisiete keuses; net een van hulle is gewoonlik wat die persoon wat dit ontplooi het, bedoel het.

Gasheermodus is nie 'n gratis opgradering nie. Die houer hou op om sy eie adres te hê, poortpublikasie hou op om te geld, en 'n proses met NET_ADMIN daar kan die gasheer se roetebepaling herskryf. Om dit te aanvaar kan die regte besluit wees. Om te aanvaar dit is reeds aan is hoe mense 'n aand spandeer om 'n tonnel te ontfout wat nooit in die pad was nie.

Volg die pakkie van die brug af

'n Brughouer stuur sy pakkie na sy verstekpoort, wat die brugkoppelvlak op die gasheer is. Die gasheer stuur die pakkie dan aan en, in die verstekkonfigurasie, vertaal die bronadres na sy eie voordat die pakkie vertrek. Dit is daardie vertaalstap wat beleid stilweg verydel.

Teen die tyd dat die pakkie die tonnel-eindpunt bereik, dra dit die gasheer se adres. Enige reël, beleidsroete of split-tonnelbesluit wat op die houer se oorspronklike adres gesleutel is, hou op om te pas, en twee houers wat bedoel is om deur verskillende uitgange te vertrek, kan nie net aan die bron uitgeken word nie. As jy roetering per houer nodig het, moet die besluit voor die vertaling gebeur of binne 'n naamruimte wat jy beheer.

Docker onderhou hierdie reëls self, deur watter vuurmuur-agterkant die daemon ook al mee opgestel is. Handgeskrewe reëls buite die ondersteunde haak vir deurgestuurde verkeer, DOCKER-USER, kan herrangskik of laat vaar word wanneer die daemon herbegin of die gasheer opgradeer. Die Docker se dokumentasie oor pakkiefiltering wys die kettingorde; die praktiese punt is dat elke reël 'n eienaar en 'n herlaaipad nodig het wat jy werklik getoets het.

Toets die twee stelsels afsonderlik

Bewyse uit een naamruimte sê niks oor die ander nie. 'n Versoek wat binne die VPN-houer uitgevoer word, bewys die tonnel werk vir daardie houer. Dit is nie bewyse oor die gasheer nie, en dieselfde opdrag wat uit 'n --network host-houer uitgevoer word, is nie bewyse oor die brug nie.

# 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'

Herhaal dan die toets binne die werklike toepassinghouer eerder as 'n soortgelyke beeld. Die app kan 'n ekstra roete, 'n proxy-omgewingsveranderlike of 'n ander oplosser dra, en elkeen daarvan verander die antwoord. Kontroleer naamoplossing en die tweede adresfamilie elke keer: houers op gebruikergedefinieerde brûe los op deur Docker se ingeboude oplosser by 127.0.0.11, en 'n IPv6-verstekroete op die brug kan verkeer uitdra terwyl jy besig is om 'n slegs-IPv4-tonnel te toets.

Lees die patroon voordat jy aan geloofsbriewe raak

Wanneer die gasheer werk en die houer nie, is die oorsaak byna elke keer struktureel, en om sleutels te roteer of die kliënt te herinstalleer mors 'n middag. Sorteer eers die simptoom en die oplossing noem gewoonlik homself.

Die oorvleuelingsry verdien 'n sin van sy eie. 'n VPN-profiel wat 'n roete vir 172.17.0.0/16 stoot, of vir 'n 10.0.0.0/8 wat toevallig jou brugvoorvoegsel bevat, maak dat die tonnel die houersubnet opeis, en antwoorde na vertaalde adresse sal in die verkeerde rigting gaan of verdwyn. Om die Docker-netwerk te hernommer is gewoonlik skoner as om uitsonderings op te hoop.

Maak dekking eksplisiet en breek dit dan doelbewus

Twee ontwerpe hou stand onder hersiening. Deel die VPN-houer se naamruimte en elke gedekte werklading gebruik een tonnel met een herbegin-grens, wat eenvoudig is totdat een diens 'n ander uitgang of sy eie DNS-pad nodig het. Of roeteer die houernetwerk na 'n VPN-poort op die gasheer: deurstuur geaktiveer, die brugvoorvoegsel na die tonnel gerig, terugverkeer eksplisiet hanteer. Dit koop beheer per netwerk en kos jou 'n reëlstel om oor daemon- en kliëntopgraderings heen te onderhou.

Hoe dit ook al sy, die toets wat saak maak is die foutgeval. Stop die tonnel met 'n houerversoek in die lug en kyk waar die pakkie heen gaan. As dit terugval na die direkte pad, was dekking nooit afgedwing nie, want 'n kliënt se kill switch beheer die kliënt se eie verkeer en nie deurgestuurde pakkies van 'n brug nie. Herbegin daarna die daemon en die gasheer en bevestig die resultaat 'n tweede keer; dit is die oomblik wanneer handgeskrewe reëls verdwyn.

Voordat jy dit klaar noem, bevestig vier dinge: die tonnelkoppelvlak sit in dieselfde naamruimte as die verkeer, die houertoets het binne die werklike houer geloop, naamoplossing en beide adresfamilies is nagegaan, en die tonnelfouttoets misluk steeds gesluit. Skryf dan die vuurmuur-agterkant, die kliëntweergawe en die eienaar van elke reël neer. Daardie rekord is wat keer dat die volgende opgradering 'n ongedokumenteerde mengsel van ou aannames in plek laat.