Divi VPN vienā Linux datorā: pārbaudiet katru atsevišķi, nesajaucot rezultātus
Divas zaļas ikonas vēl nav salīdzinājums. Ievietojiet katru tuneli savā nosaukumu telpā, vispirms pierakstiet gaidīto un pierādiet ceļu, pirms uzticaties rezultātam.
Divas zaļas savienojuma ikonas izskatās pēc salīdzinājuma un parasti ir tikai nejaušība. Ja testa pieprasījums varēja izmantot jebkuru no diviem tuneļiem, rezultāts labākajā gadījumā apraksta vienu no tiem, bet sliktākajā — nevienu. Sniedziet katram novērojumam tīkla kontekstu, paredzēto galamērķi un gaidīto, kas pierakstīts pirms testa palaišanas. Pašu pārvaldītā Linux datorā nosauktās tīkla nosaukumu telpas ir lētākais veids, kā nopirkt šo atdalījumu.
Divas zaļas gaismas nav salīdzinājums
Nosaukumu telpa atdala maršrutēšanas tabulas, saskarnes un tīkla steka stāvokli, tāpēc vienā sākts pieprasījums nevar klusi aizņemties otra tuneli. Ko tā neatdala, ir procesors, fiziskā augšupējā saite vai uz resursdatora strādājošais nosaukumu atrisinātāja dēmons. Tieši šajā pēdējā spraudē lielākā daļa šo testu neizdodas bez pazīmēm. Meklējums, kas iziet no nosaukumu telpas un jautā resursdatora atrisinātājam, atgriež atbildi, kurai nav nekāda sakara ar testējamo tuneli.
Šī procedūra pieņem, ka ir divas jau sagatavotas un apstiprinātas testa nosaukumu telpas ar funkcionējošu ārējo savienojumu un atbalstītiem klientiem. Tā neko nerada, neko nereģistrē un neaizstāj nekādu konfigurāciju. Atsevišķas virtuālās mašīnas joprojām ir godīgā izvēle, ja klientam vajag pilnu darbvirsmas sesiju vai tas atsakās darboties ārpus tās.
Nofiksējiet gaidīto pirms pirmās palaišanas
Katram kontekstam izlemiet, kā izskatās panākumi: atrisinātājs, pakalpojuma nosaukums, gaidītā adrese un uzvedība, kas nepieciešama, tunelim nokrītot. Glabājiet šīs plānotās vērtības savā kolonnā, jo ieraksts, kas sajauc plānu un novērojumu, ir izdomājums ar laika zīmogu. Zemāk esošais kontrolsaraksts ir forma, kas ierakstam nepieciešama, un katrai rindai jābūt aizpildāmai pirms pirmā savienojuma.
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
Atrisinātāja vadu savienojums šajā ierakstā pelnījis savu rindu, jo tas ir lauks, kas visticamāk melo. Ar nosaukumu telpu saistītie faili, piemēram, /etc/netns/vpn-a/resolv.conf parādās savos ierastajos ceļos, kad komanda darbojas nosaukumu telpā, kā to apraksta iproute2 nosaukumu telpu uzziņa, taču nosaukumu pakalpojuma pārslēgšanas konfigurācija un jebkurš tās palaists vietējais atrisinātājs joprojām var ievilkt meklējumu atpakaļ uz resursdatoru.
Viens tunelis reizē, otrs atslēgts
Pieslēdziet A caur tā esošo īpašnieku, kamēr B paliek izslēgts, tad no administrēšanas konteksta pārbaudiet politiku, maršrutus un izvēlēto ceļu. Trīs no zemāk esošajām komandām lasa stāvokli; tikai pēdējā sazinās ar nosaukumu pakalpojumu, un neviena no tām nesūta lietotnes pieprasījumu.
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.internalMaršruta meklējums atbild uz hipotētisku jautājumu par galamērķi, tāpēc tas nevar parādīt, ka pakalpojums pieņem datu plūsmu. Glabājiet šos divus pierādījumu veidus atsevišķās kolonnās, jo veselīgs maršruts blakus noraidītam savienojumam ir reāls un bieži sastopams rezultāts. Tad nosūtiet vienu nekaitīgu atļautu pieprasījumu ar īsto lietotni, palaistu A kontekstā kā tās parasto lietotāju bez privilēģijām ar neskartu sertifikātu validāciju un lietotnes autentifikāciju, un pierakstiet rezultātu kopā ar avota adresi, ko pakalpojums redzēja. Atslēdziet A caur tā īpašnieku un atkārtojiet visu bāzes līniju B gadījumā, atzīmējot katru konfigurācijas izmaiņu, ko veicat, citādi abas bāzes līnijas vairs nav salīdzināmas.
Abi ieslēgti, tad pa vienam izslēgti
Stabila stāvoklī ir vieglā daļa. Kad abi tuneļi ir savienoti, atkārtojiet katra konteksta meklējumu un lietotnes pieprasījumu, tad pārtrauciet vienu tuneli un pārbaudiet otru. Pieslēdzieties no jauna apgrieztā secībā, ja pati savienojuma secība ir jautājums.
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.20Uztveršana atrisina strīdus, ko lietotnes rezultāts nevar atrisināt: tā parāda, vai pieprasījums izgāja caur saskarni, kuru gaidījāt, vai caur kaut ko pavisam citu. Katrai pārejai pierakstiet īpašnieka darbību, laika zīmogu, maršruta rezultātu, nosaukuma rezultātu un lietotnes rezultātu. Tad pārbaudiet drošas aizvēršanās prasību skartajā nosaukumu telpā, jo izolācija nav avārijas slēdzis. Nosaukumu telpa tur divus tuneļus atsevišķi; tā neliedz nevienam no tiem pārvadāt datu plūsmu, ja tā profils saka, ka plūsmai jāapstājas.
Ko šis ieraksts var un ko nevar apgalvot
Sekmība pierāda šos novērojumus šai uzbūvei, šajā resursdatorā, tajā laikā. Tā neko nepasaka par diviem klientiem, kas dala vienu darbvirsmas maršrutēšanas tabulu, un neko par caurlaidi, kamēr abi tuneļi nes slodzi. Tie ir atsevišķi jautājumi ar atsevišķiem testiem, un salīdzinājums ir tik labs, cik labs ir konteksts, kas pievienots katrai rindai.
Glabājiet neveiksmes ierakstā līdzās panākumiem, atzīmējot, kurš tunelis tobrīd bija ieslēgts. Tīra lapa, kas slēpj stāvokli mērījuma brīdī, ir sliktāka par neglītu, kas to parāda. Ierakstu vēlāk atkārtoti lietojamu padara konteksts, nevis rezultāts.
Divus tuneļus vienā datorā var godīgi salīdzināt, bet tikai tik kontekstu, cik jūs patiešām kontrolējāt. Viss, kas ir vairāk, ir vēlēšanās ar zaļu ikonu blakus.