Маршруттау кестесі және нақты іздеу: VPN трафигі қайда барады

Маршруттау кестесінің дампы VPN ақауларын жою кезіндегі ең пайдасыз диагностика және ең жиі қойылатыны. Қырық жол префикс сізге машинаның не істей алатынын айтады, сәтсіз сұраныс үшін не істегенін емес. Сізге шын мәнінде керек механизм — іздеу: осы көз бен осы межелі орын берілгенде қай ереже сәйкесті, қай кестеге жүгінілді және қай интерфейс пен келесі секіріс шықты. Бір межелі орын мен бір көзден бастаңыз, содан кейін кестені осы сұрақпен оқыңыз, және сол шығыс шуылдың орнына дәлелге айналады.

Кесте — кандидаттар жиынтығы, шешім емес

Әр жазба префиксті және оған сәйкес келетін трафикпен не істеу керегін сипаттайды: оны интерфейске жіберу, келесі секіріске тапсыру немесе тастау. Сол тізімде ешнәрсе мақсат бойынша реттелмеген, және адамға ең нақты болып көрінетін жазба әрдайым ядро таңдайтын жазба бола бермейді, өйткені таңдау ең ұзын префикс сәйкестігіне, ал тең префикстер арасында метрикаға сүйенеді.

Сондықтан бірінші қадам — тізімді оқудың орнына ядродан сұрау. Іздеу командасы межелі орын үшін жауап береді, ал көз аргументімен ол жіберілген немесе байланған қосылым пайдаланатын нақты жұп үшін жауап береді:

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

Жоғарыдағы әр мекенжай — құжаттама мысалы. Мәселе жауаптың пішінінде: интерфейс, таңдалған көз мекенжайы, шлюз және жазба келген кесте. Егер бұл шығыс күткен интерфейске сәйкес келмесе, сіз мәселені бір командамен локализацияладыңыз, және толық кестені оқудың ешбір мөлшері қай кандидат жеңгенін айтпас еді.

Іздеу алдымен ережелерден, содан кейін кестелерден өтеді

Linux-та шешім екі кезеңде қабылданады. Саясат ережелері басымдық ретімен бағаланады, және сәйкес келетін бірінші ереже жүгінетін кестені атайды; содан кейін сол кесте ең ұзын префикс сәйкестігін орындайды. Ереже көз, межелі орын, firewall белгісі, интерфейс немесе олардың тіркесімі бойынша сәйкесуі мүмкін, сондықтан негізгі кесте дампы толық дәл және сіз зерттеп жатқан пакет үшін толық маңызсыз болуы мүмкін.

ip rule show
ip route show table all | head -40
ip route show table 100

Егер ереже VPN пулыңыздан трафикті 100-кестеге жіберсе, онда маңыздысы — 100-кесте, және негізгі кесте — тұзақ. Бұл сонымен қатар маршруттауыштағы көзге негізделген маршруттаудың механизмі: бір межелі орынның пакет қайдан келгеніне қарай екі түрлі жауабы болуы мүмкін, және тек көз аргументі бар іздеу қайсысы қолданылатынын ашады.

IPv6-ның өз ережелері мен кестелері бар. Екі отбасын да іске қосатын дизайн екі іздеуді де қажет етеді, және жұмыс істейтін IPv4 жауабы қос стекті клиент ұнатуы мүмкін v6 жолы туралы ештеңе айтпайды.

VPN клиенті нені орнатады

Клиенттер әдетте әдепкі маршрутты ауыстырмайды, өйткені бұл туннельдің өз сыртқы жолын бұзар еді. Олар префикс ұзындығымен жеңетін неғұрлым нақты нәрсені орнатады: 0.0.0.0/1 және 128.0.0.0/1 қамтитын жартылай әдепкі жұп — классикалық әдіс, өйткені екеуі де 0.0.0.0/0-ден ұзын префикс және бірге бүкіл кеңістікті қамтиды. Басқалары нақты жеке префикстер мен саясат ережесін орнатады, кейбіреулері тек таңдалған трафик ұсталуы үшін белгі қосады.

Сондықтан "VPN әдепкі маршрутымды өзгерткен жоқ" — сәтсіздіктің дәлелі емес. Оның шын мәнінде не қосқанын және қарастырылып отырған межелі орынның сол префикстердің ішінде екенін тексеріңіз:

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

Екі жартылай маршрутты дампта байқамау оңай, өйткені олар әдепкіге ұқсамайды. Префиксті қосуды ұмытқан split-tunnel конфигурациясы дәл сіз қуып жүрген симптомды тудырады: туннельді пайдалануы тиіс қолданба оның орнына жергілікті түрде шешіп, қосылады. Орнатылған префикстерді пайдаланушыға шынымен қажет межелі орындармен салыстырыңыз, кездейсоқ тексерген мекенжайлармен емес. Файл серверін қамтитын, бірақ оның шешушісін қамтымайтын split-tunnel тізімі қоғамдық мекенжайға шешілетін, содан кейін аутентификациядан өтпейтін қосылымды тудырады, бұл құпиясөз мәселесіне ұқсайды, бірақ маршрут мәселесі.

Сыртқы маршрут та аман қалуы керек

Туннельдің өзі трафик. Инкапсуляцияланған жүкті тасымалдайтын пакеттер физикалық интерфейс арқылы серіктестің мекенжайына барады, және бұл жол туннельге кері маршрутталмауы тиіс. Бұл орын алғанда, туннель орнатылып, содан кейін трафикті өткізуді тоқтататын тән ақау пайда болады, өйткені туннельдің көлігі енді туннельдің ішінде.

Серіктес мекенжайын ішкі межелі орынды тексергендей тексеріңіз және оның туннельге емес, физикалық интерфейске шешілетінін растаңыз:

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

Рекурсивті маршрут, серіктесті ұстайтын саясат ережесі немесе толық туннельдік клиент ауыстырған әдепкі — үш кәдімгі себеп. Үшеуі де сыртқы іздеуде көрінеді, және ешқайсысы фактіден кейін алынған негізгі кесте дампында көрінбейді.

Маршруттау шығысы сізге не айта алмайды

Дұрыс іздеу ядро пакетті қандай да бір ақылға қонымды жерге жіберетінін білдіреді. Бұл firewall рұқсат етеді, IPsec саясаты қамтиды, NAT ережесі аударады немесе қашық жақта қайту маршруты бар дегенді білдірмейді. Олардың әрқайсысы кейінгі кезең, және strongSwan-ның жіберу туралы жазбалары пакет екі ұшта өтуі тиіс шынжырды сипаттайды.

Ол қолданба деңгейіндегі байлауды да есепке алмайды. Процесс интерфейске байлануы, белгі қоюы немесе өз шешушісін пайдаланып, сіз тексергеннен өзгеше шешілетін атаумен қосылуы мүмкін. Іздеу дұрыс болып, қосылым әлі де сәтсіз болса, келесі сұрақ — қай процесс жасап жатқаны және сол процесс сіз көріп отырған кестені көретіні.

Сондықтан диагностиканы ретті ұстаңыз: межелі орын мен көзді атаңыз, іздеуді орындаңыз, тек іздеу атаған кесте мен ережені оқыңыз, содан кейін келесі кезеңді тексеріңіз. Бұл реттілік маршруттау зерттеуін минуттар ішінде ұстайды және басқа біреу қайталай алатын жазба қалдырады, қойылған кесте мұны ешқашан істемейді.