Бір IPv4 межелісін OpenVPN туннелінен тыс жіберу жолы
net_gateway арқылы бір хост маршруты бір IPv4 мекенжайын OpenVPN туннелінен тыс жібере алады. Келесі секірісті, DNS ауқымын, IPv6 және клиенттің кез келген бұғаттауын тексеріңіз.
Толық туннель конфигурацияларының көбі әр пакетті VPN арқылы жібереді, және redirect-gateway директивасы осыны мүмкін етеді. Бір ғана межелісті бәрібір ерекшелеуге болады. Сол мекенжай үшін net_gateway орнын толтырғышымен хост маршрутын қосу клиентке оған машинаның бастапқы шлюзі арқылы жетуді айтады, ал қалғаны туннельді пайдалануды жалғастырады.
Жол қауіпсіз көрінеді және жиі солай, бірақ ол тек бір сұрақты шешеді: дәл сол IPv4 мекенжайына арналған пакеттер қайда барады. Ол DNS, IPv6, брандмауэр саясаты немесе қай процесс қосылымды ашқанын өзгертпейді, және осылардың әрқайсысы ерекшелікті үнсіз жоюы мүмкін.
net_gateway шын мәнінде нені атайды
Бұл ерекшелік үшін профиль жазбасы бір жол: route 198.51.100.77 255.255.255.255 net_gateway. Бірінші мекенжай межеліс үшін құжаттамалық орнын толтырғыш, маска оны бір хосттың маршрутына айналдырады, ал соңғы токен шлюздің орнын толтырғышын атайды. OpenVPN маршруттарды орнату кезінде шлюз орнын толтырғыштарын шешеді. vpn_gateway туннельдің өз шлюзін, яғни VPN байланысының алыс жағын білдіреді. net_gateway VPN бірдеңені өзгертпей тұрып хостта болған әдепкі шлюзді білдіреді, ол әдетте физикалық желідегі жергілікті маршрутизатор.
Үшінші орнын толтырғыш, remote_host, VPN серверінің мекенжайын білдіреді және туннель серверге физикалық жолмен жете алуы үшін бар. Осы үшеуін шатастыру — ерекшеліктің қате жерге кетуінің немесе мүлде орнатылмауының ең көп тараған себебі.
Мән қосылу сәтінде оқылады, файлға жазылмайды. Егер машина басқа желіге көшсе, VPN-ге дейінгі шлюз өзгереді және маршрут жаңасына ереді. Бұл әдетте қалағаныңыз, бірақ ерекшеліктің әрекеті клиент бастаған желіге тәуелді екенін де білдіреді.
Неге хост маршруты туннельдің әдепкі маршрутынан басым
Маршруттау ең нақты сәйкес префикспен анықталады. redirect-gateway def1 әдетте әдепкі маршрутты алмастырмайды; ол екі жарты қосады, мекенжай кеңістігінің төменгі жартысына маршрут және жоғарғы жартысына тағы бірі, сондықтан бастапқы әдепкі маршрут басқа мақсаттар үшін сақталады. Бұл жартылар бір мекенжайдан кеңірек.
255.255.255.255 маскасы бар бір мекенжайға арналған маршрут /32 болып табылады, бұл IPv4 жете алатын ең нақты дәреже. Сол мекенжайға арналған пакет бағаланғанда /32 сәйкес келеді және қай маршрут бірінші орнатылғанына қарамастан жеңеді. Бұл ерекшеліктің артындағы механизм, және маршрут шынымен бар болса, Linux, macOS және Windows жүйелерінде бірдей жұмыс істейді.
Windows екінші өлшемді қосады. Екі маршрут бірдей нақты болса, метрикасы төменірек жеңеді, ал VPN адаптері нәтижені өзгертетін интерфейс метрикасын алып жүруі мүмкін. /32 жартылардан әлі де нақтырақ, сондықтан ерекшелік әдетте сақталады, бірақ бұрынғы сессиядан қалған ескі маршрут бірдей нақты болса, шатастыратын нәтиже беруі мүмкін.
Ерекшелік нені қамтымайды
DNS — бірінші олқылық. Клиент ішкі шешуші параметрлерін итеруі мүмкін, және операциялық жүйе оларды сұраулар үшін пайдалануды жалғастырады. Қосылу алдында атауды шешетін қолданба тікелей жүруі тиіс қызмет үшін ішкі мекенжайды немесе дұрыс шешілетін, бірақ кейін келесі олқылыққа сүрінетін сыртқы мекенжайды алуы мүмкін.
IPv6 — екіншісі. Маршрут директивасы тек IPv4-пен жұмыс істейді. Қос стекті межеліс IPv6-ны таңдауы мүмкін, ол саясатқа байланысты туннельді немесе хосттың IPv6 әдепкі маршрутын ұстанады, сондықтан IPv4 ерекшелігі ешқашан күшіне енбейді. Сізге сәйкес IPv6 маршруты немесе сол клиент үшін IPv6-ны өшіру туралы саналы шешім қажет.
Қолданба ауқымы — үшіншісі. Ереже межеліске негізделген, сондықтан сол мекенжайға қосылатын әр процесс тікелей жолды пайдаланады, ол көздеген процесіңіз болсын немесе болмасын. Керісінше, веб-сайт бірнеше мекенжайдан жауап бере алады, сондықтан бір /32-ні ерекшелеу сайтты ерекшелемейді. Егер нақты талап қолданба бойынша маршруттау болса, Community клиентінің маршрут кестесі қате құрал.
Өзіңізді алдамай ерекшелікті тексеру
Браузерден емес, орнатылған маршруттан бастаңыз. Linux-те ядродан нақты мекенжай үшін қай маршрут пен келесі секірісті пайдаланатынын сұраңыз; Windows-та сол /32 үшін маршрут кестесін оқыңыз. Шлюздің туннель емес, физикалық екеніне көз жеткізіңіз. Егер жазба жоқ болса, профиль қолданылмаған немесе клиенттің маршруттарды өзгертуге құқығы болмаған.
Содан кейін екі межелісті сынаңыз. Ерекшеленген мекенжайға сұрау физикалық интерфейстен шығуы керек, ал бақылау ішкі мекенжайына сұрау әлі де туннельді пайдалануы керек. Тек ерекшеленген мекенжайды сынау туннельдің қалғаны туралы ештеңе дәлелдемейді, ал ашық веб-сайтты сынау сол сайт шешілген мекенжайды сынайды, ол ережедегі мекенжай болмауы мүмкін.
Соңында, маршруттан асып түсуі мүмкін басқару элементтерін тексеріңіз. Клиент жағындағы kill switch немесе Windows-тың block-outside-dns параметрі тікелей трафикті тыйым сала алады, бұл маршрут дұрыс болса да сәтсіздікке ұшыраған қосылым ретінде көрінеді. Ерекшелік жұмыс істеп тұрғандай көрінуі үшін бұл элементтерді өшірмеңіз; егер саясат тікелей жолды тыйым салса, ерекшелік VPN қызметінің иесі үшін дизайн мәселесі.
Қайта қосылғаннан немесе желі ауысқаннан кейін қайта тексеріңіз, себебі VPN-ге дейінгі шлюз бен қолжетімді жол — сәттің қасиеттері, профильдің емес.