Што менува рутирањето по политика во VPN сообраќајот, а што не
Правилата избираат која табела се проверува, затоа стандардната рута во главната табела често не објаснува ништо. Читајте ги приоритетите, ознаките и изворите заедно пред да додадете правило.
Рутирањето по политика одговара на друго прашање од она што го поставуваат повеќето белешки за отстранување проблеми. Главната табела кажува каде оди одредиштето; правилата на политиката кажуваат која табела воопшто се проверува, и можат тоа да го решат според изворната адреса, ознака на пакет, или според интерфејсот на кој пристигнал пакетот. Кога тунелот се однесува недоследно, множеството правила е често причината, а табелата за рутирање често не е.
Правилата ја избираат табелата, потоа табелата ја избира рутата
Секое правило носи приоритет, услов за совпаѓање и целна табела. Јадрото ги поминува правилата по редослед на приоритет и запира на првото совпаѓање, потоа извршува обично пребарување на најдолгиот префикс во таа табела. Правило што покажува на празна табела паѓа на тоа што ќе го избере следното правило, и така внимателно напишано правило може да изгледа како да не прави ништо.
Затоа исфрлањето на главната табела ретко објаснува работен VPN клиент. Клиентите обично вметнуваат правила со ниски приоритетни броеви, многу пред стандардното правило на главната табела, така што пакетот никогаш не стигнува до рутата во која гледавте. Намалувањето на метрика во главната табела не менува ништо за сообраќајот што веќе бил пренасочен.
Правилото може и намерно да направи префиксот црна дупка или недостапен. Некои клиенти додаваат такво правило како прекинувач за безбедност, и тогаш отфрлањето изгледа како расипан тунел, а не како конфигуриран.
Читајте го множеството правила како низа, не како список
Испечатете ги правилата со нивните приоритети и табелите на кои упатуваат, потоа испечатете ја секоја табела што носи стандардна или тунелска рута. Редоследот е делот што е важен, и тој е делот што скриншотот обично го испушта:
ip rule show ip route show table all | sed -n '1,60p' ip route get 198.51.100.20 from 10.8.0.2 ip route get 198.51.100.20 from 10.8.0.2 mark 0x1
Последните две наредби се тие што ја претвораат теоријата во набљудување, зашто прашуваат што би направило јадрото за тој извор и таа ознака. Ако одговорот се менува кога се менува ознаката, на дело е правило засновано на ознака и секој тест што ја испушта ознаката тестира друг пакет. Надворешната врска заслужува сопствено правило. Тунел што го рутира целиот сообраќај низ себе мора да ја исклучи адресата на крајната точка со која се поврзува, инаку шифрираните пакети се враќаат во тунелот што штотуку го напуштиле. Повеќето клиенти го вметнуваат тоа исклучување автоматски, а рачно уредено множество правила е местото каде што недостига.
Ознаки и сокети: два начина на кои клиентите го делат сообраќајот
Некои клиенти означуваат пакети во огнениот ѕид и додаваат правило што се совпаѓа со ознаката. Други користат рутирање на ниво на сокет, поставувајќи рута на сокетот пред да се поврзе. Првото е видливо во ip rule; второто не е, и нема да се појави во општо пребарување.
Ако тест-програма се однесува поинаку од апликацијата што треба да ја претставува, проверете дали апликацијата поставува ознака или се врзува за уред. Таа разлика не е мистерија откако механизмот ќе се именува, и објаснува зошто curl од школка и јазиче во прелистувач можат да тргнат по различни патишта на иста машина. Двете техники се рутирање по политика во широка смисла: избираат пат со нешто друго освен одредиштето. Ниту една не го овластува сообраќајот, и ниту една не ги заменува правилата на огнениот ѕид или акредитивите што ги очекува партнерот.
Проследете го сопствеништвото пред да додадете уште едно правило
Правилата ги инсталира нешто. VPN клиент, мрежен менаџер и рачно напишана скрипта можат секој да додадат правила при стартување, а логиката за повторно поврзување може да го остави претходното множество. Две застарени правила од поранешен профил ќе продолжат да го насочуваат сообраќајот долго откако профилот е избришан.
Откријте кој процес го поседува правилото според неговиот приоритет и форма, и проверете дали тој сопственик го препишува множеството при секоја врска. Ако го прави, рачно правило додадено денес исчезнува утре, и исправката припаѓа во конфигурацијата на клиентот, а не во датотека со историја на школка. Бришењето на целото множество правила за тест е примамлив кратен пат со предвидлива цена: ги отстранува и правилата што му се потребни на клиентот за да работи сопствениот тунел. Бришете едно правило по едно, или тестирајте на машина што можете да ја рестартирате.
Докажете го опфатот со два тека, не со еден
Една исправка се потврдува само со тек што треба да биде засегнат и тек што не треба. Изберете одредиште што политиката го рутира во тунелот, и едно што мора да остане надвор, па споредете ги пребарувањата и снимките за двете:
ip route get 198.51.100.20 from 192.0.2.44 ip route get 198.51.100.21 from 192.0.2.44 tcpdump -ni any host 198.51.100.21 and port 443
Кога двете пребарувања враќаат различни интерфејси, правилото прави нешто. Кога враќаат ист интерфејс, правилото се совпаѓа пошироко од предвиденото, и тоа е дефектот што тивко испраќа цела подмрежа низ тунел наменет за една апликација.
Забележете ги приоритетите на правилата и услугата што ги поседува во тикетот, заедно со двете тест-адреси. Тогаш следниот човек има пар што може да се репродуцира наместо опис на симптом, и може во една минута да каже дали рутирањето по политика се уште е на дело.