Видове суичове

В зависимост от начина на инсталация/активиране на Hyper-V ролята и от целевата операционна система, като версия и вариант, може да се окажем в ситуация без нито един предварително създаден суич или само с т.нар. Default Switch. Последният обикновено се появява под потребителските версии на Windows. Преди да му обърнем малко повече внимание, нека да си припомним какви типове суичове поддържа Hyper-V:

  • Private Switch - позволява комуникация само между виртуалните машини, закачени към него
  • Internal Switch - позволява комуникация между виртуалните машини, закачени към него и хоста
  • External Switch - позволява комуникация между виртуалните машини, закачени към него, хоста и всички други мрежови устройства, закачени към същата мрежа, в която е мрежовата карта, асоциирана със суича

Може би по-подходящо е да ги сравним в таблица като тази:

Суич VM <-> VM VM <-> хост VM <-> външния свят
Private да нe не
Internal да да не
External да да да

Всички тези можем да управляваме както през графичния интерфейс (Action > Virtual Switch Manager), така от командия ред чрез команди като New-VMSwitch, Remove-VMSwitch и др.

NAT суич и Default суич

Добре, но по-горе няма нищо за Default Switch-а, а още по-малко за NAT такъв. Защо? Каква категория са те?

Нека да адресираме въпросите един по един.

Първо, Default Switch-а и NAT суича са един вид специализирани Internal Switch-ове. Т.е. не са самостоятелна категория, а по-скоро частен случай на такава.

Второ, в голяма степен техните фукции и възможности се припокриват. На практика и двата осигуряват NAT функционалност. Разликата е в това, че Default Switch-а в добавка предлага и DHCP фукнционалности.

Това води до следващ въпрос. Защо тогава би ни се наложило да си направим NAT суич?

Има две основателни причини за това. Първо, може да се окажем в ситуация с несъществуващ Default Switch. Второ, потребителски създаденият NAT суич ни дава повече контрол, а именно:

  • можем да изберем потребителско име и адресно пространство
  • можем да задаваме port-forwarding правила

Все пак има и две лоши новини. Първо, NAT суич можем да направим единствено в командния ред. Второ, няма вградени DHCP възможности.

Нека да адресираме и двете “лоши новини”.

Създаване на NAT суич

Нека да си представим, че искаме да създадем NAT суич с име NAT vSwitch, с адресно пространство 192.168.99.0/24 и гейтуей 192.168.99.1.

Това може да бъде постигнато по следния начин:

  • Отваряте PowerShell сесия с Run as administrator

  • Създавате интърнал суич:

New-VMSwitch -SwitchName "NAT vSwitch" -SwitchType Internal
  • Задавате адрес на новосъздадения виртуален интерфейс:
New-NetIPAddress -IPAddress 192.168.99.1 -PrefixLength 24 -InterfaceAlias "vEthernet (NAT vSwitch)"
  • Създавате NAT мрежа с адресно пространство, включващо адреса на виртуалния интерфейс:
New-NetNAT -Name "NAT Network" -InternalIPInterfaceAddressPrefix 192.168.99.0/24

Това е. Вече имаме NAT суич и можем да започнем да закачваме машини към него.

Пренасочване на портове

След като имаме всичко това, рано или късно, на дневен ред ще излезе нуждата от дефиниране на правила за пренасочване (port-forwarding). Нека да видим как става това.

За да ни е по-лесно, нека да стъпим на следната постановка:

Hyper-V NAT суич + пренасочване на портове

Тук имаме следното:

  • два хоста - venus (192.168.1.50) и mars (192.168.1.60)

  • на mars има активна Hyper-V роля, NAT суич (192.168.99.0/24) и две виртуални машини - VM1 (192.168.99.101) с инсталиран уеб сървър и VM2 *(192.168.99.102) с инсталиран SSH сървър

Имаме три основни варианта за работа с услугите в двете виртуални машини:

  • от друг участник в същата виртуална мрежа

  • от хоста, на който работят виртуалните машини (mars)

  • от друг участник (примерно venus) във физическата мрежа, към която е закачен хоста (mars)

Първият вариант не представлява интерес в случая.

Вторият вариант на практика е частен случай на първия, защото хостът (mars) е участник в същата тази виртуална мрежа и съответно може да достигне всяка от услугите, използвайки IP адреса на съответната виртуална машина и евентуално порта, на който слуша услугата (ако е различен от стандартния). Ето две примерни команди:

curl.exe http://192.168.99.101

ssh 192.168.99.102

Третият вариант е най-интересен в случая и е осъществим именно чрез правила за пренасочване на портове.

Ако искаме да направим уеб услугата във VM1 достижима за външния свят на порт 8080 на хоста (mars), трябва да изпълним следната команда:

Add-NetNatStaticMapping -NatName "NAT Network" -Protocol TCP -ExternalIPAddress "0.0.0.0/24" -ExternalPort 8080 -InternalIPAddress 192.168.99.101 -InternalPort 80

По същия начин, ако искаме да направим SSH услугата във VM2 достижима за външния свят на порт 10001 на хоста (mars), ще трябва да изпълним следната команда:

Add-NetNatStaticMapping -NatName "NAT Network" -Protocol TCP -ExternalIPAddress "0.0.0.0/24" -ExternalPort 10001 -InternalIPAddress 192.168.99.102 -InternalPort 22

Имайки тези две правила, можем да досигнем до всяка от двете услуги от друг участник във физическата мрежа на хоста, примерно venus, използвайки комбинация от IP адреса на хоста (192.168.1.60) и съответния публикуван порт (8080 или 10001).

Ето двете примерни команди от по-рано, но адаптирани за връзка от venus, през mars, към съответната виртуална машина и услугата, работеща в нея:

curl.exe http://192.168.1.60:8080

ssh -p 10001 192.168.1.60

Разбира се, има и други команди, свързани с управлението на пренасочването на портове. Например, ако искаме да изследваме наличните правила или да премахнем такива, можем да изпозлваме съответно командите Get-NetNatStaticMapping и Remove-NetNatStaticMapping.

Нека да подкрепим тези две команди с примери.

Ако искаме да видим списък с вече дефинираните правила за пренасочване за нашия NAT суич и свързаната с него мрежа, е достатъчно да изпълним следната команда:

Get-NetNatStaticMapping -NatName "NAT Network"

Тук трябва да запомним техните StaticMappingID. Те ще ни трябват за изтриването на правилата.

Ако искаме да изтрием двете правила, които дефинирахме по-рано, то можем да изпълним следното (приемаме, че техните идентификационни номера са съответно 0 и 1):

Remove-NetNatStaticMapping -NatName "NAT Network" -StaticMappingID 0

Remove-NetNatStaticMapping -NatName "NAT Network" -StaticMappingID 1

Вече разполагаме с всичко необходимо и контролът е в нашите ръце.

Почистване

Накрая, ако искаме да премахнем NAT суича, първо трябва да разкачим всички виртуални машини от него и след това, в PowerShell сесия, стартирана с Run as administrator, трябва да изпълним следната команда:

Remove-VMSwitch -SwitchName "NAT vSwitch"

А какво стана с DHCP?

Добре, това е ясно, но все още не сме адресирали проблема с липсващата DHCP функционалност.

Така е. За съжаление, няма директно и лесно решение, но пък за сметка на това, имаме пълната свобода да импровизираме. Достатъчно е да си направите малка виртуална машина, в която да инсталирате DHCP сървър и да я свържете към въпросния суич.

За идеи и/или готово решение, можете да погледнете тук: https://github.com/shekeriev/ahvdhcp