Kial macvlan-kontenero ne povas respondi al VPN-kliento

Imagu Linuksan gastiganton, kiu finas VPN-on kaj ankaŭ funkciigas konteneron en macvlan-reto. La LAN estas 192.168.60.0/24, la kontenero havas 192.168.60.210, kaj VPN-klientoj venas el 10.95.0.0/24. La kliento atingas la servon, la respondo neniam revenas, kaj ĉiu fajroŝirma regulo sur la gastiganto ŝajnas ĝusta. Du apartaj limigoj kreas tiun simptomon, kaj riparo de unu lasas la alian surloke.

Du limigoj, unu simptomo

La unua limigo estas izolado: la macvlan-ŝoforo de Docker ne permesas al kontenero paroli kun sia propra gastiganto tra la gepatra interfaco. Trafiko inter la gastiganta stako kaj la kontenero havas neniun vojon, kiel ajn la itineroj sur la gastiganto estas skribitaj.

La dua limigo estas la revena vojo. La implicita enirejo de la kontenero kutime estas la LAN-enkursigilo, do respondo adresita al VPN-kliento eliras tra tiu enkursigilo. Se la enkursigilo havas neniun itineron reen al la VPN-kolekto, la respondo estas forĵetata ie meze.

Tiuj du paneoj aspektas identaj de la klienta flanko: peto alvenas kaj respondo neniam venas. Ili bezonas malsamajn riparojn, kaj larĝa masquerade-regulo povas kaŝi, kiu el ili ankoraŭ estas rompita. Tial la unua testo estas kaptado ĉe la kontenera flanko anstataŭ plia fajroŝirma ŝanĝo. Se la peto neniam aperas tie, la izolada limigo estas tiu, kiu agas.

Konstruu la ŝimon ĉe la gastiganta flanko, mallarĝe

Dua macvlan-interfaco sur la gastiganto, alkroĉita al la sama gepatro en ponto-reĝimo, donas al la gastiganta stako propran identecon sur tiu LAN-segmento. Rezervu por ĝi adreson ekster la DHCP-kolekto kaj ekster la kontenera gamo, kaj enkursigu nur la konteneron tra ĝi.

ip link add macvlan-vpn link eth0 type macvlan mode bridge
ip address add 192.168.60.250/32 dev macvlan-vpn
ip link set macvlan-vpn up
ip route add 192.168.60.210/32 dev macvlan-vpn src 192.168.60.250

La unua komando kreas la interfacon en ponto-reĝimo, kiu estas la dokumentita implicita valoro por tiu ŝoforo kaj la reĝimo, kiun vi volas por trafiko inter gastiganto kaj kontenero. La dua asignas /32 por ke la adreso ne koliziu kun la LAN-prefikso, kaj la kvara sendas nur la adreson de la kontenero tra la ŝimo.

Ne enkursigu la tutan LAN-on tra la nova interfaco. La ordinara konektita itinero restas kia ĝi estas, kaj la gastiganta itinero estas intence mallarĝa, por ke unu kontenero gajnu vojon sen ke la resto de la segmento ŝanĝu sian konduton. Implicita itinero al la ŝimo estus alia dezajno kun aliaj sekvoj. Tenu ĝin specifa kaj la difekta radiuso restas malgranda.

Tiuj komandoj ŝanĝas la retajn agordojn sur funkcianta gastiganto. Sur aparato aŭ administrata platformo uzu la subtenatan agordan mekanismon de tiu platformo, ĉar interaga ŝanĝo per root-ŝelo eble ne postvivos ĝisdatigon.

Decidu, kiel la fonto estas konservata

Kun la ŝimo surloke, la kontenero povas atingi la gastiganton, kaj la demando fariĝas, kiun fontan adreson la respondo portas. Konservi la originalan VPN-fonton estas la pli pura modelo: la kontenero vidas la realan klientan adreson, kaj la protokoloj kaj alirreguloj de la servo povas uzi ĝin.

Por ke tio funkciu, la reta agordo de la kontenero devas por tiu vojo sendi trafikon por 10.95.0.0/24 al 192.168.60.250 kiel sia enirejo. Tio estas subtenata itinera aŭ enireja agordo interne de la propra agordo de la kontenero, ne artifiko ĉe la gastiganta flanko. Konfirmu ĝin el interne de la kontenero anstataŭ supozi, ke la agordo validiĝis. Implicita enirejo, kiu ankoraŭ montras al la LAN-enkursigilo, daŭre sendos respondojn en la saman truon.

Se la aprobita dezajno anstataŭe kaŝas la VPN-fontojn, limigu la tradukon mallarĝe: la reala VPN-kolekto, la ŝimo kiel elira interfaco, kaj la konkreta kontenero kaj servo.

iptables -t nat -A POSTROUTING -s 10.95.0.0/24 -o macvlan-vpn -j SNAT --to-source 192.168.60.250

Aligu la ŝimon kiel eliran interfacon, ne la tunelon. Regulo, kiu nomas la tunelon elira interfaco, ne kongruos kun paketo direktita al la kontenero, kaj ĝuste tiu eraro kutime troviĝas en tia aranĝo. Tenu la regulon same mallarĝa kiel la supra frazo kaj reviziu ĝin, kiam la kolekto ŝanĝiĝas.

Kontrolu de la kliento, ne de la gastiganto

Peto de la gastiganto mem, ligita al la adreso de la ŝimo, pruvas, ke la ŝimo povas atingi la konteneron. Ĝi ne pruvas, ke la kontenero povas resendi trafikon al konservita fonto 10.95.0.x, ĉar la fonta adreso en tiu testo estas la propra adreso de la ŝimo.

curl -sS --interface 192.168.60.250 -o /dev/null -w '%{http_code}\n' http://192.168.60.210:8080/health
sudo tcpdump -ni macvlan-vpn host 192.168.60.210

La unua komando testas la parton de gastiganto al kontenero, kaj la dua montras, kio efektive transiras la ŝimon dum reala VPN-kliento faras la peton. Rigardu la fontan adreson sur la enira vojo kaj ĉu respondo aperas kun la sama fluo.

Plusendado devas esti ŝaltita sur la gastiganto, kaj la plusenda vojo bezonas permeson por la VPN-kolekto al la ŝimo sur la serva pordo plus establitaj respondoj. INPUT-regulo sur la gastiganto ne rajtigas plusendatan trafikon, kio estas ofta kaŭzo, ke la paketo estas forĵetata post kiam la enkursigado aspektas ĝusta.

Lanĉu la realan aplikaĵon kun realaj legitimiloj, poste kontrolu, ke dua, nerilata servo sur la sama kontenero ankoraŭ rifuzas vin. Se la sola maniero igi ĝin funkcii estis malfermi ĉiun plusendan regulon, la dezajno ne estas finita. Notu ankaŭ, kiun fontan adreson la servo registris, ĉar tion ĝiaj propraj alirreguloj uzos de nun.