Bakit walang gateway na ipinapakita ang ruta ng VPN sa output ng ip route
Ang linyang may device at walang gateway ay direktang ruta, hindi sira. Basahin ang destinasyon, dev at scope, pagkatapos ay kumpirmahin gamit ang ip route get.
Madalas basahin ang mga talahanayan ng routing bilang sira tuwing walang laman ang hanay ng gateway, kahit kadalasan ay kumpleto na ang linya sa sarili nito. Lumilitaw lamang ang field na via kapag ipinasa ng kernel ang packet sa isang address ng susunod na hop; ang rutang nakakabit sa isang interface ay umaabot sa mga destinasyon nito sa halip sa pamamagitan ng resolusyon sa link layer o sa pamamagitan ng peer na point-to-point. Ang pagbasa sa mga hanay mula kaliwa pakanan ay nagsasabi kung anong kaso ang kinalalagyan mo, at ang pagbasang iyon ay dapat mangyari bago pa may mag-edit ng default na ruta. Karamihan sa mga ticket tungkol sa nawawalang gateway ay nagtatapos sa pagkakaibang ito.
Basahin ang linya ng ruta hanay bawat hanay
Bawat entry ay nagsisimula sa destinasyon at haba ng prefix nito, pagkatapos ay nagdaragdag ng mga modifier sa isang takdang bokabularyo: via, dev, proto, scope, src at metric. Ang linyang tulad ng 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 ay siksik ngunit ganap na tinukoy. Walang kulang dito, at walang address ng router na ipinahihiwatig.
Ang kawalan ng via ang kawili-wiling bahagi. Kung walang susunod na hop, nilulutas ng kernel ang destinasyon nang direkta sa pinangalanang interface, na para sa isang tunnel ay nangangahulugang ipasa ang frame sa tunnel device at hayaang ang encapsulation ang humawak mula roon. Itinatala ng proto kernel na awtomatikong na-install ang entry nang magtalaga ng address, hindi ito tinipa ng isang administrator. Sinasabi ng scope link na maaabot ang destinasyon sa link na iyon nang hindi dumadaan sa router, at pinangalanan ng src ang address na pipiliin ng kernel bilang pinagmulan para sa tumutugmang trapiko.
Ngayon basahin ang default na ruta sa parehong paraan: default via 192.0.2.254 dev eth0 proto static metric 100. Narito ang via dahil talagang kailangan ng packet ang susunod na hop, at ang hop na iyon mismo ay dapat maabot sa eth0. Ang dalawang linyang iyon ay hindi mga baryante ng isa't isa; sinasagot nila ang magkaibang tanong tungkol sa kung saan pupunta ang trapiko.
Dalawang hugis ng ruta na napagkakamalan
Ang ruta ng subnet ng tunnel at ang default na ruta ay magkamukha sa isang screenshot at kumikilos nang lubos na magkaiba. Gamitin ang talahanayan sa ibaba bilang tulong sa pagbasa ng mga field, pagkatapos ay kumpirmahin ang tunay na mga numero sa makina na ini-debug mo sa halip na magtiwala sa isang halimbawa mula sa gabay.
| 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 |
Ang hindi masasabi ng talahanayan ay ang layunin. Ang direktang ruta patungo sa pribadong saklaw sa pamamagitan ng tunnel ay sadyang disenyo ng split tunnel; ang parehong hugis na lumilitaw sa isang host na dapat magpadala ng lahat sa pamamagitan ng VPN ay sintomas. Ang layunin ay naninirahan sa configuration na lumikha ng entry, kaya tingnan ang tool na nag-install nito bago ka magpasyang nagkamali ang kernel.
Gayundin, ang nawawalang gateway ay hindi pahintulot na mag-imbento ng isa. Kung talagang kailangan ng ruta ang susunod na hop, ang hop na iyon ay dapat maabot sa interface na nagdadala nito, at para sa point-to-point tunnel ang address ng peer ay hindi kaparehong bagay sa lokal na address. Ang pagtrato sa lokal na address ng tunnel bilang Ethernet router ay karaniwang paraan upang makagawa ng rutang mukhang tama at walang ipinapasa.
Tanungin ang kernel kung aling linya ang talagang gagamitin nito
Ang pagbasa ng talahanayan ay hindi katulad ng pagsasagawa ng paghahanap, dahil kumukonsulta ang kernel sa mga patakaran ng patakaran, ilang talahanayan at mga naka-cache na entry bago sumagot. Ang pandiwang nagsasagawa ng tunay na paghahanap ay ip route get, at ipinapakita nito ang rutang tatahakin ng isang packet na may mga katangiang iyon.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0
Palitan ng destinasyong talagang mahalaga sa iyo, pagkatapos ay idagdag ang from o iif kapag pinili ang trapiko ayon sa pinagmulan o ipinapasa, dahil ang ordinaryong lokal na paghahanap ay maaaring pumili ng ibang landas kaysa sa ipinapasang kliyente. Pinangalanan ng sagot ang interface, ang piniling address ng pinagmulan at anumang susunod na hop, na kaparehong impormasyon na gagamitin sa pag-route ng packet sa sandaling iyon.
Kung mabigla ka sa sagot, i-print ang mga patakaran bago baguhin ang anuman: inililista sila ng ip -4 rule show ayon sa pagkakasunod-sunod ng priyoridad, at ang kliyente ng VPN na nag-install ng sarili nitong talahanayan o patakaran para sa mga markadong packet ay hindi lalabas sa pangunahing talahanayan. Ang paglilista ng bawat talahanayan ay nagsasara ng puwang na iyon.
ip -4 route show table all | grep -E 'tun|default'Suriin ang underlay bago palitan ang default
Ang sariling mga packet ng tunnel ay kailangang makarating sa malayong endpoint, at ginagawa nila iyon sa pamamagitan ng pisikal na interface gamit ang rutang umiral bago umangat ang VPN. Ang pagpalit sa buong default na ruta nang hindi ipinipikit ang endpoint na iyon ay nagpapadala sa mga naka-encapsulate na packet papasok sa tunnel na dapat nilang itayo, at bumagsak ang koneksyon. Kumpirmahin muna ang landas patungo sa endpoint sa pamamagitan ng paghahanap sa address ng endpoint lamang.
Panatilihing magkahiwalay ang tatlong bagay kapag gagawin mo ang pagbabago: ang ruta patungo sa endpoint na dapat manatili sa pisikal na interface, ang mga pribadong saklaw na dapat pumasok sa tunnel, at ang default na nagpapasya sa lahat ng iba pa. Paghiwalayin ang mga ito sa ganoong pagkakasunod-sunod, ilapat ang isa sa isang pagkakataon, at patakbuhin muli ang paghahanap pagkatapos ng bawat hakbang. Ang isang nabigong ping pagkatapos ay kakaunti ang pinatutunayan sa sarili nito, dahil ang mga pahintulot, routing ng sagot, DNS at ang serbisyo mismo ay pawang nasa ibaba ng tamang ruta.
Isulat ang apat na halagang ibinigay sa iyo ng linya bago ang pag-edit: destinasyon, susunod na hop o ang kawalan nito, device, at piniling pinagmulan. Kung may gumalaw sa alinman sa mga ito sa susunod na pagbabago, alam mo kung aling pasya ang tunay na nabago, at maaari mong ibalik ang isang entry sa halip na hulaan ang buong talahanayan.