VirtualBox NAT или мост: каде завршува VPN-от на VM

Две различни прашања доаѓаат заедно секој пат кога виртуелна машина извршува VPN клиент, и нивните одговори се различни. Првото е дали тунел внатре во гостинот го штити домаќинот, а второто е дали тунел на домаќинот го покрива гостинот. Режимот на адаптерот одлучува и за двете, повеќе од самата VPN програма. NAT адаптерот го прави домаќинот видлива крајна точка, додека мостовиот адаптер го става гостинот на мрежата со сопствена адреса.

Кој всушност ја завршува шифрираната сесија

Шифрираната сесија му припаѓа на машината што ја завршува, а тоа е гостинот кога клиентот работи внатре во VM. Низ тој тунел поминува само сообраќајот што влегува во виртуелниот адаптер на гостинот, а хипервизорот никогаш сам не насочува друга машина низ гостинот. Затоа гостинот може да држи работен тунел додека домаќинот прелистува отворено. Обратното не е симетрично, и токму оваа асиметрија е делот што повеќето упатства го сфаќаат погрешно.

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

NAT го препишува гостинот додека не заличи на домаќинот

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

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Гостин што извршува сопствен клиент го завршува тој тунел внатре во гостинот, а шифрираниот сообраќај потоа излегува низ истото препишување, така што апликациите на домаќинот го задржуваат својот пат и својата излезна адреса. VirtualBox во овој режим го поседува и решавањето имиња и ги препраќа барањата на гостинот низ сопствениот механизам, освен ако не е вклучен --natdnshostresolver1. Неговото вклучување ги предава пребарувањата на гостинот на резолверот на домаќинот, што го поправа решавањето кога сликата на домаќинот е точна и исто толку предава резолвер што може да постои само внатре во тунел. VM мора да биде исклучена пред промената на поставката, а поставката му припаѓа на адаптерот, а не на програмата на гостинот.

Мостот му дава на гостинот сопствен закуп и сопствена изложеност

Мостот ги пренесува рамките на гостинот на физичкиот сегмент, затоа DHCP му дава закуп и мрежата го третира како одделен домаќин. Секој премостен гостин може да држи независен тунел со сопствена стандардна рута, а табелата на домаќинот никогаш не се менува. Цената е изложеност: гостинот одговара на емитувања, се појавува во табелите на соседите и доаѓа под безбедноста на портите на прекинувачот и изолацијата на безжичните клиенти. Тунел на домаќинот исто така не го покрива овој распоред, бидејќи рамките на гостинот никогаш не поминуваат низ стекот на домаќинот.

Таа разлика од случајот со NAT вреди да се каже отворено, наместо да се остави како навестување. На премостениот гостин му треба сопствен клиент и сопствени податоци за најава секогаш кога неговиот сообраќај мора да користи тунел. Онаму каде гостинот мора да остане невидлив за локалната мрежа, NAT или мрежа само за внатрешна употреба со контролирано рутирање е подобар дизајн.

Зошто гостинот не може да биде портата на домаќинот

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

Употребливите замени се препраќања и прокси-сервери. Локалното SSH препраќање му овозможува на домаќинот да се поврзе со сопствената повратна јамка додека гостинот го носи текот во тунелот, што ги покрива TCP услугите без инсталирање втор клиент. Терањето на сопствениот IP сообраќај на домаќинот наместо тоа да го користи тунелот на гостинот бара рутер внатре во гостинот, плус јасна рута на домаќинот и превод на домаќинот. Тоа е мал мрежен дизајн, а не квадратче за штиклирање, и бара план за повратниот пат. Кога гостинот постои само за да го извршува клиентот, ставете го клиентот на домаќинот и избришете го вишокот скок.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Резолверите и рутите не ја преминуваат границата

DNS го следи адаптерот што ја прими опцијата, затоа гостинот не го наследува резолверот на тунелот на домаќинот и домаќинот никогаш не дознава за серверот што му е турнат на гостинот. Турнатите вредности dhcp-option DNS важат за интерфејсот што ги прими, и затоа премостен гостин без клиент не може да ги реши внатрешните имиња. NAT гостинот обично ја користи обработката на DNS на хипервизорот, а разликата се гледа со една команда по околина.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

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