VMware көпірлік қонағы OpenVPN-нен кейін желісін жоғалтты
Жаңа TAP адаптері VMware қай хост NIC-іне көпір жасайтынын өзгертті. VMnet0-ді бекіту мен қонақты маршруттау арасында шешім қабылдап, содан кейін нәтижені VM ішінде оқыңыз.
Бір сағат бұрын көпірлік болып, қолжетімді болған қонақ енді бәрінде уақыт шегіне жетеді, және ешкім оның параметрлерін өзгертпеген. Хостта интернет әлі де туннель арқылы жұмыс істейді. Бұл екі факт бірге VPN-нен алыстап, гипервизорға қарай бағыттайды, өйткені хост пен қонақ енді бірдей жолды пайдаланбайды. Мұны тудыру үшін бір ғана жаңа виртуалды адаптер жеткілікті.
Қонақ өзгерген жоқ, көпір өзгерді
Windows-қа OpenVPN клиентін орнату туннель көтерілгенде қызмет байланысатын виртуалды желілік адаптер қосады. Операциялық жүйе үшін ол байланыс күйі бар кәдімгі интерфейс және жиі өз мекенжайлары бар сияқты көрінеді. Бұл VMware-ге оны көпір үміткері ретінде қарауға жеткілікті.
VMnet0 әдепкі бойынша Автоматты түрде орнатылған, яғни гипервизор әр көпір жасаған сайын хост адаптерін таңдайды. Жаңа орнатылған виртуалды адаптер осы топқа қосылады, ал егер ол таңдалса, қонақ жіберген әрбір кадр физикалық коммутатор портына емес, туннель құрылғысына кетеді.
Көпірді бекітіңіз немесе қонақты маршруттаңыз
Бірінші тармақ қонақ физикалық LAN-да тең құқықты қатысушы болуы керек кезде дұрыс: көпірдің таңдауына жол бермеуді тоқтатыңыз және адаптерді анық атаңыз. Екінші тармақ қонақ корпоративтік туннельді пайдалануы керек кезде қолданылады, және бұл жағдайда көпір ешқашан дұрыс дизайн болмаған, өйткені көпірлік қонақ хосттың VPN маршрутын мұра етпейді.
Мұны алдымен шешіңіз, өйткені екі жауап басқа жұмысқа әкеледі. Ретті кері айналдыру ешқашан көпірленбеуі керек қонаққа дұрыс бекітілген көпір жасайды.
Бірінші тармақ үшін хостта Virtual Network Editor ашыңыз, VMnet0 таңдап, Автоматты физикалық адаптермен ауыстырыңыз. Бірнеше адаптер болса, автоматты параметрлер тізімін пайдаланыңыз және ешқашан қонақ трафигін тасымалдамауы тиіс барлық нәрсенің белгісін алып тастаңыз: OpenVPN TAP немесе Wintun құрылғысы, сондай-ақ Hyper-V, WSL, Docker және loopback адаптерлері. Ноутбукта сымды да, сымсыз да физикалық адаптерді белгілі күйде қалдырыңыз, әйтпесе пайдаланушы оны келесі жолы докқа қосқанда қонақ көпірінен айырылады.
Таңдауды шешетін үш шарт
Көпірдің жалпы сәйкес келуі қонақтың не үшін екеніне байланысты. Қонақ LAN-да өз хосты ретінде, өз мекенжайымен және өз кіру қолжетімділігімен көрінуі керек болса, көпір дұрыс модель және бекіту — бүкіл түзету. Қонаққа тек шығу рұқсаты қажет болса, тек хостқа арналған желі немесе NAT қарапайым және адаптер ауысуына төзімді.
Қонақ хостпен бірдей туннельді пайдалануы керек болса, көпір режимі де, бекітілген адаптер де көмектеспейді, өйткені қонақтың трафигі ешқашан хосттың маршруттау шешіміне кірмейді. Бұл жағдай хостта маршрутталған немесе аударылған жолды қажет етеді, ал адаптер таңдауы маңызсыз болады.
VMware Player интерфейсінде желі редакторы жоқ, сондықтан тек Player жұмыс істейтін хост бұл параметрлерге жету үшін жеке редакторды немесе Workstation орнатуын қажет етеді. Бұл шектеу кейде тәсілді өзі шешеді.
Нәтижені қонақтың ішінен оқыңыз
Виртуалды NIC-ті қайта іске қосыңыз немесе қонақты қайта іске қосыңыз, ол қайта жалдау сұрасын. Содан кейін хост конфигурациялады деп ойлағанды емес, ол шын мәнінде не алғанын оқыңыз.
ipconfig /all
ip addr
ip route
Осы шығыстағы екі өрісті оқыңыз, қалғанын әзірге елемеңіз. Шлюз LAN маршрутизаторы болуы керек, ал адаптер сипаттамасы туннельді емес, VMware Ethernet құрылғысын атауы керек. 169.254.0.0/16 ішінде өзіне берілген мекенжай ешбір DHCP сервері жауап бермегенін білдіреді, және көпір туннель адаптеріне қонақ жағынан дәл осылай көрінеді.
Басқа нәрсені өзгертуден бұрын тағы бір айырмашылықты атап өткен жөн. Маршрутизаторға жетіп, интернетке жетпейтін қонақтың жұмыс істеп тұрған көпірі және жоғары жақта мәселесі бар. Туннель ауқымында мекенжай алған қонақ әлі де дұрыс емес құрылғыға қосылған. TAP адаптерін өшіру екі жағдайдың ешқайсысы үшін шешім емес, өйткені OpenVPN қызметіне ол қажет.