Два VPN на една Linux машина: тестирајте го секој одделно без мешање резултати

Две зелени икони за врска изгледаат како споредба и обично се случајност. Ако тест-барањето можело да го користи било кој од двата тунели, резултатот во најдобар случај опишува еден од нив, а во најлош ниту еден. Дајте му на секое набљудување мрежен контекст, предвидена дестинација и очекување запишано пред тестот да се изврши. На Linux машина што самите ја управувате, именуваните мрежни именик-простори се најевтиниот начин да се купи тоа раздвојување.

Две зелени светла не се споредба

Именик-просторот ги одвојува табелите за рутирање, интерфејсите и состојбата на мрежниот стек, па барање започнато во еден не може тивко да позајми тунел од друг. Она што не го одвојува се процесорот, физичката нагорна врска или демонот за решавање имиња што работи на домаќинот. Токму во оваа последна празнина повеќето од овие тестови пропаѓаат без никој да забележи. Пребарувањето што излегува од именик-просторот и го прашува решавачот на домаќинот враќа одговор без никаква врска со тунелот што се тестира.

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

Зацврстете го очекувањето пред првото извршување

Одредете за секој контекст како изгледа успехот: решавачот, името на услугата, очекуваната адреса и однесувањето што се бара кога тунелот паѓа. Чувајте ги тие планирани вредности во сопствена колона, зашто запис што меша план и набљудување е фикција со временски печат. Списокот за проверка подолу е формата што му треба на записот, и секој ред мора да може да се пополни пред првата врска.

Поврзувањето на решавачот заслужува свој ред во тој запис, зашто тоа е полето што најверојатно ќе лаже. Датотеките врзани за именик-просторот, како /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

Снимањето решава спорови што резултатот на апликацијата не може: покажува дали барањето излегло низ интерфејсот што го очекувавте или низ нешто сосема друго. За секој премин запишете го дејството на сопственикот, временскиот печат, резултатот од рутата, резултатот од името и резултатот од апликацијата. Потоа проверете го барањето за безбедно затворање во засегнатиот именик-простор, зашто изолацијата не е прекинувач. Именик-просторот држи два тунели одвоени; тој не спречува ниту еден од нив да носи сообраќај кога неговиот профил вели дека сообраќајот мора да запре.

Што може и што не може да тврди овој запис

Успехот ги докажува тие набљудувања за овој распоред, на овој домаќин, во тоа време. Тој не кажува ништо за два клиенти што делат една табела за рутирање на работна површина, ниту за пропусната моќ додека двата тунели носат товар. Тоа се одделни прашања со одделни тестови, и споредбата е добра онолку колку што е добар контекстот прикачен на секој ред.

Чувајте ги неуспесите во записот покрај успесите, означени со тоа кој тунел бил вклучен тогаш. Чиста страница што ја крие состојбата во моментот на мерење е полоша од грда што ја покажува. Записот го прави повторно употреблив контекстот, не резултатот.

Два тунели на една машина можат чесно да се споредат, но само во онолку контексти колку што навистина сте контролирале. Сѐ над тоа е желба со зелена икона до неа.