Twee VPN's op een Linux-rekenaar: toets elkeen sonder om resultate te vermeng
Twee groen ikone is nie 'n vergelyking nie. Plaas elke tonnel in 'n naamruimte, skryf die verwagting eers neer en bewys die pad voordat jy die uitslag vertrou.
Twee groen verbindingsikone lyk soos 'n vergelyking en is gewoonlik 'n toevalligheid. As die toetsversoek enige van die twee tonnels kon gebruik het, beskryf die uitslag op sy beste een van hulle en op sy slegste nie een nie. Gee elke waarneming 'n netwerkverband, 'n beoogde bestemming en 'n verwagting wat geskryf is voordat die toets begin. Op 'n selfbestuurde Linux-rekenaar is benoemde netwerknaamruimtes die goedkoopste manier om daardie skeiding te koop.
Twee groen ligte is nie 'n vergelyking nie
'n Naamruimte skei roeteringstabelle, netwerkkoppelvlakke en die toestand van die netwerkstapel, sodat 'n versoek wat in een begin het nie stilweg 'n ander se tonnel kan leen nie. Wat dit nie skei nie, is 'n verwerker, 'n fisiese opstroomlyn of die resolver-daemon wat op die gasheer loop. Dit is juis by daardie laaste leemte waar die meeste van hierdie toetse misluk sonder dat iemand dit agterkom. 'n Opsoeking wat die naamruimte verlaat en die gasheer se resolver vra, lewer 'n antwoord wat niks met die tonnel onder toets te doen het nie.
Hierdie prosedure veronderstel twee reeds ingerigte, goedgekeurde toetsnaamruimtes met werkende buitenste verbinding en ondersteunde kliënte. Dit skep niks, skryf niks in en vervang geen konfigurasie nie. Aparte virtuele masjiene bly die eerlike keuse wanneer 'n kliënt 'n volledige lessenaarsessie nodig het of weier om daarbuite te loop.
Bepaal die verwagting voor die eerste lopie
Bepaal per konteks hoe sukses lyk: die resolver, die diensnaam, die verwagte adres en die gedrag wat vereis word wanneer die tonnel val. Hou daardie beplande waardes in hul eie kolom, want 'n rekord wat plan en waarneming vermeng, is fiksie met 'n tydstempel. Die kontrolelys hieronder is die vorm wat die rekord nodig het, en elke ry moet ingevul kan word voordat die eerste verbinding gemaak word.
| 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 |
Die bedrading van die resolver verdien sy eie reël in daardie rekord, want dit is die veld wat die meeste geneig is om te lieg. Lêers wat aan die naamruimte gebind is, soos /etc/netns/vpn-a/resolv.conf verskyn op hul gewone paaie wanneer 'n opdrag binne die naamruimte loop, soos die iproute2-verwysing vir naamruimtes beskryf, maar die naambediening-skakelkonfigurasie en enige plaaslike resolver wat dit begin, kan 'n opsoeking steeds na die gasheer terugtrek.
Een tonnel op 'n slag, die ander ontkoppel
Verbind A deur sy bestaande eienaar terwyl B af bly, en ondersoek dan beleid, roetes en die gekose pad vanuit die administrasiekonteks. Drie van die opdragte hieronder lees toestand; net die laaste een kontak 'n naambediening, en nie een van hulle stuur 'n toepassingsversoek nie.
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'n Roete-opsoeking beantwoord 'n hipotetiese vraag oor 'n bestemming, so dit kan nie wys dat die diens verkeer aanvaar nie. Hou daardie twee soorte bewyse in aparte kolomme, want 'n gesonde roete langs 'n geweierde verbinding is 'n werklike en algemene uitslag. Stuur dan een skadelose gemagtigde versoek met die werklike toepassing, in A se konteks begin as sy normale onbevoorregte gebruiker met sertifikaatvalidering en toepassingsverifikasie ongeskonde, en teken die uitslag saam met die bronadres wat die diens gesien het op. Ontkoppel A deur sy eienaar en herhaal die hele basislyn vir B, en let op enige konfigurasieverandering wat jy maak, anders bly die twee basislyne nie vergelykbaar nie.
Beide op, dan een op 'n slag af
Bestendige toestand is die maklike deel. Met beide tonnels verbind, herhaal elke konteks se opsoeking en toepassingsversoek, breek dan een tonnel en kyk na die ander. Herverbind in die omgekeerde volgorde wanneer die verbindingsorde self die vraag is.
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.20Die opname beslis argumente wat 'n toepassingsuitslag nie kan beslis nie: dit wys of die versoek deur die koppelvlak vertrek het wat jy verwag het, of deur iets heeltemal anders. Teken vir elke oorgang die eienaar se aksie, die tydstempel, die roete-uitslag, die naamuitslag en die toepassingsuitkoms op. Kontroleer dan die vereiste van veilig-faal binne die betrokke naamruimte, want isolasie is nie 'n doodskakelaar nie. 'n Naamruimte hou twee tonnels apart; dit keer nie een van hulle om verkeer te dra wanneer sy profiel sê verkeer moet stop nie.
Wat hierdie rekord wel en nie kan beweer nie
'n Slaag bewys daardie waarnemings vir hierdie reëling, op hierdie gasheer, op daardie tydstip. Dit sê niks oor twee kliënte wat een lessenaar se roetertabel deel nie, en niks oor deurset terwyl beide tonnels las dra nie. Dit is aparte vrae met aparte toetse, en 'n vergelyking is net so goed soos die konteks wat aan elke ry geheg is.
Hou die mislukkings in die rekord langs die suksesse, gemerk met watter tonnel op daardie oomblik op was. 'n Skoon bladsy wat die toestand by die meting wegsteek, is slegter as 'n lelike een wat dit wys. Wat die rekord later herbruikbaar maak, is die konteks, nie die punt nie.
Twee tonnels op een rekenaar kan eerlik vergelyk word, maar net binne soveel kontekste as wat jy werklik beheer het. Enigiets verder is 'n wens met 'n groen ikoon langs hom.