Kial nur route-nopull lasas la dosierujan servilon neatingebla
Ignori puŝitajn itinerojn estas nur duono de dividita tunelo. Elektu la itinerposedanton, aldonu la oficejan prefikson permane, kaj testu tri fluojn antaŭ ol nomi ĝin riparita.
La dosieruja servilo malfermiĝas bone, kaj la videovoko en la apuda fenestro komencas stumbli. Nenio estas malrapida kaj neniu MTU estas malĝusta: via kliento akceptis la itinerliston, kiun la servilo donis al ĝi, do ĉiu pako nun eliras tra la fajroŝirmilo de la oficejo. La riparo ne estas plia agorda ŝaltilo sed decido pri tio, kiu posedas la itineran tabelon de la kliento. Tiu decido apartenas al unu loko, kaj la malsukcesaj manieroj sube diras al vi, kiun lokon vi efektive elektis.
Decidu, kiu posedas la itineran tabelon
Tri posedantoj eblas. La servilo povas puŝi itinerojn kaj defaŭltan enirejon, kaj tiam la kliento instalas tion, kion oni diras al ĝi, kaj fariĝas plena tunelo. La klienta profilo povas preni posedon per forĵeto de la puŝoj kaj portado de propraj itineraj linioj. Labortabla konekta administrilo ankaŭ povas posedi la decidon per siaj propraj itinero- kaj defaŭltitinero-ecoj.
Ĉiu elekto malsukcesas alimaniere, kaj tial indas legi la tabelon antaŭ ol redakti profilon. La vico, kiu kongruas kun via simptomo, estas la posedanto, kiun vi efektive havas.
| 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 |
Elektu unu kaj skribu ĝin. Miksi du lasas gastiganton, kies defaŭlta vojo kontraŭdiras sian propran dokumentaron, kaj la sekva inĝeniero ne povas vidi, kiu tavolo venkis. Forigu la malvenkinton eksplicite.
route-nopull filtras puŝojn, ĝi ne aldonas itinerojn
route-nopull apartenas al la klienta profilo, kaj ĝia ordo en tiu dosiero estas sensignifa, ĉar ĝi nur forĵetas valorojn venantajn de la servilo. Ĝi forĵetas puŝitajn itinerojn, inkluzive de puŝita defaŭlta itinero, dum la tunelo ankoraŭ leviĝas normale.
La sekvo, kiun homoj maltrafas, estas ke puŝitaj DHCP-opcioj iras kun ili. Ankaŭ la DNS-agordoj senditaj de la servilo estas forĵetitaj, do internaj nomoj ĉesas solviĝi eĉ kvankam la tunelo estas sana kaj la servilo atingeblas per adreso.
Tio lasas tunelon sen vojo al la oficeja prefikso, krom se vi mem aldonas unu: route-nopull sekvata de route 10.30.0.0 255.255.0.0 en la sama profilo. Tiu linio portas adreson kaj maskon; ĝi ne nomas sekvan salteton.
Alternativa formo aldonas enirejan ĵetonon, route 10.30.0.0 255.255.0.0 vpn_gateway, kiu direktas la eron al la tunelo laŭnome. Importiloj malsamas pri tio, ĉu ili tradukas tiun varianton, do kontrolu la konservitan konekton se la ero mankas en la kernotabelo.
Kontrolu per itineraj serĉoj, ne per ping
Ping diras al vi, ke io respondis. Itinera serĉo diras al vi, kiun interfacon la kerno elektus, kaj tio estas la demando, kiun vi efektive starigis. Kvar mallongaj komandoj apartigas mankantan itineron de itinero, kiu montras al la malĝusta aparato.
Legu, kion la tunelo instalas per ip route show dev tun0. Nenia eligado entute signifas nulon da itineroj, kio ne estas funkcianta dividita tunelo, kaj tio estas la kutima rezulto de aldono de la filtrilo sen la eksplicita linio.
Poste kontrolu unu oficejan adreson per ip route get 10.30.5.7, kaj unu ordinaran interretan adreson per ip route get 1.1.1.1. La dua devus nomi la fizikan interfacon; se ĝi nomas la tunelon, la puŝo tute ne estis filtrita.
Fine legu ip rule, ĉar politika regulo lasita de antaŭa provo povas superregi la tabelon, kiun vi ĵus korektis. Ĝusta profilo kun malnova regulo supre aspektas ĝuste kiel rompita profilo. Forigu la regulon, kiun vi aldonis lastfoje, antaŭ ol aldoni alian.
Interkovrantaj subretoj aspektas kiel rompita tunelo
Du privataj gamoj povas esti identaj el la vidpunkto de la kliento, kaj ĝuste tie dividita tunelo estas kulpigata pri io, kion ĝi ne kaŭzis. Se la oficejo disdonas la saman prefikson, kiun uzas via hejma enkursigilo, la tunela itinero kovras la enkursigilon kaj la hejma reto ŝajnas malaperi.
Komparu la adreson sur via propra interfaco kun la itinero, kiun la profilo instalas, uzante ordinaran adresliston antaŭ ol ŝanĝi ion ajn. La interkovro estas reala, kaj neniu profila opcio solvas ĝin. Kion vi povas ripari estas la nomado, por ke la sekva persono vidu du gamojn anstataŭ unu.
La honestaj riparoj estas renumerigi unu flankon aŭ traduki adresojn en la oficejo. Fiksi unu gastigantan itineron al la enkursigilo funkcias ĝis la enkursigila adreso ŝanĝiĝas, kaj tiam ĝi fariĝas dua mistero super la unua.
Igu la decidon postvivi rekonekton
Eroj tajpitaj permane ne postvivas rekonekton, kaj konekta administrilo rekonstruas la tabelon ĉiufoje, kiam la profilo ekfunkcias. Metu la decidon tie, kie la konekto estas kreata, ĉu temas pri la profilo aŭ pri la konservitaj agordoj de la administrilo. Poste restartigu la konekton unufoje intence, anstataŭ malkovri la konduton dum voko. Profilo, kiu funkcias nur ĝis la sekva rekonekto, ne estas finita.
Ekzercu tri vojojn samtempe: oficejan gastiganton per la laŭlitera adreso, la saman gastiganton per nomo, kaj ordinaran publikan retejon. La meza dependas de la nomservo, kiun vi agordis post forĵeto de la puŝitaj DNS-opcioj, kaj ĝi estas tiu, kiu silente malsukcesas.