Docker и VM сообраќај зад OpenVPN: рутирање или пренумерирање?

Контејнерите и гостите на домаќин со OpenVPN клиент или ја губат повратната патека или се судираат со префиксот на тунелот. Три прашања го избираат решението.

Домаќинот прелистува низ тунелот, а контејнерот до него не стигнува никаде. Објавувањето порта од контејнер што води сопствен VPN клиент е полошо: барањето пристигнува, а одговорот никогаш не излегува. И двете се одлуки за рутирање на домаќинот, а Docker е само гласник.

Три прашања одлучуваат кој од двата случаи го гледате, и траат околу една минута.

Два дефекти што изгледаат исто

Првиот е проблем со повратната патека. Објавената порта се преведува во контејнерот, барањето пристигнува, а одговорот се рутира преку стандардната рута на домаќинот, која OpenVPN клиентот ја насочил кон tun0. Одговорот излегува од адреса што далечниот партнер не ја очекува, и се отфрла. Вториот е судир на префикси: стандардниот мост на Docker поседува 172.17.0.0/16, а корпоративен тунел го турка истиот опсег.

Едниот се поправа со табела за рутирање, другиот со пренумерирање на мост. Уредување пред да знаете кој е кој е начинот да расипете работен контејнер.

Одлучете со три прашања

Прашање прво: дали дефектот исчезнува кога ќе го запрете VPN? Ако сè работи со исклучен тунел, посомневајте се во повратната патека. Прашање второ: дали ip route show table all го наведува истиот префикс двапати, еднаш на мост и еднаш на tun0? Тоа е судирот. Прашање трето: дали засегнатата адреса е контејнер, NAT гостин или гостин поврзан преку мост?

Третото прашање е важно зашто секој има различно точно решение, а примената на решението за контејнер врз libvirt гостин троши една вечер.

ip route
ip route show table all | grep -E '172\.1[7-9]|10\.8'
docker network inspect bridge --format '{{.IPAM.Config}}'

Повратна патека: табела за една изворна адреса

Кога сообраќајот на контејнерот мора да излезе низ физичкиот интерфејс, додека самиот домаќин го користи тунелот, рутирање засновано на изворот е најмалата промена. Додајте правило што одговара на адресата на контејнерот и пратете го во посебна табела. Ништо друго на домаќинот не се поместува.

ip rule add from 172.22.0.3 lookup 10
ip route add default via 172.22.0.1 table 10

Секој пакет чиј извор е таа адреса прво ја проверува табелата 10, а табелата 10 го праќа на портата на мостот наместо во тунелот.

Потврдете со ip route get 1.1.1.1 from 172.22.0.3. Одговорот мора да го наведе интерфејсот на мостот, не tun0. Правилата додадени на овој начин исчезнуваат при рестарт, па ставете ги во единицата или мрежната кука што го поседува контејнерот.

Истата шема работи и за WireGuard контејнер, каде и патеката на одговорот бара експлицитно правило.

Судир на префикси: пренумерирајте го мостот

Табелата за рутирање праќа еден префикс на едно место. Ако VPN го турка 172.17.0.0/16 додека мостот на Docker веќе е таму, победува помалата метрика: Docker ја поставува својата поврзана рута со метрика 0, а турнатата рута пристигнува со 50. Тогаш тунелот изгледа расипан додека Docker продолжува да работи, или обратно, зависно од редоследот на инсталација. Пренумерирајте го мостот наместо да се борите со метриката.

{
  "bip": "10.200.0.1/24",
  "default-address-pools": [{"base": "10.201.0.0/16", "size": 24}]
}

По промената рестартирајте го Docker и повторно создадете мрежи изградени со стариот базен. Менувањето на метриката само го преместува конфликтот во следното подигање.

VM бараат повторно друг одговор

libvirt гостин на стандардната NAT мрежа го наследува рутирањето на домаќинот и престанува да стигнува надвор кога тунелот на домаќинот ќе ја преземе стандардната рута. Префрлањето на гостинот на мост или macvtap уред му дава сопствена патека на физичката мрежа. Во virt-manager додајте хардвер, изберете Network, поставете го изворот на macvtap уредот на домаќинот, задржете virtio како модел, потоа деактивирајте го стариот NAT интерфејс.

macvtap гостинот обично не може да стигне до својот домаќин. Тоа е очекувано однесување, а не дефект, и припаѓа во белешката што ја оставате.

За гостин на кого му треба само LAN на домаќинот, клиентот на добавувачот може да го има прекинувачот што недостасува: со Mullvad mullvad lan set allow ја враќа локалната достапност без да го допре libvirt. И кога контејнер треба да биде достапен само преку тунелот, врзете ја објавената порта за адресата на тунелот, -p 10.8.0.5:8080:8080, наместо да ја објавувате на секоја адреса.

Поврзани статии