Зашто VPN рута не приказује мрежни пролаз у излазу ip route
Линија са уређајем и без мрежног пролаза је директна рута, а не покварена. Прочитајте одредиште, dev и scope, а затим потврдите помоћу ip route get.
Табеле рутирања се често читају као покварене кад год колона мрежног пролаза остане празна, иако је линија обично потпуна сама по себи. Поље via појављује се само када језгро преда пакет адреси следећег скока; рута повезана са интерфејсом достиже своја одредишта уместо тога кроз резолуцију на слоју везе или кроз партнера од тачке до тачке. Читање колона с лева на десно говори у ком случају сте, и то читање би требало да се догоди пре него што било ко измени подразумевану руту. Већина тикета о пролазу који недостаје завршава се на овој разлици.
Читајте линију руте колону по колону
Сваки унос почиње одредиштем и дужином његовог префикса, затим додаје модификаторе у фиксном речнику: via, dev, proto, scope, src и metric. Линија као 198.51.100.0/24 dev tun0 proto kernel scope link src 198.51.100.2 је густа, али потпуно одређена. Ништа јој не недостаје и никаква адреса рутера се не подразумева.
Занимљив је део недостатак via. Без следећег скока језгро решава одредиште директно на наведеном интерфејсу, што за тунел значи предају оквира тунелском уређају и пуштање инкапсулације да преузме одатле. proto kernel бележи да је унос инсталиран аутоматски када је адреса додељена, а не да га је администратор откуцао. scope link каже да је одредиште достижно на тој вези без проласка кроз рутер, а src именује адресу коју ће језгро преферирати као извор за саобраћај који се поклапа.
Сада прочитајте подразумевану руту на исти начин: default via 192.0.2.254 dev eth0 proto static metric 100. Овде је via присутно јер пакету заиста треба следећи скок, и тај скок сам мора бити достижан на eth0. Те две линије нису варијанте једна друге; оне одговарају на различита питања о томе куда саобраћај иде.
Два облика руте која се међусобно замењују
Рута подмреже тунела и подразумевана рута изгледају слично на снимку екрана и понашају се сасвим различито. Користите табелу испод као помоћ за читање поља, а затим потврдите стварне бројеве на машини коју отклањате, уместо да верујете примеру из приручника.
| 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 |
Оно што табела не може да вам каже јесте намера. Директна рута до приватног опсега кроз тунел је намерни дизајн подељеног тунела; исти облик на домаћину који би требало да шаље све кроз VPN је симптом. Намера живи у конфигурацији која је створила унос, зато погледајте алат који га је инсталирао пре него што закључите да је језгро нешто погрешило.
Исто тако, пролаз који недостаје није дозвола да га измислите. Ако рути заиста треба следећи скок, тај скок мора бити достижан на интерфејсу који га носи, а за тунел од тачке до тачке адреса партнера није исти објекат као локална адреса. Третирање локалне адресе тунела као Ethernet рутера је чест начин да се добије рута која изгледа исправно и ништа не прослеђује.
Питајте језгро коју ће линију заиста користити
Читање табеле није исто што и извођење претраге, јер језгро пре одговора консултује правила политике, неколико табела и кеширане уносе. Глагол који изводи праву претрагу је ip route get, и исписује руту коју би пакет са тим својствима кренуо.
ip route get 203.0.113.37 from 198.51.100.2 iif tun0Замените одредиштем које вам је заиста важно, затим додајте from или iif када је саобраћај изабран по извору или прослеђен, јер обична локална претрага може изабрати другачији пут од прослеђеног клијента. Одговор именује интерфејс, изабрану изворну адресу и било који следећи скок, што су исте информације са којима би пакет у том тренутку био рутиран.
Ако вас одговор изненади, испишите правила пре било какве измене: ip -4 rule show их наводи по редоследу приоритета, а VPN клијент који инсталира своју табелу или правило за означене пакете уопште се неће појавити у главној табели. Навођење свих табела затвара ту празнину.
ip -4 route show table all | grep -E 'tun|default'Проверите доњи слој пре него што замените подразумевану руту
Сопствени пакети тунела морају стићи до удаљене крајње тачке, и то чине кроз физички интерфејс користећи руту која је постојала пре него што се VPN подигао. Замена целе подразумеване руте без причвршћивања те крајње тачке шаље инкапсулиране пакете у тунел који је требало да изграде, и веза се руши. Прво потврдите пут до крајње тачке претрагом само њене адресе.
Држите три ствари одвојено када правите измену: руту до крајње тачке која мора остати на физичком интерфејсу, приватне опсеге који би требало да уђу у тунел, и подразумевану руту која одлучује о свему осталом. Раздвојите их тим редом, примените једну по једну и поново покрените претрагу после сваког корака. Неуспешан ping после тога сам по себи доказује веома мало, јер дозволе, рутирање одговора, DNS и сама услуга сви стоје низводно од исправне руте.
Запишите четири вредности које вам је линија дала пре измене: одредиште, следећи скок или његово одсуство, уређај и изабрани извор. Ако каснија измена помери било коју од њих, знате која је одлука заправо измењена, и можете да вратите један унос уместо да погађате целу табелу.