Bakit ang route-nopull lang ay iniiwan ang file server na hindi maabot

Maayos na bumubukas ang file server, at ang video call sa katabing window ay nagsisimulang pumalya. Walang mabagal at walang MTU na mali: tinanggap ng iyong kliyente ang listahan ng ruta na ibinigay ng server, kaya bawat packet ay lumalabas na ngayon sa firewall ng opisina. Ang solusyon ay hindi isa pang tuning flag kundi isang desisyon kung kanino pag-aari ang talahanayan ng ruta ng kliyente. Ang desisyong iyon ay kabilang sa isang lugar lamang, at ang mga mode ng pagkasira sa ibaba ay nagsasabi kung aling lugar ang pinili mo talaga.

Magpasya kung kanino pag-aari ang talahanayan ng ruta

Tatlong may-ari ang posible. Maaaring magtulak ang server ng mga ruta at default na gateway, at sa gayon ang kliyente ay nag-i-install ng sinasabi sa kanya at nagiging buong tunnel. Maaaring kunin ng profile ng kliyente ang pagmamay-ari sa pamamagitan ng pagtatapon ng mga tulak at pagdadala ng sarili nitong mga linya ng ruta. Ang tagapamahala ng koneksyon sa desktop ay maaari ring magmay-ari ng desisyon sa pamamagitan ng sarili nitong mga katangian ng ruta at default na ruta.

Bawat pagpipilian ay nabigo sa ibang paraan, kaya sulit basahin ang talahanayan bago i-edit ang isang profile. Ang hilera na tumutugma sa iyong sintomas ay ang may-ari na talagang mayroon ka.

Pumili ng isa at isulat ito. Ang paghahalo ng dalawa ay nag-iiwan ng host na ang default na landas ay sumasalungat sa sarili nitong dokumentasyon, at hindi matukoy ng susunod na inhinyero kung aling layer ang nanalo. Tanggalin nang tahasan ang natalo.

Ang route-nopull ay nagsasala ng mga tulak, hindi ito nagdadagdag ng ruta

route-nopull ay kabilang sa profile ng kliyente, at ang pagkakasunod-sunod nito sa file na iyon ay walang kinalaman dahil itinatapon lamang nito ang mga halagang nagmumula sa server. Itinatapon nito ang mga itinulak na ruta, kabilang ang itinulak na default na ruta, habang ang tunnel ay umaangat pa rin nang normal.

Ang resulta na hindi napapansin ng mga tao ay ang mga itinulak na opsyon ng DHCP ay umaalis kasama nila. Ang mga setting ng DNS na ipinapadala ng server ay itinatapon din, kaya ang mga panloob na pangalan ay humihinto sa pagresolba kahit malusog ang tunnel at naaabot ang server sa pamamagitan ng address.

Iniiwan nito ang isang tunnel na walang landas patungo sa prefix ng opisina maliban kung magdagdag ka mismo ng isa: route-nopull na sinusundan ng route 10.30.0.0 255.255.0.0 sa parehong profile. Ang linyang iyon ay nagdadala ng address at mask; hindi nito pinapangalanan ang susunod na hop.

Ang alternatibong anyo ay nagdaragdag ng gateway token, route 10.30.0.0 255.255.0.0 vpn_gateway, na itinuturo ang entry sa tunnel sa pamamagitan ng pangalan. Nagkakaiba ang mga importer kung isinasalin nila ang variant na iyon, kaya siyasatin ang naka-save na koneksyon kung nawawala ang entry sa talahanayan ng kernel.

I-verify gamit ang mga paghahanap ng ruta, hindi gamit ang ping

Sinasabi ng ping na may sumagot. Sinasabi ng paghahanap ng ruta kung aling interface ang pipiliin ng kernel, at iyon ang tanong na talagang itinanong mo. Apat na maiikling utos ang naghihiwalay ng nawawalang ruta mula sa rutang tumuturo sa maling device.

Basahin kung ano ang in-install ng tunnel gamit ang ip route show dev tun0. Ang ganap na kawalan ng output ay nangangahulugang zero ruta, na hindi isang gumaganang split tunnel, at iyon ang karaniwang resulta ng pagdaragdag ng filter nang walang tahasang linya.

Pagkatapos ay suriin ang isang address ng opisina gamit ang ip route get 10.30.5.7, at isang ordinaryong address ng internet gamit ang ip route get 1.1.1.1. Dapat pangalanan ng pangalawa ang pisikal na interface; kung pinapangalanan nito ang tunnel, hindi nasala ang tulak.

Sa huli basahin ang ip rule, dahil ang patakaran ng patakaran na iniwan ng naunang pagtatangka ay maaaring mangibabaw sa talahanayang kakalutas mo lang. Ang tamang profile na may lipas na patakaran sa ibabaw ay mukhang sira na profile. Tanggalin ang patakarang idinagdag mo noong huling pagkakataon bago magdagdag ng iba.

Ang magkakapatong na subnet ay mukhang sirang tunnel

Dalawang pribadong saklaw ay maaaring magkapareho mula sa pananaw ng kliyente, at doon ay sinisisi ang split tunnel sa isang bagay na hindi nito ginawa. Kung ang opisina ay namamahagi ng parehong prefix na ginagamit ng iyong home router, sinasaklaw ng ruta ng tunnel ang router at ang network ng bahay ay tila nawawala.

Ihambing ang address sa iyong sariling interface sa rutang in-install ng profile, gamit ang isang simpleng listahan ng address bago ka magbago ng anuman. Tunay ang overlap, at walang opsyon ng profile ang lumulutas nito. Ang maaari mong ayusin ay ang pagpapangalan, upang makita ng susunod na tao ang dalawang saklaw sa halip na isa.

Ang tapat na pag-aayos ay muling pagbilang sa isang panig o pagsasalin ng mga address sa opisina. Ang pagpirmi ng isang rutang host sa router ay gumagana hanggang magbago ang address ng router, at pagkatapos ito ay nagiging pangalawang misteryo sa ibabaw ng una.

Gawing nakakaligtas ang desisyon sa muling pagkonekta

Ang mga entry na manu-manong naitype ay hindi nakakaligtas sa muling pagkonekta, at ang tagapamahala ng koneksyon ay muling nagtatayo ng talahanayan sa tuwing magsisimula ang profile. Ilagay ang desisyon kung saan nilikha ang koneksyon, maging ang profile o ang naka-save na setting ng tagapamahala. Pagkatapos ay i-restart ang koneksyon isang beses nang sadya sa halip na matuklasan ang pag-uugali sa gitna ng isang tawag. Ang profile na gumagana lamang hanggang sa susunod na muling pagkonekta ay hindi pa tapos.

Sanayin ang tatlong landas nang sabay: isang host ng opisina sa literal na address, ang parehong host sa pangalan, at isang ordinaryong pampublikong site. Ang nasa gitna ay nakasalalay sa serbisyo ng pangalan na na-configure mo pagkatapos itapon ang mga itinulak na opsyon ng DNS, at iyon ang tahimik na nabigo.