ESXi гост VPN: рутирање или премошћавање — одлучите пре порт групе
Рутирани TUN тражи повратне руте; премошћени TAP тражи домет другог слоја и ширу политику порт групе. Одредите улогу пре него што проширите promiscuous режим.
Рутирајте пакете или проширите Ethernet домен: промена порт групе долази после тог избора. Из апликације са приватном адресом резултати могу изгледати исто, док су захтеви хипервизора сасвим различити. Зато се порт група прво прошири, а питање дизајна реши друго, обично после broadcast олује. Прођите ове провере редом и зауставите се док је захтев још нејасан, јер ниједна поставка порт групе не поправља дизајн који никада није изабран.
Одлука припада власнику услуге; конфигурација хипервизора треба да је спроведе, а не да је случајно одреди.
Проверите шта удаљеној страни заиста треба
Наведите услуге до којих удаљени клијенти морају стићи и протоколе које користе. Ако је списак неколико TCP услуга на познатим префиксима, рутирање то покрива. Ако нешто заиста треба суседство 2. слоја — откривање зависно од broadcast-а, не-IP протоколе, уређај који не прихвата gateway — рутирање то не може опонашати и то треба рећи рано. Будите искрени о не-IP ставкама на том списку, јер ту рутирани дизајн тихо пада недељу касније.
Затим проверите клијентски базен. Рутирани дизајн тражи распон адреса и изричиту повратну руту на удаљеној страни; премошћени дизајн тражи да проширена Ethernet домена поседује доделу адреса и изолацију. Шта год одабрали, неко изван овог VM-а мора се с тим сложити.
Шта сваки дизајн тражи од виртуелне мреже
Два дизајна се разликују по томе шта виртуелна мрежа мора поднети, а табела је најкраћи начин да се то види:
| Дизајн | Улога на страни госта | Шта виртуелна мрежа мора прихватити | Начин квара ако погрешите |
|---|---|---|---|
| Рутирани TUN | Рутер између одвојених префикса | Рутирани клијентски базен плус повратни путеви на удаљеној страни | Клијенти стигну до gateway-а и никада не стигну до услуге иза њега |
| Премошћени TAP | Премостница 2. слоја за клијенте који се придруже | Додатни Ethernet идентитети, broadcast саобраћај и VLAN правила | vSwitch одбацује оквире или дизајн тражи promiscuous режим који нико није одобрио |
Рутирање оставља broadcast домену где јесте и даје вам природно место да ограничите које услуге прелазе gateway. Премошћавање помера границу: клијенти постају учесници проширене Ethernet домене, а додела адреса, изолација и свака политика 2. слоја сада се односе на њих. Упишите изабрани ред у запис о промени. Реченица попут „рутирани TUN, клијентски базен 10.90.0.0/24, повратна рута на језгру“ спречава следећег инжењера да поново расправља дизајн из поставки порт групе.
Ко сме видети чије оквире
Поставите власнику платформе једно питање пре него што дирнете порт групу: тражи ли дизајн да овај VM прима оквире адресиране на друге учеснике? Ако је одговор не, ништа у овом одељку се не примењује, јер рутирани TUN никада не треба ту видљивост. Ако је одговор да, Broadcomове смернице за promiscuous режим су штиво које је важно: објашњавају колико више vSwitch-а VM може видети и препоручују да се та политика ограничи на једну порт групу.
Третирајте то као проверу захтева, а не дозволу. Укључите поставку за један наменски прикључак када је потреба за премошћавањем записана, а свуда другде је оставите искљученом. Широки VLAN trunk копиран из другог примера премостнице је део који се нико не сети уклонити, а дизајн са једним VLAN-ом треба да остане са једним VLAN-ом.
Забележите која се порт група променила и зашто, на истом месту где сте записали ред дизајна. Тај пар чини следећу ревизију могућом.
Држите објекте госта експлицитним
Унутар Linux-а, чланство у премосници и власништво над адресом одвојени су објекти, а њихово мешање ствара збуњујуће полурадно стање. Доделите адресе премосном интерфејсу или рутираном тунелу, не обема странама истог пута, а чланске портове држите без IP конфигурације.
Избегавајте стављање једне подмреже независно на рутирани TUN и на неповезани Ethernet интерфејс. Таква конфигурација ствара два пута до истог префикса, асиметричне одговоре и тему подршке о flapping-у која не помиње ниједан пут. Ако гост уједно хостује контејнере или локални хипервизор, проверите да се они већ не премошћују у исти uplink. Две премостнице на једној NIC су дизајн, а не несрећа коју желите открити током прозора промене.
Потврдите путањом пакета, не ping-ом
Проверите стварни пут, а не само достижност. Са клијента потврдите која изворна адреса стиже до удаљене услуге, затим да се одговор враћа истим путем. На госту проверите бројаче прослеђивања за конкретан ток, а на порт групи да није укључена додатна видљивост мимо оне коју одабрани дизајн тражи.
На крају тестирајте смер квара. Зауставите тунел или одвојите клијента и проверите да саобраћај не пада тихо на рутирани пут који сте сматрали неискоришћеним, јер тај пад је начин на који премошћени дизајн тихо постаје ненамерни рутер.