Зошто 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 и самата услуга стојат низводно од правилна рута.
Запишете ги четирите вредности што ви ги даде линијата пред уредувањето: дестинација, следен скок или негово отсуство, уред и избран извор. Ако подоцнежна промена помести која било од нив, знаете кое решение всушност е променето, и можете да вратите еден запис наместо да ја погодувате целата табела.