Vagrant VM VPN qoşulanda yox olur: xarab marşrut kimindir

Maşın bir dəqiqə əvvəl cavab verirdi, VPN qoşuldu və indi həmin ünvana vaxt aşımı verir. Üç nasazlıq bu əlaməti yaradır və onlar müxtəlif maşınlarda yerləşir. Host özəl şəbəkəyə marşrutu itirə bilər, qonağın NAT diapazonu tunelin indi elan etdiyi diapazonla toqquşa bilər, ya da tam tunel hostdakı bütün marşrutların sahibliyini götürə bilər. Hər hansı konfiqurasiyanı dəyişməzdən əvvəl hansının baş verdiyini tapın, çünki hər düzəliş başqa yerdə yerləşir.

Maşına deyil, marşruta baxın

Tunel açıqkən hostun qonaq ünvanı üçün marşrut qərarına baxın. Hələ də yalnız host adapterinə işarə edən marşrut problem deyil. İndi VPN adapterinə işarə edən marşrut problemdir və onu siz deyil, klient dəyişdirib. Adapterin ünvanını saxlaması interfeysin qaldığını göstərir, bu isə yolun qalmasından fərqli faktdır.

Tam qoşulma anında düşən SSH sessiyası gözlənilən davranışdır. Klient adapterləri təkrar işlədir və marşrutlar quraşdırır, buna görə əlaqə bir neçə saniyə ölür. Nasazlıq heç vaxt qayıtmayan əlaqədir, bir anlıq yanıb-sönən deyil.

Cədvəli tuneldən əvvəl və sonra bir də çıxarın, sonra bu iki çıxışı müqayisə edin. Fərq diaqnozdur və eyni zamanda şəbəkə sahibinin istəyəcəyi sübutdur.

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

Hostun cədvəlini qoşulmadan əvvəl və sonra oxuyun

Linuxda üst-üstə düşən marşrutlar arasında üstünlük prefiks uzunluğundan və metrikləşdirmədən gəlir, buna görə daha dəqiq VPN marşrutu səhv olsa da qalib gəlir. Windowsda bərabərliyi interfeys metriki həll edir və tunel adapteri adətən virtual adapterdən aşağı metriklə gəlir. Hər iki halda görünən əlamət eynidir: paketlər tunel adapterindən çıxır və yox olur.

Adapterləri və onların metriklərini qonaq prefiksinin marşrutunun yanında çap edin. Bu iki çıxış sahiblik sualına bir baxışda cavab verir.

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

Əgər marşrut dəyişib, adapter metriki dəyişməyibsə, klient rəqib marşrut quraşdırıb. Əgər metrik dəyişibsə, klient adapterləri yenidən sıralayıb. Hər ikisi düzəldilə bilər və onlar müxtəlif yerlərdə düzəldilir.

Qonağın NAT diapazonu toqquşma olduqda

VirtualBox NAT susmaya görə 10.0.2.0/24 diapazonundan istifadə edir və eyni diapazonu itələyən tunel qonağı həmin trafiki real təyinat yerinə deyil, öz NAT şlüzinə göndərməyə məcbur edir. Paket hostdan heç vaxt çıxmır, buna görə qarşı tərəfdə heç bir firewall jurnalı onu göstərməyəcək. Docker Machine-də yalnız host planında eyni sinif toqquşma var və həmin planı dəyişmək maşını sertifikatları ilə birlikdə yenidən yaratmağı tələb edə bilər.

Əvəzləməni tunelin artıq elan etdiyini, sonra ofis şəbəkəsinin istifadə etdiyini, sonra bu hostdakı hər virtual adapterin tutduğunu sadalayaraq seçin. Marşrutu pozan üst-üstə düşmədir, oxşarlıq isə əhəmiyyətsizdir. Bir diapazon tamamilə digərinin içində ola bilər, halbuki ilk baxışda tamamilə fərqli görünür.

Yeni diapazonu maşın yaradılarkən təyin edin və ya onu dəyişib yenidən yükləyin, sonra uğursuz əlaqəni qonaqdan yenidən sınayın. Qonağın öz cədvəli əhəmiyyətli olan görünüşdür.

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

Klientlə dava etmədən yolu bərpa edin

Hər platforma yalnız host prefiksini yenidən qaba çəkməyin bir yolunu təklif edir. macOS-da yalnız host interfeysinə statik marşrut növbəti qoşulmaya qədər işləyir. Windows-da virtual adapterdə aşağı interfeys metriki onu üstün saxlayır. Linuxda əvəzləmə əməliyyatı tək prefiksi əhatə edir. Üçü də müvəqqəti həlldir, çünki marşrutlarını yenidən təsdiqləyən klient onları ləğv edəcək.

Yoxlamanı skriptlə yazın, açılışda kor-koranə yenidən qoşulma ilə deyil. Hər qoşulmadan sonra qonaq prefiksinin marşrutunu çap edən kiçik skript sirri jurnalda bir sətrə çevirir.

Profil tam tuneldirsə, şəbəkə sahibindən bölünmüş tunel və ya sənədləşdirilmiş istisna istəyin. Təhlükəsizlik siyasətini yan keçən marşrutları sakitcə əlavə etmək düzəliş deyil, sonra auditorla birlikdə gələn ikinci problemdir.

Düzəlişi hər iki tərəfdə yoxlayın

Dəyişiklikdən sonra üç yolu yoxlayın: hostdan qonağa, qonaqdan korporativ hosta və qonaqdan internetə. Onlardan birini bərpa edib digərini pozan düzəliş təmir maskası geyinmiş konfiqurasiya dəyişikliyidir. Müqayisə bərabər olsun deyə, dəyişiklikdən əvvəl topladığınız çıxışların eynisini çıxarın.

Dəyişən interfeysi, metriki və marşrutu vaxtı ilə birlikdə qeyd edin ki, növbəti hal yenidən qurma deyil, axtarış olsun. Bu qeyd uzun bilet yazışmasından daha dəyərlidir.

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

Host yenidən qonağa çatanda və qonaq LAN-a çatanda, başladığınız yolu bərpa etmisiniz. Yalnız biri işləyəndə qalan nasazlıq digər sahibin ərazisindədir və fərq hansı ərazi olduğunu söyləyir.