Ang default na VPN sa table 200 ay nagtatago ng iyong rutang LAN

Apat na pagsusuri ang naghihiwalay ng sira sa table ng patakaran mula sa sira sa routing: aling tuntunin ang tumugma, aling table ang pinangalanan ng tuntuning iyon, ano ang nilalaman ng table na iyon, at aling ruta sa loob nito ang nanalo. Hindi na kinokonsulta ang pangunahing table kapag may naunang table na nagbigay ng ruta, kaya ang entry na LAN na nakikita doon ay maaaring walang kaugnayan sa packet na sinusubukan mo. Gawin ang mga pagsusuri nang sunud-sunod, at ang nawawalang ruta ay lalabas sa ikatlong hakbang at hindi sa ikaapat.

Ang pagtutugma ng pinakamahabang prefix ay nangyayari sa loob ng isang table; hindi nito inihahambing ang mga ruta ng lahat ng table bilang isang listahan.

Nagtatapos ang paghahanap sa unang table na sumasagot

Kumuha ng patakaran kung saan ang trapiko mula sa isang subnet ay unang tumitingin sa table 200, ang table 200 ay may default na ruta sa tunnel, at ang pangunahing table ay may prefix na LAN. Ang packet para sa isang address na LAN ay maaaring tumugma sa default na iyon sa table 200 at huminto doon. Dahil nagbigay ng ruta ang paghahanap, hindi na nakakakuha ng pagkakataon ang huling tuntunin ng pangunahing table na ialok ang mas tiyak na entry nito. Ang resulta ay packet na pumapasok sa tunnel habang ang isang ganap na maayos na rutang LAN ay nananatiling hindi ginagamit.

Naaangkop pa rin ang mga naunang tuntunin at ang sariling paghahanap ng makina sa mga lokal na address, kaya dapat gamitin ng pagsubok ang source, mark at interface na dala ng tunay na daloy. Magtanong gamit ang iba pa at baka maayos na mapili ang LAN, na siyang nagtatago sa mismong sirang hinahanap mo.

Ilagay ang eksepsiyon sa LAN kung saan ito nararapat

Maaaring dalhin ng napiling table ang mga rutang LAN, konektado at patungo sa endpoint na kailangan nito, na nagpapanatiling makasarili ang patakaran. Gumagamit ang ibang disenyo ng tahasang naunang tuntunin para sa prefix na LAN, o sinadyang throw route na nagbibigay ng prefix sa susunod na paghahanap. Bawat isa ay lehitimong pattern na may ibang may-ari. Pumili batay sa nilalayong patakaran at sa kung sino ang nagpapanatili ng mga ruta, hindi sa kung alin ang mas maikli i-type.

Anuman ang pattern, kailangang makita ang eksepsiyon kung saan tinukoy ang patakaran. Ang rutang idinagdag nang manu-mano at hindi naitala ay mawawala sa susunod na reboot at dadalhin ang diagnosis.

Huwag kopyahin ang pangunahing table nang buo

Ang pagkopya ng bawat ruta mula sa pangunahing table papunta sa table ng patakaran ay mukhang pag-aayos ngunit lumilikha ng snapshot. Maaaring magdagdag o mag-alis ang tagapangasiwa ng mga address at interface nang dynamic, at ang kopya ay naluluma nang walang nakakapansin. Panatilihin ang lifecycle ng mga ruta sa may-ari ng configuration nito, at muling likhain ang table mula sa configuration at hindi mula sa isang sandali sa oras.

Bigo rin sa layunin ang kopyadong table, dahil muling ginagawa nito ang fallback na pag-uugali na dapat sana ay nilimitahan ng patakaran.

Suriin ang mga sagot nang hiwalay sa mga ruta

Kapag napili na ng paghahanap ang nilalayong landas, maaari pa ring mabigo ang mga sagot dahil sa mga dahilan na walang kaugnayan sa table. Maaaring mailapat ang pagsasalin sa maling interface, maaaring tanggihan ng pagpapatunay ng reverse path ang packet na dumating sa hindi inaasahang landas, o maaaring hindi sumagot ang endpoint. Magkaibang sira ang mga ito na may magkaibang ebidensiya, at wala sa mga ito ang naaayos sa pamamagitan ng pag-edit ng mga entry sa ruta.

I-save ang paghahanap para sa eksaktong daloy na iyon sa magkabilang panig ng pagbabago, upang manatiling nakikita ang pagwawasto. Ang pagpapatay ng mga pagsusuri ng reverse path sa buong mundo o pag-flush ng mga tuntunin ay walang naibibigay na nawawalang ruta at nagpapahina sa mga kontrol na walang kaugnayan.

Itala ang tuntunin, ang table, ang nanalong ruta at ang landas ng sagot. Ang talaang iyon ang naghihiwalay ng pagkakamali sa patakaran mula sa sirang serbisyo.