VPN қосылғанда Vagrant VM жоғалады: бұзылған маршрут кімдікі

Бір минут бұрын жауап берген машина қосылу сәтінде жоғалады. Бірдеңені өзгертуден бұрын бұзылған маршрут кімге тиесілі екенін анықтаңыз.

Машина бір минут бұрын жауап беріп тұрды, VPN қосылды, енді сол мекенжай уақыт шегінен өтіп кетеді. Бұл симптомды үш ақау туғызады және олар түрлі машиналарда тұрады. Хост жеке желіге баратын маршрутты жоғалтуы мүмкін, қонақтың NAT ауқымы туннель енді жариялап отырған ауқыммен қақтығысуы мүмкін, немесе толық туннель хосттағы барлық маршруттың иелігін алуы мүмкін. Кез келген конфигурацияны өзгертуден бұрын қайсысы болғанын анықтаңыз, өйткені әр түзету басқа жерде тұрады.

Маршрутқа қараңыз, машинаға емес

Туннель көтерілген кезде қонақ мекенжайы үшін хосттың маршруттау шешіміне қараңыз. Әлі де тек хост адаптеріне сілтейтін маршрут мәселе емес. Енді VPN адаптеріне сілтейтін маршрут мәселе, және оны клиент өзгертті, сіз емес. Адаптердің өз мекенжайын сақтауы интерфейстің аман қалғанын білдіреді, бұл жолдың аман қалуынан өзгеше факт.

Дәл қосылу сәтінде үзілетін SSH сессиясы күтілетін мінез-құлық. Клиент адаптерлерді қайта пайдаланып, маршруттарды орнатады, сондықтан байланыс бірнеше секунд өледі. Ақау — ешқашан қайтпайтын байланыс, бір сәт жыпылықтаған байланыс емес.

Туннельге дейін кестені түсіріп, одан кейін тағы бір рет түсіріңіз, содан кейін осы екі шығысты салыстырыңыз. Айырмашылық — диагноз, ол сонымен қатар желі иесі сұрайтын дәлел.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

Хосттың кестесін қосылуға дейін және кейін оқыңыз

Linux-та қабаттасатын маршруттар арасындағы басымдық префикс ұзындығы мен метрикадан келеді, сондықтан нақтырақ VPN маршруты қате болса да жеңеді. Windows-та интерфейс метрикасы теңдікті шешеді, ал туннель адаптері әдетте виртуалдыдан төмен метрикамен келеді. Екі жағдайда да көрінетін симптом бірдей: пакеттер туннель адаптерінен шығып, жоғалады.

Қонақ префиксінің маршрутының қасында адаптерлер мен олардың метрикаларын шығарыңыз. Осы шығыс жұбы иелік сұрағына бір қарағанда жауап береді.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

Маршрут өзгеріп, адаптер метрикасы өзгермесе, клиент бәсекелес маршрут орнатқан. Метрика өзгерсе, клиент адаптерлерді қайта реттеген. Екеуін де түзетуге болады және олар әр жерде түзетіледі.

Қонақтың NAT ауқымы қақтығыс болғанда

VirtualBox NAT әдепкі бойынша 10.0.2.0/24 қолданады, ал сол ауқымды итеретін туннель қонақты бұл трафикті нақты межеге емес, өз NAT шлюзіне жіберуге мәжбүр етеді. Пакет хосттан ешқашан шықпайды, сондықтан арғы жақтағы ешбір firewall журналы оны көрсетпейді. Docker Machine-де де өзінің тек-хост жоспарында осы тектес қақтығыс бар, ал ол жоспарды өзгерту машинаны сертификаттарымен бірге қайта жасауды талап етуі мүмкін.

Ауыстырманы таңдау үшін туннельдің әлдеқашан жариялағанын, содан кейін кеңсе желісі қолданатынын, содан кейін осы хосттағы әр виртуалды адаптер талап еткенін тізіп шығыңыз. Маршруттауды бұзатын нәрсе — қабаттасу, ал ұқсастықтың маңызы жоқ. Бір ауқым екіншісінің ішінде толық отыра алады, бірақ бір қарағанда мүлдем ұқсамайды.

Жаңа ауқымды машина жасалған кезде орнатыңыз, немесе оны өзгертіп қайта жүктеңіз, содан кейін сәтсіз байланысты қонақтан қайта тексеріңіз. Қонақтың өз кестесі — маңызды көрініс.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

Клиентпен ұрыспай жолды қалпына келтіріңіз

Әр платформа тек-хост префиксін қайта алдыға шығару жолын ұсынады. macOS-та тек-хост интерфейсіне статикалық маршрут келесі қосылуға дейін жұмыс істейді. Windows-та виртуалды адаптердегі төменірек интерфейс метрикасы оны басым күйде ұстайды. Linux-та алмастыру операциясы бір префиксті қамтиды. Үшеуі де уақытша шешім, өйткені өз маршруттарын қайта талап ететін клиент оларды жояды.

Жүктелу кезінде соқыр қайта қосылудың орнына тексеруді скрипт етіп жазыңыз. Әр қосылудан кейін қонақ префиксінің маршрутын шығаратын шағын скрипт жұмбақты журналдағы бір жолға айналдырады.

Профиль толық туннель болса, желі иесінен бөлінген туннель немесе құжатталған ерекшелік сұраңыз. Қауіпсіздік саясатын айналып өтетін маршруттарды үнсіз қосу түзету емес, кейінірек аудитормен бірге келетін екінші мәселе.

Түзетуді екі жақта тексеріңіз

Өзгерістен кейін үш жолды тексеріңіз: хосттан қонаққа, қонақтан корпоративтік хостқа және қонақтан интернетке. Біреуін қалпына келтіріп, екіншісін бұзатын түзету — жөндеу маскасын киген конфигурация өзгерісі. Салыстыру тең-тең болуы үшін өзгеріске дейін жинаған шығыстардың дәл өзін түсіріңіз.

Өзгерген интерфейсті, метриканы және маршрутты уақытымен бірге жазып алыңыз, келесі оқиға қайта құру емес, іздеу болсын. Бұл жазба ұзақ билет тармағынан қымбат.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

Хост қайтадан қонаққа жетіп, қонақ LAN-ға жеткенде, сіз бастаған жолды қалпына келтірдіңіз. Тек біреуі жұмыс істесе, қалған ақау басқа иесінің аумағында, ал айырмашылық қай аумақ екенін айтады.

Қатысты мақалалар