Subukan ang VPN routing sa mga namespace nang hindi hinahawakan ang mga ruta ng host
Tatlong simulate na papel, tatlong hiwalay na konteksto at isang veth bawat link. Ihambing ang namespace lab sa host-route lab bago hawakan ang host.
Dalawang lab ang maaaring magmodelo ng parehong VPN topology at mabigo sa ganap na magkaibang paraan: ang isa ay naninirahan sa mga namespace ng network, ang isa sa sariling mga ruta ng host. Ang bersyon ng namespace ay nag-iingat ng bawat interface, ruta at socket sa isang konteksto na maaari mong burahin, habang ang bersyon ng host ay mas mabilis magsimula at nag-iiwan ng estado. Ang natirang estado na iyon ang dahilan kung bakit mahirap ulitin ang pangalawang lab makalipas ang isang buwan. Ihambing muna ang paglilinis, dahil ito ang nagpapasya kung maaari mong isagawa ang eksperimento nang dalawang beses.
Dalawang paraan upang buuin ang parehong lab, at kung kailan nananalo ang bawat isa
Sa isang host-route lab, nagdaragdag ka ng tunnel interface at mga ruta sa makina kung saan ka nagtatrabaho, kaya ang eksperimento ay nakikibahagi ng kapalaran sa iyong shell, sa iyong package manager at sa bawat iba pang koneksyon. Sa isang namespace lab, bawat papel ay nakakakuha ng sarili nitong stack ng mga interface, address, ruta at socket, at ang pagbura ng namespace ay nag-aalis ng lahat ng iyon. Wala sa dalawang modelo ang mas tama, dahil sumasagot sila sa magkaibang tanong. Piliin ang mga namespace kapag ang paksa ay routing at pagpapasa, at isang host lab kapag ang paksa ay kung paano nagsasama ang isang desktop client.
| Aspect | Namespace lab | Host-route lab |
|---|---|---|
| Isolation | Full stack per role | Shares the host stack |
| Cleanup | Delete named namespaces | Manual route and rule removal |
| Realism | Strong for routing | Needed for GUI clients |
Ang paghahalo ng dalawa ang karaniwang pagkakamali: isang namespace lab na sinubukan laban sa isang client sa host lamang ay walang pinapatunayan tungkol sa alinman sa dalawang kaayusan. Magpasya kung anong tanong ang itinatanong mo bago ka gumawa ng unang link.
Isang konteksto bawat papel, konektado nang sadya
Gumawa ng isang namespace bawat papel at ilipat ang bawat dulo ng bawat pares ng veth sa kontekstong nagmamay-ari nito. Sapat na ang unang apat na utos upang makita ang hugis:
ip netns add client
ip netns add gateway
ip link add veth-c type veth peer name veth-g
ip link set veth-c netns clientBigyan ang lab ng mga saklaw na hindi nagsasapawan ng anuman sa host, at isulat bago magsimula kung aling namespace ang nagmamay-ari ng aling address. Ang gumaganang lab ay nangangailangan ng dalawang hiwalay na landas: isang panlabas upang maabot ng VPN endpoint ang kapareha nito, at isang pabalik na landas para sa resource na pinoprotektahan. I-modelo ang mga ito bilang dalawang desisyon, dahil ang lab na gumagawa lamang ng palabas na kalahati ay pumapasa sa isang pagsubok ng pakikipagkamay at bumagsak sa isang pagsubok ng aplikasyon.
Ang papel ng pagpapasa ang lugar kung saan nagiging kawili-wili ang mga lab
Kailangang magpasa ng isang papel, na nangangahulugang paganahin ang pagpapasa sa loob ng namespace na iyon at idagdag ang tuntunin na kailangan ng disenyo. Ang estado ng pagpapasa ay bawat namespace, kaya ang setting ng host ay walang kaugnayan sa lab at ang setting ng lab ay hindi tumutulo palabas, tulad ng inilalarawan ng dokumentasyon tungkol sa mga namespace ng network. Itinatala ng WireGuard na ang isang interface at ang panlabas na socket nito ay maaaring manirahan sa magkaibang namespace, na isang kapaki-pakinabang na trick at isang mahusay na paraan upang lituhin ang iyong sarili. Huwag ipagpalagay na ang paglipat ng isang interface ay naglilipat ng bawat bahagi ng koneksyon sa parehong paraan.
Suriin ang counter ng pagpapasa pagkatapos ng isang test packet, dahil ang isang tuntuning hindi kailanman tumugma at isang tuntuning nagtapon ay magkamukha sa talahanayan ng ruta. Ang mga counter lamang ang naghihiwalay sa kanila.
Itala ang baseline, pagkatapos ay sirain ang isang ruta
Magsimula sa pagtatala kung ano ang umiiral, na nakasulat ang konteksto sa tabi ng bawat linya. Basahin ang mga namespace, pagkatapos ang rutang tatahakin ng isang test destination sa loob ng isa sa kanila, pagkatapos ang mga counter sa link na nagdadala nito:
ip netns list
ip -n client route get 10.0.0.5
ip -n gateway -s link show veth-gAng ikatlong utos ang nilalaktawan ng mga tao, at doon naninirahan ang ebidensya: ang mga counter ng itinapon at mga error ay nagsasabi kung ang isang packet ay umabot man sa papel ng pagpapasa. Itala ang parehong tatlong tanawin pagkatapos ng pagbabago, at hayaang ang diff ang maging ebidensya sa halip na ang iyong memorya. Pagkatapos ay sirain ang eksaktong isang bagay, alinman sa pamamagitan ng pagbura ng ruta o pagdaragdag ng tuntunin ng pagtanggi sa landas ng pagpapasa, at kumpirmahin ang sintomas na hinulaan mo: isang kumpletong pakikipagkamay na walang sagot, o isang kabiguan sa paglutas sa halip na isang timeout. Ang lab na nagpapakita lamang ng tagumpay ay nagtuturo ng napakakaunti.
Ang paglilinis ang nagpapataas ng susunod na pagtakbo upang maulit
Panatilihin ang paglilinis sa loob ng mga resource na pinangalanan mo, dahil ang pangkalahatang pag-reset ng firewall o pag-alis ng ruta ng host ay hindi pagiging maulit, ito ay pangalawang insidente. I-save ang topology, ang eksaktong mga utos at ang mga obserbasyong inaasahan mo, upang ang susunod na pagtakbo ay muling gawin ang parehong kabiguan sa halip na hulaan kung aling konteksto ang may dating estado. Kung walang rekord na iyon, ang lab ay isang kuwento at hindi isang pamamaraan.
Gumamit ng mga kredensyal na nabuo nang lokal para sa lab, at ilayo ang mga production account sa mga ibinahaging halimbawa. Pagkatapos ay burahin ang bawat namespace at kumpirmahin na ang tanawin ng host ay hindi nagbago, na siyang buong dahilan upang piliin ang modelong ito. Ang lab na hindi mo malinis na maalis ay isang pagbabago sa host na may karagdagang mga hakbang.