Пренасочување на VM сообраќајот во host-only мрежата преку TUN OpenVPN сервер

host-only адаптерите создаваат локална виртуелна мрежа, а рутираните TUN тунели пренесуваат IP пакети меѓу адресите. Ниту едниот не е мост кон другиот, затоа работна конфигурација мора да каже кој препраќа и чија е повратната рута. Ако ги замените овие две задачи, гостинот му одговара на тунелот со извор што клиентот на тунелот никогаш не го побарал. Дизајнот подолу ги држи двата префикса одделно и го прави повратниот пат експлицитен.

Две мрежи, два префикса

Дајте ѝ на базата на тунелот и на host-only мрежата различни префикси и никогаш не користете еден за другиот. Во овој пример VPN базата е 10.44.0.0/24, а host-only мрежата е 192.168.99.0/24, домаќинот е на 192.168.99.1, а гостин е на 192.168.99.20. Доделувањето на истиот префикс и на TUN уредот и на host-only адаптерот не ги спојува. Тоа создава две тврдења за еден адресен опсег, а табелата за рутирање потоа одговара за тврдењето што случајно го задржала.

host-only адаптерот постои на домаќинот и внатре во гостинот, и тој сам по себе нема пат надвор од машината. Мостните и NAT врски имаат различно изложување, а преминот во мостен режим не е услов за достигнување на еден сервис на гостинот.

Домаќинот веќе го држи патот

Погледнете што постои пред да додадете нешто. Домаќинот има интерфејс на host-only мрежата и рута за тој префикс, двете создадени кога адаптерот се подигнал.

ip -br addr show
ip route show 192.168.99.0/24
sysctl net.ipv4.ip_forward

Третата линија е механизмот што го прави домаќинот скок. Без него пакетот што пристигнува од тунелот е адресиран до мрежа до која домаќинот може да стигне, но нема да ја препрати. Препраќањето е потребно и не е доволно. Филтерската политика сѐ уште одлучува дали е дозволен одреден тек меѓу интерфејсот на тунелот и host-only интерфејсот, и таа одлука треба да биде писмена, а не во стандардна политика што никој не ја прочитал.

Турнете ја рутата, па филтрирајте што достигнува

Серверот може да го достави host-only префиксот до клиенти што прифаќаат туркани рути, што е истиот механизам што се користи за секоја друга подмрежа зад тунелот.

push "route 192.168.99.0 255.255.255.0"
iptables -A FORWARD -i tun0 -o vboxnet0 -d 192.168.99.20 -p tcp --dport 5432 -j ACCEPT
iptables -A FORWARD -i vboxnet0 -o tun0 -s 192.168.99.20 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Овие две правила дозволуваат еден сервис во една насока и неговите одговори. Рута што го достигнува целиот префикс и филтер што дозволува еден порт се намерна комбинација; рута плус безусловно прифаќање е патот на кој лабораториски сервис станува изложен. Турканата рута исто така не е авторизација. Клиентот ја прифаќа, домаќинот ја препраќа, а огнениот ѕид на гостинот и самиот сервис сѐ уште имаат збор.

На гостинот му треба пат назад

Гостин до кој се стигнува од 10.44.0.x мора да ги испраќа своите одговори до host-only адресата на домаќинот, или домаќинот мора да го преведе изворот. Добивањето адреса од DHCP на VirtualBox не кажува ништо за ниту едно од двете уредувања.

ip route add 10.44.0.0/24 via 192.168.99.1 dev enp0s8
ip route get 10.44.0.15

Додавањето на таа рута внатре во гостинот го зачувува оригиналниот извор, што ја задржува смислата на политиката и дневниците по клиент. Ограниченото преведување на изворот на домаќинот е алтернативата, и работи, но по цена да го сокрие тоа кој клиент се поврзал. Преклопувањето е другиот режим на откажување. Далечински клиент чија домашна LAN веќе користи 192.168.99.0/24 ќе ја чита турканата рута како сопствена мрежа, и никаква промена на страната на серверот не ја решава таа двосмисленост. Пренумерирајте една страна или изберете префикс што веројатно нема да се судри.

TUN уредот пренесува IP пакети, затоа додавањето стандарден портал внатре во гостинот не го претвора тунелот во Ethernet сегмент со host-only адаптерот. TAP мостот е различен дизајн со сопствена клиентска поддршка и сопственост на адреси, а мешањето на двата описи води до конфигурации што никогаш не се приближуваат.

Проверете, па направете да го преживее рестартирањето

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

ss -lntp '( sport = :5432 )'
conntrack -L | grep 192.168.99.20

Потоа рестартирајте го VPN сервисот и мрежата на виртуелната машина и повторете ги истите три проверки. Рачно додадената рута опстојува до следното рестартирање, а конфигурација што работи само во топла сесија не е дизајн. Забележете ги двата префикса, политиката за препраќање и рутата на гостинот заедно. Тој што ќе ја додаде следната виртуелна машина ќе ги треба сите три и инаку ќе ги открива одново со секоја неуспешна врска.