Dalawang tanong ang nagpapasya kung karapat-dapat ang isang plano ng address: aling prefix ang pag-aari ng aling site, at paano lumalabas ang sagot mula sa site na iyon. Sagutin ang dalawa nang sabay at mababago ng tagapangasiwa ang isang peer nang hindi kinakausap ang sinuman. Ang lahat ng iba sa dokumento ay para suportahan ang dalawang sagot. Ang hindi sumusuporta sa alinman ay palamuti.

Ano ang dapat sagutin ng mambabasa bago hawakan ang isang peer

Ginagawang maayos ng compression ang mga address, at ang kaayusan ay hindi istruktura. Istruktura ang malaman kung aling saklaw ang itinalaga ng provider, alin ang pinili mo, alin ang pool ng kliyente at alin ang nasa likod ng isang site.

Isulat para sa katrabahong sasali sa susunod na quarter at kailangang magdagdag ng pangalawang site. Walang anuman sa pahina ang magsasabi sa kanya kung saan nanggaling ang isang prefix maliban kung gagawin ito ng entry. Laktawan iyon at ang unang pagbabago ay magiging arkeolohiya.

Ano ang dapat dalhin ng bawat hilera ng plano

Apat na field ang nagpapaging beripikado ang isang entry: haba ng prefix, may-ari, saan pupunta ang trapiko, at aling bahagi ang namamahagi ng halaga. Ihambing ang mga ito sa tumatakbong configuration at ang anumang hindi pagkakasundo ay lumalabas sa sarili nito. Ang susunod na hop na nakaturo sa isang tunnel na inalis noong nakaraang buwan ay agad na mukhang mali sa halip na humalo sa iba.

Panatilihin ang mga tungkulin sa magkahiwalay na hilera kahit na dalawa sa kanila ay nagbabahagi ng isang prefix ngayon. Ang pagsasama ng mga ito ay ginagawang mukhang bagong alokasyon ang susunod na paghahati at hindi pagwawasto.

EntryFields to recordWhy a reviewer needs it
Endpoint addressesPrefix, owning side, session initiatorFirewall rules and peer config both read it
Tunnel interfacesPrefix and length, next hop, interface nameShows the path a packet actually takes
Client allocationsPool range, size, distributing componentShows room left before a redesign
Downstream networksPrefix, site label, return routeExplains a reply that never arrives

Saan naghihiwalay ang kanonikal na teksto at ang sintaks ng configuration

Itinatakda ng RFC 5952 ang isang anyo ng teksto para sa isang address: maliliit na titik, walang nangungunang zero at ang pinakamahabang sunod-sunod na zero na grupo ay siksik nang eksaktong isang beses. Gamitin ito sa mga tala, tiket at talaan ng pagbabago para maihambing ang dalawang dokumento nang walang conversion. Ang mga mambabasang makakita ng dalawang baybay ng isang address ay nagsisimulang maghanap ng pagkakaibang wala. Murang-mura ang pagkakapare-pareho dito at inaalis nito ang isang buong uri ng mga huwad na alarma.

Sumusunod ang mga configuration file sa sarili nilang mga patakaran, at hindi ito ang mga patakaran ng pagbasa. Ang address na ipinares sa isang port ay nangangailangan ng bracket kahit hindi kailangan ng hubad na address, at ang kopya mula sa tala patungo sa configuration file ay nawawala ang pagkakaibang iyon nang walang babala. Pangalanan ang anyong ginagamit ng bawat field, kung hindi ang plano ang magdudulot ng eksaktong error sa pagkopya na dapat nitong pigilan.

Ayos lang ang dalawang notasyon basta may label ang bawat isa. Ang paghahalong walang label ang nag-aanyaya ng mali.

Saan lumilitaw ang magkakapatong na saklaw at nawawalang ruta ng pagbalik

Mas matagal mabuhay ang overlap kaysa sa ibang mali dahil walang mukhang mali hanggang sa dalawang site ang sumagot sa parehong saklaw. Lagyan ng label ang site at gumawa ng mga lokal na natatanging prefix gamit ang dokumentadong pamamaraan sa halip na kopyahin ang isang halimbawa.

Hindi kailanman ipinapaliwanag ng listahan ng kliyente kung aling direksyon naglalakbay ang sagot. Itala ang ruta ng pagbalik ng LAN gateway sa tabi ng saklaw ng peer na dinadala ng tunnel, at ipapaliwanag ng rekord ang isang malayong subnet na tumatanggap ng mga kahilingan at nananatiling tahimik. Patakbuhin ang mga pagsusuri sa ibaba sa makina at ihambing sa entry. Ang planong sumasalungat sa ip -6 route ay planong tinatanggap ng mga tao na hindi basahin.

ip -6 route show default
ip -6 route get 2001:db8:2::10
ip -6 addr show dev wg0

Ang maabot ay hindi pahintulot, at ang prefix ay hindi kailanman nangangahulugan ng patakaran. Isulat ang inilaan na pag-access sa tabi ng rutang pinaglalapatan nito. Kung hindi, ituturing ng susunod na mambabasa ang isang address sa plano bilang pahintulot na maabot ang bawat serbisyo sa likod nito.

Paano nalalampasan ng plano ang ikatlong site

Markahan ang bawat prefix bilang itinalaga, inilaan nang lokal o niruruta sa ibang paraan. Para sa lahat ng maaaring gumalaw, pangalanan ang prosesong gumagalaw dito. Pagkatapos ay ilista ang mga talaang DNS at mga tuntunin ng firewall na dapat magbago sa parehong yugto, dahil ang pag-update ng prefix na humihinto sa router ay kalahati lamang.

Pagkatapos ng pagbabago, maabot ang isang resource sa likod ng bawat hangganang tinamaan ng pagbabago bago i-edit ang dokumento. Ang planong naglalarawan ng network noong nakaraang buwan ay mas masahol pa sa wala, dahil pinagkakatiwalaan ito ng mga tao. Panatilihin ang mga binawing alokasyon sa listahan kasama ang petsa nang mawala ang mga ito para walang makapaglabas muli nang aksidente. Nananatili sa labas ng file ang mga sikreto; ipinapaliwanag ng plano ang network, hindi ito binubuksan.

Itabi ang plano kung saan sinusuri ang mga pagbabago, sa tabi ng configuration na inilalarawan nito. Ang dokumentong walang muling nagbabasa ay nabubulok nang mas mabilis kaysa sa network na ginagawan nito ng mapa.

Kaugnay na mga artikulo