Dy VPN në një makinë Linux: testo secilin veçmas pa përzier rezultatet

Dy ikona jeshile lidhjeje duken si krahasim dhe zakonisht janë rastësi. Nëse kërkesa e testit mund të kishte përdorur një nga dy tunelet, rezultati në rastin më të mirë përshkruan njërin prej tyre dhe në rastin më të keq asnjërin. Jepi çdo vëzhgimi një kontekst rrjeti, një destinacion të synuar dhe një pritshmëri të shkruar përpara se të ekzekutohet testi. Në një makinë Linux që e administron vetë, hapësirat e emrave të rrjetit me emër janë mënyra më e lirë për të blerë atë ndarje.

Dy drita jeshile nuk janë krahasim

Një hapësirë emrash ndan tabelat e rrugëzimit, ndërfaqet dhe gjendjen e stivës së rrjetit, kështu që një kërkesë e nisur brenda njërës nuk mund të huazojë në heshtje tunelin e tjetrës. Ajo që nuk ndan është një procesor, një lidhje fizike lart ose daemoni i zgjidhjes së emrave që punon në host. Pikërisht në këtë boshllëk të fundit dështojnë shumica e këtyre testeve pa e vënë re askush. Një kërkim që del nga hapësira e emrave dhe pyet zgjidhësin e hostit kthen një përgjigje pa asnjë lidhje me tunelin në provë.

Kjo procedurë supozon dy hapësira emrash testimi të përgatitura dhe të miratuara më parë, me lidhje të jashtme funksionale dhe klientë të mbështetur. Ajo nuk krijon asgjë, nuk regjistron asgjë dhe nuk zëvendëson asnjë konfigurim. Makinat virtuale të veçanta mbeten zgjedhja e ndershme kur një klient ka nevojë për një sesion të plotë desktopi ose refuzon të punojë jashtë tij.

Fikso pritshmërinë përpara ekzekutimit të parë

Vendos për çdo kontekst si duket suksesi: zgjidhësi, emri i shërbimit, adresa e pritur dhe sjellja e kërkuar kur tuneli bie. Mbaji ato vlera të planifikuara në kolonën e tyre, sepse një regjistër që përzien planin dhe vëzhgimin është trillim me vulë kohe. Lista e kontrollit më poshtë është forma që i duhet regjistrit, dhe çdo rresht duhet të plotësohet përpara lidhjes së parë.

Lidhja e zgjidhësit meriton rreshtin e vet në atë regjistër, sepse është fusha që ka më shumë gjasa të gënjejë. Skedarët e lidhur me hapësirën e emrave, si /etc/netns/vpn-a/resolv.conf shfaqen në shtigjet e tyre të zakonshme kur një komandë ekzekutohet brenda hapësirës së emrave, siç përshkruan referenca e iproute2 për hapësirat e emrave, por konfigurimi i ndërrimit të shërbimit të emrave dhe çdo zgjidhës lokal që ai nis mund të tërheqin ende një kërkim përsëri te hosti.

Një tunel në një herë, tjetri i shkëputur

Lidh A përmes pronarit të tij ekzistues ndërsa B mbetet poshtë, pastaj inspekto politikën, rrugët dhe rrugën e zgjedhur nga konteksti i administrimit. Tre nga komandat më poshtë lexojnë gjendjen; vetëm e fundit kontakton një shërbim emrash, dhe asnjëra prej tyre nuk dërgon një kërkesë aplikacioni.

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

Një kërkim rruge i përgjigjet një pyetjeje hipotetike për një destinacion, prandaj nuk mund të tregojë se shërbimi pranon trafik. Mbaji këto dy lloje provash në kolona të veçanta, sepse një rrugë e shëndoshë pranë një lidhjeje të refuzuar është rezultat i vërtetë dhe i zakonshëm. Pastaj dërgo një kërkesë të padëmshme të autorizuar me aplikacionin e vërtetë, e nisur në kontekstin e A si përdoruesi i saj normal pa privilegje me vërtetimin e certifikatës dhe vërtetimin e aplikacionit të paprekur, dhe regjistro rezultatin së bashku me adresën e burimit që vëzhgoi shërbimi. Shkëput A përmes pronarit të tij dhe përsërit të gjithë vijën bazë për B, duke shënuar çdo ndryshim konfigurimi që bën, përndryshe dy vijat bazë nuk mbeten më të krahasueshme.

Të dyja lart, pastaj një poshtë në një herë

Gjendja e qëndrueshme është pjesa e lehtë. Me të dy tunelet të lidhur, përsërit kërkimin dhe kërkesën e aplikacionit të çdo konteksti, pastaj prish një tunel dhe kontrollo tjetrin. Rilidhu në sekuencë të kundërt kur vetë rendi i lidhjes është pyetja.

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

Kapja zgjidh mosmarrëveshje që një rezultat aplikacioni nuk mund t'i zgjidhë: tregon nëse kërkesa doli përmes ndërfaqes që prisje apo përmes diçkaje krejt tjetër. Për çdo kalim regjistro veprimin e pronarit, vulën e kohës, rezultatin e rrugës, rezultatin e emrit dhe rezultatin e aplikacionit. Pastaj kontrollo kërkesën e mbylljes së sigurt brenda hapësirës së emrave të prekur, sepse izolimi nuk është çelës ndalimi. Një hapësirë emrash mban dy tunele të ndarë; nuk e pengon asnjërin prej tyre të mbajë trafik kur profili i tij thotë se trafiku duhet të ndalet.

Çfarë mund dhe çfarë nuk mund të pohojë ky regjistër

Një kalim i suksesshëm provon ato vëzhgime për këtë rregullim, në këtë host, në atë kohë. Nuk thotë asgjë për dy klientë që ndajnë një tabelë rrugëzimi desktopi, dhe asgjë për xhiron ndërsa të dy tunelet mbajnë ngarkesë. Këto janë pyetje të veçanta me teste të veçanta, dhe një krahasim është vetëm aq i mirë sa konteksti i bashkangjitur çdo rreshti.

Mbaji dështimet në regjistër pranë sukseseve, të etiketuara me cilin tunel ishte lart në atë kohë. Një faqe e pastër që fsheh gjendjen në momentin e matjes është më e keqe se një e shëmtuar që e tregon. Ajo që e bën regjistrin të ripërdorshëm më vonë është konteksti, jo rezultati.

Dy tunele në një makinë mund të krahasohen me ndershmëri, por vetëm brenda aq konteksteve sa ke kontrolluar vërtet. Çdo gjë përtej kësaj është një dëshirë me një ikonë jeshile pranë.