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

Алдымен қонақтың қосылымын жазып алыңыз

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

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

Қонақтың соңғы нүктесін сыртқа қарай қадағалаңыз

Қонақ VPN-іне басқа нәрсе жұмыс істеуінен бұрын өз серверіне жарамды жол қажет. Хосттың туннелі қосылып, қонақ NAT артында отырғанда, қонақтың қол алысуы хосттың туннелі арқылы шығады, бұл не жоба, не ешкім құжаттамаған оқиға. Хосттың туннелі түсіп, қонақ соған тәуелді болса, қонақ өз жағында бірде-бір өзгеріссіз байланысын жоғалтады. Соңғы нүктені сыртқа қарай қадағалау осы екеуінің қайсысы шынымен сізде екенін айтады.

Кез келген контексте кең маршрут екінші клиент күткен трафикті ұстап қалады. Қонақтың ішіндегі 0.0.0.0/0 маршруты мен толық туннельді хост клиенті екеуі де бәріне таласады, ал соңында қолданылғаны жеңеді. Қонақтың виртуалды желілері, жергілікті LAN және қашықтағы желілер арасындағы қабаттасу жеке префикстер үшін бірдей әсер береді, ақаулар аутентификация мәселелеріне ұқсайды; мекенжайларды аудару мінез-құлқы контейнерлер желісі үшін сипатталғанмен бірдей.

Алдыңғы және кейінгі жазбаны салыстырыңыз

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

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

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

Қайта жүктеулер арасында меншікті анық ұстаңыз

Хост клиентінің жергілікті қатынас шектеуі виртуалды NAT-қа немесе көпірге трафикті бөгеуі мүмкін, және бұл шектеу жиі қонақтың тіркелгі деректерінің мәселесімен шатастырылады. Тест өтуі үшін шектеуді өшірудің орнына клиенттің құжатталған мінез-құлқын оқыңыз. Қолдау көрсетілген түзетуден кейін қонақ қолданбасын және өзіңіз талап ететін ақау саясатын қайта тексеріңіз. Сәтті қайта қосылған хост қонақтың маршруты немесе шешушісі туралы ештеңе дәлелдемейді.

Әдепкі маршруттың қай тарапқа тиесілі екенін шешіп, оны пайдалану нұсқаулығына жазыңыз. Қонақтың қайта жүктелуі немесе хосттағы желінің ауысуы меншікті үнсіз төңкерсе, ешқашан кінәлі болмаған VPN туралы қате есебі пайда болады. Реттеу қайта жүктеуден кейін де сақталуы керек, ешкім оның неге жұмыс істегенін есіне алмай-ақ.

Қатысты мақалалар