Екі VPN пулы үшін көз бойынша маршруттау: ережеңіз нені өткізіп жібереді
from түріндегі ереже SNAT оны қайта жазбай тұрып клиент мекенжайына сәйкес келеді, ал шлюзден жасалған тест екеуіне де сәйкес келмейді. Іздеуді әр пул үшін орындаңыз және оның орнына басымдықтарды оқыңыз.
Екі клиент пулы, бір шлюз және жоспар қарапайым көрінеді: бір ереже бірінші пулды жылдам жоғары арна арқылы шығарады, екіншісі екінші пулды серіктес туннелі арқылы жібереді. Содан кейін ережелер орнында, ал екінші пул әлі де әдепкі маршрут арқылы шығады. Ереже бұзылмаған. Пакеттің көзі — іздеу сәтінде автор күткен нәрсе емес, өйткені аудару мен іздеу бір пакеттің жолының әртүрлі нүктелерінде болады, ал рет көпшілік салатын ой диаграммасына кері.
Іздеу көз қайта жазылмай тұрып орындалады
VPN клиентінен жіберілетін пакет үшін ядро белгілі бір реттілікті орындайды. Ол туннель интерфейсіне келеді, conntrack пен DNAT тұратын prerouting-тен өтеді, содан кейін маршруттау шешімі қабылданады, содан кейін жіберу, содан кейін SNAT ең соңында қолданылатын postrouting. from түріндегі ереже сол маршруттау шешімі кезінде қаралады, яғни ол клиенттің бастапқы мекенжайын көреді, аударылғанын емес.
Сондықтан masquerade ережесін қосу шығыс ағынына қай саясат сәйкес келетінін өзгертпейді. Өзгеретіні — алыс жақтың не көретіні, демек қандай қайтару жолы бар екені. Бұл екі түрлі салдар, және өзгерістерді қарау оларды үнемі шатастырады. Оларды бөліңіз, сонда дизайн әдетте бір минут ішінде айқын болады.
Аударылған мекенжай ережелерде жауап бағытында көрінеді. Шлюзге қайтатын пакет аударылған мекенжайға адрестеледі, ал егер мақсатқа немесе ол кірген интерфейске байланған саясат ережелеріңіз болса, сіз дәл сол мәнді сәйкестендіресіз. Бір байланыс, әр бағытта шындықтың өзге көзі.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
Осылайша көздері әртүрлі екі пулға шынымен әртүрлі кестелер қажет, ал дизайн дұрыс. Жоғарыдағы кесте жоққа шығаратын нәрсе — алыс сайттың не алғанын қарап, одан ережені қорытып шығаратын оңай жол.
Шлюзден жасалған тест пулдың тесті емес
Шлюздің өзі жасайтын трафик ешқашан prerouting-тен өтпейді, өйткені ол интерфейске келмеген. Ол шығыс жолында маршрутталады, көзі ретінде шлюздің өз мекенжайы алынады, ал клиент ауқымына байланған from ережесі сәйкес келмейді. Бұл саладағы қораптан жұмыс істейді, клиенттен істемейді деген әрбір тикет — сол фактінің қайталануы.
Клиентті болжаудың орнына оны имитациялаңыз. Маршруттау іздеуін тікелей сұрауға болады, көз бен кіру интерфейсін беріп:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201Оны әр пул үшін бір рет орындаңыз. Егер екі команда бірдей интерфейс қайтарса, ережелер пулдарды бөлмейді, ал себебі — жетіспейтін ереже немесе екеуіне де сәйкес келетін жоғары басымдықты ереже. Егер олар әртүрлі интерфейстер қайтарса, бірақ клиент әлі сәтсіз болса, ақау іздеуден кейін және ережелерді қарауды тоқтатуға болады.
Басымдық, файлдағы орын емес
Ережелер басымдықтың өсу ретімен бағаланады, маңыздысы — сан, сіз терген рет емес. local кестесі 0 басымдықта, main кестесі 32766-да, әдепкі ереже 32767-де, сондықтан әдепкі басымдықпен қосылған ереже тізімнің соңына таяу түседі де, барлығына дерлік ұтылады.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201Айқын басымдық көзделген ретті файлда және қарау кезінде көрінетін етеді. Ол сондай-ақ кейінгі қосымшаның бар ереженің алдына үнсіз секіруіне жол бермейді, бұл — жұмыс істеп тұрған саясаттың қатыссыз өзгерістен кейін тоқтауының ең жиі себебі.
Толық емес кестеге сілтейтін сәйкес ереже — екінші тұзақ. Егер 201 кестесінде әдепкі маршрут болса, бірақ мақсатқа маршрут болмаса, пакет тасталады немесе дұрыс емес жерге жіберіледі, ал ереже оқшау түрде мүлдем дұрыс көрінеді. Ережені емес, кестені оқыңыз. Ереже — сілтеме, ал бос кесте — ешқайдағы сілтеме.
Қайтару жолы әлі де болуы керек
Көз саясаты шығуды таңдайды. Ол қайтару жолын жасамайды. Егер екінші пул серіктес туннелінен шықса, серіктес 172.31.8.0/24-ке қалай жетуді білуі керек, не шлюзге қайтатын маршрутпен, не өзі бұрыннан білетін аударылған мекенжайларды алумен.
Осылардың арасында таңдау — көрінетін салдары бар дизайн шешімі. Клиент ауқымын кері маршруттау серіктесте әр клиенттің жеке басын сақтайды және оның сіздің префиксіңізді қабылдауын талап етеді. Аудару пулды бір мекенжайдың артына жасырады және серіктес тек сол мекенжайды қабылдауын талап етеді, соның құны — сіздің және оның журналдары кім қосылғаны туралы енді келіспейді.
Не таңдасаңыз да, оны пул анықтамасының жанына жазыңыз. Тек біреудің жадында ғана бар қайтару маршруты — серіктес фаерволды ауыстырғанша өмір сүретін, содан кейін қалпына келтіруге бір күн кететін дәл сол нәрсе.
Саясатта шлюздің өз туннелін ұстап алмаңыз
Клиенттер үшін жазатын ережелер шлюз жасайтын трафикке де қолданылады, егер оны шығарып тастамасаңыз. Белгіге немесе шығыс интерфейске байланған кең ереже шлюздің серіктеспен өз байланысын ұстап қалуы мүмкін, сонда саясатты тасымалдайтын туннель саясатпен маршрутталады. Бұл провайдер ақауына ұқсайтын цикл немесе үзіліс тудырады.
Әр ережені дизайн рұқсат еткенше тарылтыңыз: көз префиксі, кіру интерфейсі және қолдау болса, тек клиент пакеттері таситын белгі. Содан кейін әр ереже өзгерісінен кейін шлюздің өз байланысын тексеріңіз, өйткені ақау өзіне сілтеме жасайды және клиент тестінде көрінбейді.
ip-rule нұсқаулығының беті селектор мен басымдықтың семантикасын құжаттайды. Оны әр пулдың іздеу тестімен қосыңыз, сонда дизайн тексерілетін болады, бұл — бір жыл шыдайтын саясаттық маршруттау мен бәрі ұстауға қорқатын маршруттаудың айырмашылығы.