Twa VPN's op ien Linux-masine: test elk apart sûnder resultaten te mingen
Twa griene byldkaikes binne gjin ferliking. Set elk tunnel yn syn eigen nammromte, skriuw earst de ferwachting op en bewys it paad foardat jo it resultaat fertrouwe.
Twa griene ferbyningsbyldkaikes lykje in ferliking en binne meastentiids tafal. As de testopdracht ien fan beide tunnels brûke koe, beskriuwt it resultaat yn it bêste gefal ien fan harren en yn it slimste gefal gjinien. Jou elke waarnimming in netwurkferbân, in bedoeld bestimming en in ferwachting dy't skreaun is foardat de test rint. Op in sels beheard Linux-masine binne neamde netwurknammromten de goedkeapste manier om dy skieding te keapjen.
Twa griene lampen binne gjin ferliking
In nammromte skiedt rûtelearstabellen, ynterfaces en de steat fan 'e netwurkstapel, sadat in opdracht dy't yn ien begûn is net stilwei de tunnel fan in oar liene kin. Wat it net skiedt, is in prosessor, in fysike opgeande ferbining of de oplosser-daemon dy't op 'e host rint. Krekt yn dat lêste gat mislearje de measte fan dizze tests sûnder dat immen it merkt. In syktocht dy't de nammromte ferlit en de oplosser fan 'e host freget, jout in antwurd werom dat neat mei de testten tunnel te krijen hat.
Dizze proseduere giet derfan út dat der al twa taret en goedkarde testnammromten binne, mei wurkjende bûtenferbining en stipe kliïnten. It makket neat, registrearret neat en ferfangt gjin konfiguraasje. Aparte firtuele masines bliuwe de earlike kar as in kliïnt in folsleine buroblêdsesje nedich hat of wegere om bûten ien te rinnen.
Fêstigje de ferwachting foar de earste run
Bepaal per kontekst hoe't sukses derút sjocht: de oplosser, de tsjinstnamme, it ferwachte adres en it gedrach dat frege wurdt as de tunnel falt. Hâld dy plande wearden yn har eigen kolom, want in ferslach dat plan en waarnimming mingt is fiksje mei in tiidstimpel. De checklist hjirûnder is de foarm dy't it ferslach nedich hat, en elke rige moat ynfolber wêze foar de earste ferbining.
| 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 |
De bekabeling fan 'e oplosser fertsjinnet syn eigen rigel yn dat ferslach, want it is it fjild dat it meast wierskynlik liicht. Bestannen dy't oan 'e nammromte bûn binne, lykas /etc/netns/vpn-a/resolv.conf ferskine op har gewoane paden as in opdracht binnen de nammromte rint, sa't de iproute2-referinsje oer nammromten it beskriuwt, mar de konfiguraasje fan 'e nametsjinstwiksel en elke lokale oplosser dy't dy start, kinne in syktocht noch altyd weromlûke nei de host.
Ien tunnel tagelyk, de oare ôfskeakele
Ferbyn A fia syn besteande eigner wylst B del bliuwt, en besjoch dan belied, rûtes en it keazen paad út 'e administraasjekontekst. Trije fan 'e opdrachten hjirûnder lêze steat; allinne de lêste nimt kontakt op mei in nametsjinst, en gjinien fan harren stjoert in applikaasje-opdracht.
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.internalIn rûtesyktocht beantwurdet in hypotetyske fraach oer in bestimming, dus it kin net sjen litte dat de tsjinst ferkear akseptearret. Hâld dy twa soarten bewiis yn aparte kolommen, want in sûne rûte njonken in wegere ferbining is in echt en gewoan resultaat. Stjoer dan ien ûnskeadlike autorisearre opdracht mei de echte applikaasje, start yn 'e kontekst fan A as syn gewoane brûker sûnder foech, mei sertifikaatferifikaasje en applikaasje-autentikaasje yntakt, en registrearje it resultaat tegearre mei it boarneadres dat de tsjinst seach. Skeakel A ôf fia syn eigner en werhelje de hiele basisline foar B, en notearje elke konfiguraasjeferoaring dy't jo meitsje, oars bliuwe de twa basislinen net ferlykber.
Beide omheech, dan ien tagelyk del
Stabylste steat is it maklike part. Mei beide tunnels ferbûn, werhelje de syktocht en applikaasje-opdracht fan elke kontekst, ferbrek dan ien tunnel en kontrolearje de oare. Ferbyn wer yn 'e omkearde folchoarder as de ferbiningsfolchoarder sels de fraach 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.20De opname beslist diskusjes dy't in applikaasjeresultaat net besliste kin: it lit sjen oft de opdracht fia it ynterface gie dat jo ferwachten, of fia hiel wat oars. Registrearje foar elke oergong de aksje fan 'e eigner, de tiidstimpel, it rûteresultaat, it nameresultaat en it applikaasjeresultaat. Kontrolearje dan de eask fan feilich sluten binnen de troffen nammromte, want isolaasje is gjin needstop. In nammromte hâldt twa tunnels apart; it ferhindert gjinien fan beiden om ferkear te dragen as syn profyl seit dat it ferkear stopje moat.
Wat dit ferslach wol en net bewearje kin
In slagge bewyst dy waarnimmingen foar dizze opstelling, op dizze host, op dat stuit. It seit neat oer twa kliïnten dy't ien buroblêd-rûtelearstabel diele, en neat oer trochfoersnelheid wylst beide tunnels lading drage. Dat binne aparte fragen mei aparte tests, en in ferliking is mar sa goed as de kontekst dy't oan elke rige ferbûn is.
Hâld de mislearringen yn it ferslach njonken de suksessen, markearre mei hokker tunnel doe omheech wie. In skjinne side dy't de steat by de mjitting ferberget is slimmer as in ûnsjogge ien dy't it sjen lit. Wat it ferslach letter werbrûkber makket is de kontekst, net de skoare.
Twa tunnels op ien masine kinne earlik ferlike wurde, mar allinne binnen safolle konteksten as jo echt behearske hawwe. Alles dêrbûten is in winsk mei in grien byldkaike derneist.