Kial VPN-itinero montras neniun retpordegon en la eligo de ip route
Linio kun aparato kaj sen retpordego estas rekta itinero, ne rompita. Legu celon, dev kaj scope, poste konfirmu per ip route get.
Itinertabeloj estas mislegataj kiel rompitaj ĉiam, kiam la kolumno de la retpordego restas malplena, kvankam la linio kutime estas kompleta per si mem. La kampo via aperas nur tiam, kiam la kerno transdonas la paketon al adreso de sekva salteto; itinero ligita al interfaco atingas siajn celojn anstataŭe per solvado de la liga tavolo aŭ per samranga nodo de punkto al punkto. Legi la kolumnojn de maldekstre dekstren diras al vi, en kiu kazo vi troviĝas, kaj tiu legado devus okazi antaŭ ol iu ajn redaktas defaŭltan itinero. Plej multaj biletoj pri mankanta retpordego finiĝas ĉe tiu distingo.
Legu itinero-linion kolumno post kolumno
Ĉiu rikordo komenciĝas per la celo kaj ĝia prefiksa longo, poste aldonas modifilojn en fiksa vortaro: via, dev, proto, scope, src kaj metric. Linio kiel 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 estas densa sed tute specifita. Nenio mankas en ĝi, kaj neniu enkursiga adreso estas implicata.
La manko de via estas la interesa parto. Sen sekva salteto, la kerno solvas la celon rekte sur la nomita interfaco, kio por tunelo signifas transdoni la kadron al la tunela aparato kaj lasi la enkapsuligon transpreni de tie. proto kernel registras, ke la rikordo estis instalita aŭtomate kiam adreso estis atribuita, ne tajpita de administranto. scope link diras, ke la celo estas atingebla sur tiu ligo sen pasi tra enkursigilo, kaj src nomas la adreson, kiun la kerno preferos kiel fonton por kongrua trafiko.
Nun legu defaŭltan itinero same: default via 192.0.2.254 dev eth0 proto static metric 100. Ĉi tie via ĉeestas ĉar la paketo ja bezonas sekvan saltegon, kaj tiu salteto mem devas esti atingebla sur eth0. La du linioj ne estas variantoj unu de la alia; ili respondas malsamajn demandojn pri tio, kien la trafiko iras.
Du itineroj formoj, kiuj konfuziĝas unu kun la alia
Tunela subreta itinero kaj defaŭlta itinero aspektas similaj en ekrankopio kaj kondutas tute malsame. Uzu la suban tabelon kiel leghelpon por la kampoj, poste konfirmu la efektivajn nombrojn sur la maŝino, kiun vi sencimigas, anstataŭ fidi specimenon el gvidilo.
| Piece of the line | What it settles | What it says nothing about |
|---|---|---|
| The destination and mask | Which packets are eligible to match | Where those packets leave the host |
via plus its address | Which next hop receives them, and therefore that a router is involved | Whether that router is reachable or sane |
dev | Which interface carries the encapsulated or raw packet | Whether the interface is up or has a carrier |
proto and scope | Who installed the entry and how far the destination is considered to be | Whether a firewall later drops the traffic |
Kion la tabelo ne povas diri al vi, estas la intenco. Rekta itinero al privata gamo tra tunelo estas intenca projektado de dividita tunelo; la sama formo sur gastiganto, kiu devus sendi ĉion tra la VPN, estas simptomo. Intenco vivas en la agordo, kiu produktis la rikordon, do rigardu la ilon, kiu instaligis ĝin, antaŭ ol konkludi, ke la kerno eraris.
Same, mankanta retpordego ne estas permeso elpensi unu. Se itinero vere bezonas sekvan saltegon, tiu salteto devas esti atingebla sur la interfaco, kiu portas ĝin, kaj por punkto-al-punkta tunelo la adreso de la samranga nodo ne estas la sama objekto kiel la loka adreso. Trakti la lokan tunelan adreson kiel Ethernet-enkursigilo estas ofta maniero produkti itinero, kiu aspektas ĝusta kaj plusendas nenion.
Demandu la kernon, kiun linion ĝi efektive uzos
Legi la tabelon ne samas kiel plenumi la serĉon, ĉar la kerno konsultas politikajn regulojn, plurajn tabelojn kaj kaŝmemorajn rikordojn antaŭ ol respondi. La verbo, kiu plenumas la veran serĉon, estas ip route get, kaj ĝi presas la itinero, kiun prenus paketo kun tiuj ecoj.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Anstataŭigu la celon, pri kiu vi vere zorgas, poste aldonu from aŭ iif kiam la trafiko estas fonto-elektita aŭ plusendita, ĉar ordinara loka serĉo povas elekti alian vojon ol plusendita kliento. La respondo nomas la interfacon, la elektitan fontan adreson kaj ajnan sekvan saltegon, kio estas la sama informo, per kiu paketo estus enkursigita en tiu momento.
Se la respondo surprizas vin, presu la regulojn antaŭ ol ŝanĝi ion: ip -4 rule show listigas ilin laŭ prioritata ordo, kaj VPN-kliento, kiu instalas sian propran tabelon aŭ regulon por markitaj paketoj, tute ne aperos en la ĉefa tabelo. Listigi ĉiujn tabelojn fermas tiun breĉon.
ip -4 route show table all | grep -E 'tun|default'Kontrolu la suban tavolon antaŭ ol anstataŭigi la defaŭltan itinero
La propraj paketoj de la tunelo devas atingi la malproksiman finpunkton, kaj ili faras tion tra la fizika interfaco uzante la itinero, kiu ekzistis antaŭ ol la VPN ekfunkciis. Anstataŭigi la tutan defaŭltan itinero sen fiksi tiun finpunkton sendas la enkapsulitajn paketojn en la tunelon, kiun ili devus konstrui, kaj la konekto kolapsas. Unue konfirmu la vojon al la finpunkto per serĉo nur de la finpunkta adreso.
Tenu tri aferojn aparte, kiam vi faras la ŝanĝon: la itinero al la finpunkto, kiu devas resti sur la fizika interfaco, la privataj gamoj, kiuj devus eniri la tunelon, kaj la defaŭlta itinero, kiu decidas ĉion alian. Disigu ilin en tiu ordo, apliku unu samtempe kaj relanu la serĉon post ĉiu paŝo. Malsukcesa ping poste mem pruvas tre malmulte, ĉar permesoj, responda enkursigo, DNS kaj la servo mem ĉiuj situas malsupre de ĝusta itinero.
Notu la kvar valorojn, kiujn la linio donis al vi antaŭ la redakto: celo, sekva salteto aŭ ĝia manko, aparato kaj elektita fonto. Se posta ŝanĝo movos iun ajn el ili, vi scias, kiu decido efektive estis ŝanĝita, kaj vi povas restarigi unu rikordon anstataŭ diveni la tutan tabelon.