Du VPN-oj sur unu Linuksa maŝino: testu ĉiun aparte sen miksi rezultojn
Du verdaj ikonoj ne estas komparo. Metu ĉiun tunelon en sian propran nomspacon, skribu la atendojn unue, kaj pruvu la vojon antaŭ ol fidi la rezulton.
Du verdaj konektaj ikonoj aspektas kiel komparo kaj kutime estas hazardo. Se la testa peto povus uzi ajnan el la du tuneloj, la rezulto priskribas plej bone unu el ili kaj plej malbone neniun. Donu al ĉiu observo retan kuntekston, celitan celon kaj atendojn skribitajn antaŭ ol la testo ruliĝas. Sur memadministrata Linuksa maŝino, nomitaj retaj nomspacoj estas la plej malmultekosta maniero aĉeti tiun apartigon.
Du verdaj lumoj ne estas komparo
Nomspaco apartigas enkursigajn tabelojn, interfacojn kaj la staton de la reta stako, do peto komencita en unu ne povas kviete prunti la tunelon de alia. Kion ĝi ne apartigas, estas procesoro, fizika suprenligo aŭ la solvila demono kuranta sur la gastiganto. Ĝuste en tiu lasta breĉo plej multaj el ĉi tiuj testoj malsukcesas sen ke iu rimarkas. Serĉo, kiu forlasas la nomspacon kaj demandas la solvilon de la gastiganto, redonas respondon sen ajna rilato al la testata tunelo.
Ĉi tiu proceduro supozas du jam pretigitajn, aprobitajn testajn nomspacojn kun funkcianta ekstera konekteco kaj subtenataj klientoj. Ĝi kreas nenion, registras nenion kaj anstataŭas neniun agordon. Apartaj virtualaj maŝinoj restas la honesta elekto kiam kliento bezonas plenan labortablajn seancon aŭ rifuzas kuri ekster ĝi.
Fiksu la atendojn antaŭ la unua rulo
Decidu por ĉiu kunteksto kiel aspektas sukceso: la solvilo, la servo-nomo, la atendata adreso kaj la konduto postulata kiam la tunelo falas. Teni tiujn planitajn valorojn en sia propra kolumno, ĉar rikordo, kiu miksas planon kaj observon, estas fikcio kun tempstampo. La kontrol-listo sube estas la formo, kiun la rikordo bezonas, kaj ĉiu vico devas esti plenigebla antaŭ ol la unua konekto.
| 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 |
La dratado de la solvilo bezonas sian propran linion en tiu rikordo, ĉar ĝi estas la kampo plej verŝajne mensoganta. Dosieroj ligitaj al la nomspaco, kiel /etc/netns/vpn-a/resolv.conf aperas sur siaj kutimaj vojoj kiam komando ruliĝas ene de la nomspaco, kiel la iproute2-referenco pri nomspacoj priskribas, sed la agordo de la nomserva ŝaltado kaj ajna loka solvilo, kiun ĝi lanĉas, ankoraŭ povas tiri serĉon reen al la gastiganto.
Unu tunelo samtempe, la alia malkonektita
Konektu A per sia ekzistanta posedanto dum B restas malsupre, poste inspektu politikon, vojojn kaj la elektitan vojon el la administra kunteksto. Tri el la komandoj sube legas staton; nur la lasta kontaktas nomservon, kaj neniu el ili sendas aplikan peton.
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.internalVoja serĉo respondas hipotezan demandon pri celo, do ĝi ne povas montri ke la servo akceptas trafikon. Tenu tiujn du specojn de pruvo en apartaj kolumnoj, ĉar sana vojo apud rifuzita konekto estas reala kaj ofta rezulto. Poste sendu unu senmalican rajtigitan peton per la reala aplikaĵo, lanĉita en la kunteksto de A kiel ĝia normala neprivilegiita uzanto kun sendifekta atestila validigo kaj aplikaĵa aŭtentikigo, kaj registru la rezulton kune kun la fontadreso, kiun la servo observis. Malkonektu A per sia posedanto kaj ripetu la tutan bazlinion por B, notante ajnan agordan ŝanĝon, kiun vi faras, alie la du bazlinioj ĉesas esti kompareblaj.
Ambaŭ supre, poste unu malsupren samtempe
Stabila stato estas la facila parto. Kun ambaŭ tuneloj konektitaj, ripetu la serĉon kaj la aplikaĵan peton de ĉiu kunteksto, poste rompu unu tunelon kaj kontrolu la alian. Rekonektu laŭ la inversa sinsekvo kiam la konekta ordo mem estas la demando.
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.20La kapto solvas disputojn, kiujn aplikaĵa rezulto ne povas: ĝi montras ĉu la peto eliris tra la interfaco, kiun vi atendis, aŭ tra io tute alia. Por ĉiu transiro registru la agon de la posedanto, la tempstampon, la vojrezulton, la nomrezulton kaj la aplikaĵan rezulton. Poste kontrolu la postulon de sekura fermo ene de la tuŝita nomspaco, ĉar izolado ne estas mortigilo. Nomspaco tenas du tunelojn aparte; ĝi ne malhelpas iun el ili porti trafikon kiam ĝia profilo diras, ke trafiko devas halti.
Kion ĉi tiu rikordo povas kaj ne povas aserti
Pasado pruvas tiujn observojn por ĉi tiu aranĝo, sur ĉi tiu gastiganto, en tiu tempo. Ĝi diras nenion pri du klientoj kunhavantaj unu labortablan enkursigan tabelon, kaj nenion pri trairo dum ambaŭ tuneloj portas ŝarĝon. Tiuj estas apartaj demandoj kun apartaj testoj, kaj komparo estas nur tiom bona kiom la kunteksto alkroĉita al ĉiu vico.
Tenu la malsukcesojn en la rikordo apud la sukcesoj, markitaj per tio, kiu tunelo estis supre tiutempe. Pura paĝo, kiu kaŝas la staton ĉe la mezuro, estas pli malbona ol malbela, kiu montras ĝin. Tio, kio igas la rikordon reuzebla poste, estas la kunteksto, ne la poentaro.
Du tuneloj sur unu maŝino povas esti honeste komparitaj, sed nur en tiom da kuntekstoj, kiom vi efektive kontrolis. Io ajn preter tio estas deziro kun verda ikono apud ĝi.