VPN bağlanınca Vagrant VM kayboluyor: bozulan yol kimin

Makine bir dakika önce yanıt veriyordu, VPN bağlandı ve şimdi aynı adres zaman aşımına uğruyor. Üç arıza bu belirtiyi üretir ve farklı makinelerde yaşarlar. Ana makine özel ağa giden yolu kaybedebilir, konuğun NAT aralığı tünelin artık duyurduğu bir aralıkla çakışabilir veya tam tünel ana makinedeki her yolun sahipliğini alabilir. Herhangi bir yapılandırmayı değiştirmeden önce hangisinin olduğunu bulun, çünkü her düzeltme başka bir yerde yaşar.

Yola bakın, makineye değil

Tünel açıkken konuk adresi için ana makinenin yönlendirme kararına bakın. Hâlâ yalnızca ana makine bağdaştırıcısına işaret eden yol sorun değildir. Artık VPN bağdaştırıcısına işaret eden yol sorundur ve onu siz değil istemci değiştirdi. Bağdaştırıcının adresini koruması arayüzün hayatta kaldığını söyler, bu yolun hayatta kalmasından farklı bir olgudur.

Tam bağlantı anında düşen bir SSH oturumu beklenen davranıştır. İstemci bağdaştırıcıları geri dönüştürür ve yollar kurar, bu yüzden bağlantı birkaç saniye ölür. Arıza, asla geri gelmeyen bağlantıdır, bir an yanıp sönen değil.

Tabloyu tünelden önce ve bir kez de sonra yakalayın, sonra bu iki çıktıyı karşılaştırın. Fark tanının kendisidir ve ağ sahibinin isteyeceği kanıt da odur.

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

Ana makinenin tablosunu önce ve sonra okuyun

Linux'ta çakışan yollar arasındaki tercih önek uzunluğundan ve metrikten gelir, bu yüzden daha belirgin bir VPN yolu yanlış olsa bile kazanır. Windows'ta eşitliği arayüz metriği belirler ve tünel bağdaştırıcısı genellikle sanaldan daha düşük metrikle gelir. Her iki durumda görünen belirti aynıdır: paketler tünel bağdaştırıcısından çıkar ve kaybolur.

Bağdaştırıcıları ve metriklerini konuk önekinin yolu yanında yazdırın. Bu çıktı çifti sahiplik sorusunu tek bakışta yanıtlar.

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

Yol değişti ama bağdaştırıcı metriği değişmediyse istemci rakip bir yol kurdu. Metrik değiştiyse istemci bağdaştırıcıları yeniden sıraladı. İkisi de düzeltilebilir ve farklı yerlerde düzeltilir.

Konuğun NAT aralığı çakışma olduğunda

VirtualBox NAT varsayılan olarak 10.0.2.0/24 kullanır ve aynı aralığı iten bir tünel konuğu o trafiği gerçek hedefe değil kendi NAT geçidine göndermeye zorlar. Paket ana makineden hiç ayrılmaz, bu yüzden karşı taraftaki hiçbir güvenlik duvarı günlüğü onu göstermez. Docker Machine de yalnızca ana makine planında aynı sınıf çakışmaya sahiptir ve o planı değiştirmek makinenin sertifikalarıyla birlikte yeniden oluşturulmasını gerektirebilir.

Değişimi seçmek için tünelin zaten ne duyurduğunu, sonra ofis ağının ne kullandığını, sonra bu ana makinedeki her sanal bağdaştırıcının ne talep ettiğini listeleyin. Yönlendirmeyi bozan şey örtüşmedir ve benzerlik önemsizdir. Bir aralık tamamen diğerinin içinde oturabilir, oysa ilk bakışta hiç benzemez.

Yeni aralığı makine oluşturulurken ayarlayın veya değiştirip yeniden yükleyin, sonra başarısız bağlantıyı konuktan yeniden deneyin. Önemli olan konuğun kendi tablosudur.

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

İstemciyle kavga etmeden yolu geri getirin

Her platform yalnızca ana makine önekini yeniden öne getirmenin bir yolunu sunar. macOS'ta yalnızca ana makine arayüzüne statik yol bir sonraki bağlantıya kadar çalışır. Windows'ta sanal bağdaştırıcıdaki daha düşük arayüz metriği onu tercih edilen tutar. Linux'ta değiştirme işlemi tek bir öneği kapsar. Üçü de geçici çözümdür, çünkü yollarını yeniden dayatan istemci onları iptal eder.

Açılışta kör bir yeniden bağlanma yerine denetimi betikleyin. Her bağlantıdan sonra konuk önekinin yolunu yazdıran küçük bir betik bir gizemi günlükte bir satıra çevirir.

Profil tam tünel ise ağ sahibinden bölünmüş tünel veya belgelenmiş bir istisna isteyin. Güvenlik politikasını atlayan yolları sessizce eklemek düzeltme değil, sonra denetçiyle birlikte gelen ikinci bir sorundur.

Düzeltmeyi iki tarafta da denetleyin

Değişiklikten sonra üç yolu doğrulayın: ana makineden konuğa, konuktan kurumsal ana makineye ve konuktan internete. Birini geri getirip diğerini bozan düzeltme, onarım kılığına girmiş bir yapılandırma değişikliğidir. Karşılaştırma eşit koşullarda olsun diye değişiklikten önce topladığınız çıktıların aynısını yakalayın.

Değişen arayüzü, metriği ve yolu saatle birlikte not edin, böylece bir sonraki olay yeniden inşa değil arama olur. O not uzun bir bilet dizisinden daha değerlidir.

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

Ana makine konuğa yeniden ulaştığında ve konuk LAN'a ulaştığında başladığınız yolu geri getirmiş olursunuz. Bunlardan yalnızca biri çalışıyorsa kalan arıza diğer sahibin bölgesindedir ve fark hangi bölge olduğunu söyler.