Две зелени икони за връзка изглеждат като сравнение и обикновено са съвпадение. Ако тестовата заявка е можела да използва и двата тунела, резултатът описва в най-добрия случай един от тях, а в най-лошия — нито един. Дайте на всяко наблюдение мрежов контекст, предназначена дестинация и очакване, записано преди пускането на теста. На самостоятелно управляван Linux компютър именуваните мрежови пространства от имена са най-евтиният начин да купите това разделение.

Две зелени лампи не са сравнение

Пространството от имена разделя таблиците за маршрутизация, интерфейсите и състоянието на мрежовия стек, така че заявка, започнала в едно, не може тихо да заеме тунела на друго. Това, което не разделя, е процесор, физически входен канал или услугата за разрешаване на имена, работеща на хоста. Именно в тази последна празнина повечето такива тестове се провалят, без някой да забележи. Търсене, което напуска пространството от имена и пита преобразувателя на хоста, връща отговор без никаква връзка с тествания тунел.

Тази процедура предполага две вече подготвени и одобрени тестови пространства от имена с работеща външна свързаност и поддържани клиенти. Тя не създава нищо, не регистрира нищо и не заменя никаква конфигурация. Отделните виртуални машини остават честният избор, когато клиентът се нуждае от пълна сесия на работен плот или отказва да работи извън нея.

Фиксирайте очакването преди първото пускане

Определете за всеки контекст как изглежда успехът: преобразувателят, името на услугата, очакваният адрес и поведението, изисквано при падане на тунела. Пазете тези планирани стойности в собствена колона, защото запис, който смесва план и наблюдение, е измислица с времеви печат. Списъкът по-долу е формата, от която записът се нуждае, и всеки ред трябва да може да се попълни преди първата връзка.

TunnelOwnerClient interface inside the namespaceProof commandRequired on disconnect
vpn-athe identity that owns profile A, recorded by nameits own tun device, never the host'sip -n vpn-a -4 route get 10.55.10.20traffic stops; no host-side fallback
vpn-ba separate owner, even when both run on one boxits own tun device in its own namespaceip -n vpn-b -4 route get 10.55.20.20verified separately, never inferred from A

Окабеляването на преобразувателя заслужава собствен ред в този запис, защото това е полето, което най-вероятно ще излъже. Файлове, обвързани с пространството от имена, като /etc/netns/vpn-a/resolv.conf се появяват на обичайните си пътища, когато команда се изпълнява вътре в пространството от имена, както справката на iproute2 за пространства от имена описва, но конфигурацията за превключване на услугата за имена и всеки локален преобразувател, който тя стартира, все още могат да дръпнат търсенето обратно към хоста.

Един тунел наведнъж, другият изключен

Свържете A чрез съществуващия му собственик, докато B остава изключен, после прегледайте политиката, маршрутите и избрания път от административния контекст. Три от командите по-долу четат състояние; само последната се свързва с услуга за имена, и нито една от тях не изпраща заявка на приложение.

sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internal

Търсенето на маршрут отговаря на хипотетичен въпрос за дестинация, затова не може да покаже, че услугата приема трафик. Пазете тези два вида доказателства в отделни колони, защото здрав маршрут до отказана връзка е реален и често срещан резултат. След това изпратете една безвредна разрешена заявка с истинското приложение, стартирано в контекста на A като неговия обикновен непривилегирован потребител, с непокътнати проверка на сертификата и удостоверяване на приложението, и запишете резултата заедно с адреса на източника, който услугата е видяла. Изключете A чрез собственика му и повторете цялата базова линия за B, отбелязвайки всяка промяна в конфигурацията, която правите, иначе двете базови линии престават да бъдат сравними.

И двете включени, после по едно

Устойчивото състояние е лесната част. С двата свързани тунела повторете търсенето и заявката на приложението за всеки контекст, после прекъснете единия тунел и проверете другия. Свържете отново в обратна последователност, когато самият ред на свързване е въпросът.

sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20

Прихващането решава спорове, които резултатът на приложението не може: то показва дали заявката е излязла през интерфейса, който очаквате, или през нещо съвсем друго. За всеки преход запишете действието на собственика, времевия печат, резултата от маршрута, резултата от името и изхода на приложението. После проверете изискването за безопасно затваряне вътре в засегнатото пространство от имена, защото изолацията не е прекъсвач. Пространството от имена държи два тунела разделени; то не спира нито един от тях да носи трафик, когато профилът му казва, че трафикът трябва да спре.

Какво може и какво не може да твърди този запис

Успешното преминаване доказва тези наблюдения за тази подредба, на този хост, в онова време. То не казва нищо за два клиента, споделящи една таблица за маршрутизация на работен плот, нито за пропускателна способност, докато двата тунела носят товар. Това са отделни въпроси с отделни тестове и сравнението е толкова добро, колкото е контекстът, прикачен към всеки ред.

Пазете провалите в записа до успехите, отбелязани с кой тунел е бил включен по онова време. Чиста страница, която крие състоянието при измерването, е по-лоша от грозна, която го показва. Това, което прави записа използваем отново по-късно, е контекстът, а не оценката.

Два тунела на един компютър могат да се сравнят честно, но само в толкова контексти, колкото наистина сте контролирали. Всичко отвъд това е желание със зелена икона до него.

Подобни статии