Kodėl vien route-nopull palieka failų serverį nepasiekiamą
Stumiamų maršrutų ignoravimas tėra pusė padalyto tunelio. Pasirinkite maršruto savininką, rankiniu būdu pridėkite biuro prefiksą ir patikrinkite tris srautus, prieš vadindami tai ištaisyta.
Failų serveris atsidaro gerai, o gretimame lange vaizdo skambutis pradeda strigti. Niekas nėra lėtas ir joks MTU nėra neteisingas: jūsų klientas priėmė serverio duotą maršrutų sąrašą, todėl dabar kiekvienas paketas išeina per biuro užkardą. Sprendimas – ne dar vienas derinimo parametras, o sprendimas, kam priklauso kliento maršrutų lentelė. Tas sprendimas priklauso vienai vietai, o žemiau aprašyti gedimo būdai pasako, kurią vietą iš tikrųjų pasirinkote.
Nuspręskite, kam priklauso maršrutų lentelė
Galimi trys savininkai. Serveris gali stumti maršrutus ir numatytąją šliuzą, ir tada klientas įdiegia viską, kas jam pasakyta, ir tampa pilnu tuneliu. Kliento profilis gali perimti nuosavybę atmesdamas stūmimus ir nešdamas savo maršrutų eilutes. Darbalaukio ryšio tvarkyklė taip pat gali valdyti sprendimą per savo maršruto ir numatytojo maršruto savybes.
Kiekvienas pasirinkimas žlunga kitaip, todėl verta perskaityti lentelę prieš redaguojant profilį. Eilutė, kuri atitinka jūsų simptomą, yra savininkas, kurį iš tikrųjų turite.
| Owner | Where it lives | Result |
|---|---|---|
| Server | server config, redirect-gateway, pushed routes | client becomes a full tunnel |
| Profile | route-nopull and its own route lines | tunnel up, office prefix missing |
| Manager | never-default plus its own routes | desktop decides, profile ignored |
Pasirinkite vieną ir užsirašykite. Sumaišius du lieka pagrindinis kompiuteris, kurio numatytasis kelias prieštarauja jo paties dokumentacijai, o kitas inžinierius negali pasakyti, kuris sluoksnis laimėjo. Ištrinkite pralaimėtoją aiškiai.
route-nopull filtruoja stūmimus, jis neprideda maršrutų
route-nopull priklauso kliento profiliui, o jo tvarka tame faile nesvarbi, nes jis tik atmeta reikšmes, ateinančias iš serverio. Jis atmeta stumiamus maršrutus, įskaitant stumiamą numatytąjį maršrutą, o tunelis vis tiek keliasi normaliai.
Pasekmė, kurią žmonės praleidžia, yra ta, kad stumiami DHCP parametrai eina kartu su jais. Serverio siunčiami DNS nustatymai taip pat atmetami, todėl vidiniai vardai nustoja spręstis, nors tunelis sveikas, o serveris pasiekiamas adresu.
Tai palieka tunelį be kelio į biuro prefiksą, nebent patys jį pridėsite: tame pačiame profilyje route-nopull ir po jo route 10.30.0.0 255.255.0.0. Ta eilutė neša adresą ir kaukę; ji neįvardija kito šuolio.
Alternatyvi forma prideda šliuzo žymeklį, route 10.30.0.0 255.255.0.0 vpn_gateway, kuris įrašą nukreipia į tunelį pagal pavadinimą. Importuotojai skiriasi tuo, ar verčia tą variantą, todėl patikrinkite išsaugotą ryšį, jei įrašo nėra branduolio lentelėje.
Tikrinkite maršrutų paieškomis, o ne ping
Ping pasako, kad kažkas atsakė. Maršruto paieška pasako, kurią sąsają branduolys pasirinktų, ir tai yra klausimas, kurį iš tikrųjų uždavėte. Keturios trumpos komandos atskiria trūkstamą maršrutą nuo maršruto, nukreipto į netinkamą įrenginį.
Perskaitykite, ką tunelis įdiegė, naudodami ip route show dev tun0. Visai nėra išvesties – nulis maršrutų, o tai nėra veikiantis padalytas tunelis, ir tai įprastas rezultatas pridėjus filtrą be aiškios eilutės.
Tada patikrinkite vieną biuro adresą su ip route get 10.30.5.7 ir vieną įprastą interneto adresą su ip route get 1.1.1.1. Antrasis turėtų įvardyti fizinę sąsają; jei įvardija tunelį, stūmimas visiškai nebuvo filtruotas.
Galiausiai perskaitykite ip rule, nes ankstesnio bandymo palikta politikos taisyklė gali nusverti ką tik pataisytą lentelę. Teisingas profilis su pasenusia taisykle viršuje atrodo lygiai kaip sugadintas profilis. Ištrinkite taisyklę, kurią pridėjote praėjusį kartą, prieš pridėdami dar vieną.
Persidengiantys potinkliai atrodo kaip sugadintas tunelis
Du privatūs diapazonai gali būti identiški kliento požiūriu, ir būtent ten padalytas tunelis kaltinamas dėl to, ko nesukėlė. Jei biuras išduoda tą patį prefiksą, kurį naudoja jūsų namų maršrutizatorius, tunelio maršrutas uždengia maršrutizatorių, ir namų tinklas atrodo dingęs.
Palyginkite savo sąsajos adresą su maršrutu, kurį įdiegia profilis, naudodami paprastą adresų sąrašą prieš ką nors keisdami. Persidengimas realus, ir jokia profilio parinktis jo neišsprendžia. Tai, ką galite pataisyti, yra pavadinimai, kad kitas žmogus matytų du diapazonus, o ne vieną.
Sąžiningi pataisymai – pernumeruoti vieną pusę arba išversti adresus biure. Vieno pagrindinio kompiuterio maršruto prisegimas prie maršrutizatoriaus veikia tol, kol pasikeičia maršrutizatoriaus adresas, o tada tai tampa antra mįsle virš pirmosios.
Padarykite, kad sprendimas išliktų po prisijungimo iš naujo
Rankiniu būdu įvesti įrašai neišlieka po prisijungimo iš naujo, o ryšio tvarkyklė kaskart, kai profilis paleidžiamas, lentelę perstato. Padėkite sprendimą ten, kur ryšys sukuriamas – ar tai būtų profilis, ar tvarkyklės išsaugoti nustatymai. Tada vieną kartą sąmoningai paleiskite ryšį iš naujo, o ne atraskite elgseną skambučio metu. Profilis, kuris veikia tik iki kito prisijungimo iš naujo, nėra baigtas.
Išbandykite tris kelius vienu metu: biuro pagrindinį kompiuterį tiesioginiu adresu, tą patį kompiuterį vardu ir įprastą viešą svetainę. Vidurinis priklauso nuo vardų tarnybos, kurią sukonfigūravote atsisakę stumiamų DNS parinkčių, ir būtent jis tyliai žlunga.