Ruta tinanggihan dahil sa mga host bit? Hanapin ang nilalayong prefix
Ang tinanggihang linya ng ruta ay kadalasang dahil sa mga host bit, hindi problema sa pagpapasa. Tukuyin ang prefix na nilayon mo sa halip na palawakin ang mask hanggang tanggapin.
Bumabalik na tinanggihan ang iyong linya ng ruta, at ang payong makikita mo ay nagsasabing buksan ang IP forwarding. Ang dalawang bagay na ito ay nasa magkaibang yugto ng problema. Ang forwarding ang nagpapasya kung ang isang host ay makakagalaw ng mga packet sa pagitan ng mga interface; wala itong opinyon kung ang destination na tinipa mo ay isang wastong network. Ayusin muna ang prefix, dahil hindi maililigtas ng forwarding ang address at mask na hindi nagtutugma.
Ano ba talaga ang reklamo ng parser
Ang destination na nakasulat bilang address plus mask ay dapat maglarawan ng network, at ang network ay nagsisimula sa mga host bit na zero. Kapag ang address na ibinigay mo ay may halaga pa sa host na bahagi, ang pares ay panloob na hindi tugma: mukhang maayos ang 172.20.130.0 dahil nagtatapos ito sa zero, ngunit ang zero sa ikaapat na octet ay hindi lamang ang mahalaga. Ang ikatlong octet ang may dalang ligaw na bits dito.
Iba't ibang paraan ang paghawak ng mga tool sa hindi pagkakatugmang iyon. Tinatanggihan ng mahigpit na parser ang linya at pinangalanan ang host bits. Binabalot ng maluwag na parser ang address sa mask at naglalagay ng bagay na hindi mo hiniling, na mas masama, dahil ang configuration ay nagruruta na ng saklaw na hindi mo kailanman nilayon. Ang ipaddress module ng Python ay direktang nagpapakita ng pagpipilian: ang mahigpit na network parsing ay naglalabas ng error, at ang strict=False ay nagbabalot ng host bits. Maaaring mahigpit, maluwag, o hindi pare-pareho sa pagitan ng mga bersyon ang client mo, kaya basahin ang mensahe sa halip na magtiwala sa ugali.
Gawin ang halimbawa sa kamay
Kumuha ng tunnel na kailangang maabot ang 172.20.130.0 gamit ang /20 na mask. Ang /20 ay nanghihiram ng apat na bit mula sa ikatlong octet, kaya ang octet na iyon ay binibilang lamang sa mga hakbang na 16: 0, 16, 32 at pasulong hanggang 240. Ang halagang 130 ay nahuhulog sa pagitan ng 128 at 143, na nangangahulugang ang nakapaligid na network ay nagsisimula sa 172.20.128.0, hindi sa 172.20.130.0 na may naka-zero na huling octet.
Kapag isinulat, ang block ay mula 172.20.128.0 hanggang 172.20.143.255 at may 4,096 na address. Ang pagbibigay ng parehong mga halaga sa hindi mahigpit na parser ay nagpapakita ng pagpapalit na gagawin nito sa ngalan mo:
$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096Magpasya kung aling destination ang tunay mong nilayon
Ang tinanggihang linya ay kadalasang nagtatago ng isa sa tatlong layunin, at ikaw lamang ang makakapili. Kung kailangan ng tunnel ang buong block, isulat ang 172.20.128.0/20, ang kanonikal na network address. Kung ang tunnel ay nangangailangan lamang ng 130 segment, mali ang mask at ang 172.20.130.0/24 ang tapat na anyo. Kung isang makina lamang ang target, ang IPv4 host route ay /32 at walang mask arithmetic na kasama.
Ang bawat isa ay nagpapahintulot ng ibang dami ng trapiko, at iyon ang tunay na dahilan upang hindi palawakin ang mask hanggang tumigil ang reklamo. Ang /16 ay tumatanggap ng linya halos kahit saan at nagpapadala ng trapiko sa mga destination na hindi mo kailanman nilayong iruta sa tunnel. Isulat ang pinakamakitid na prefix na tumutugma sa layunin, pagkatapos ay kumpirmahin ito laban sa susunod na hop na inaasahan mo, hindi laban sa katahimikan ng parser.
Bakit hindi kailanman naging solusyon ang forwarding
Ang tinanggihang ruta ay hindi kailanman umaabot sa landas ng forwarding, kaya hindi mababago ng paglipat ng net.ipv4.ip_forward ang resulta. Mahalaga ang setting na iyon mamaya, kapag kailangang ipasa ng host ang mga packet sa pagitan ng mga interface, at ang pagbukas nito bago maging tama ang talahanayan ay nagbabago lamang kung aling yugto ang susunod na mabibigo.
Dalawang iba pang bagay ang madalas sinisisi sa parehong punto. Maaaring tanggapin ang ruta at matalo pa rin sa isang mas partikular na ruta, at maaaring ihulog ng firewall rule ang trapiko pagkatapos ng tamang paghahanap. Panatilihing hiwalay ang mga yugto: syntax, pag-install, pagpili, pag-filter. Ang paggawa sa maling yugto ay parang produktibo dahil bawat pagbabago ay nagsisimula muli ng isang bagay.
Suriin ang naka-install na ruta at ang landas na panalo nito
Kapag tinanggap ng client ang linya, tingnan kung ano ang in-install nito at kung aling ruta ang pipiliin ng kernel para sa isang representatibong address sa loob ng block. Kung ang naka-install na prefix ay naiiba sa isinulat mo, may normalizer na kumilos sa ngalan mo.
Magtanong ng isang member address at isa rin sa labas ng block, upang ang paghahambing ay makabuluhan at hindi lamang isang nakaaaliw na linya:
ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10Ang ikatlong query ay dapat mahulog sa labas ng tunnel kung tama ang prefix mo, at kapag hindi, ang rutang itinayo mo ay mas malawak kaysa sa iniisip mo. Itala kung ano ang dapat saklawin ng prefix bago mo hawakan ang susunod na setting, dahil ang rutang napa-parse at ang landas na gumagana ay nananatiling magkahiwalay na obserbasyon.