Жасыл белгіше, сол қоғамдық IP: VPN қай маршрутты өткізіп жіберді
Науа белгішесі туннель туралы хабарлайды, әдепкі маршрут туралы емес. Төрт тексеру клиент маршрутты орнатты ма, әлде шығу сіздің көзіңізді ешқашан аудармады ма, соны көрсетеді.
Қосылған, науадағы белгіше жасыл, ал мекенжайды көрсететін бет әлі де провайдердің мекенжайын көрсетіп тұр, бірақ бұл автоматты түрде ақау дегенді білдірмейді. Клиент екі бөлек жұмыс істейді: туннель салады және маршруттау кестесін өңдейді. Екеуінің кез келгені екіншісіз болуы мүмкін, ал таңдамалы маршруттау дегеніміз екіншісі әдейі өткізіп жіберілетін конфигурация.
Клиент шын мәнінде нені орнатты
Туннель көтерілді ме деп сұраудың орнына, пакетті нақты межеге қай интерфейс апаратынын сұраңыз. Сол межеге маршруты жоқ туннель дегеніміз ешкім жүрмейтін жеке жол.
ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4Бірінші команда Linux пен macOS-та жауап береді, ал қалған екеуі Windows-тегі баламалар, онда біреуі жеткілікті. Егер жауап физикалық адаптерді атаса, туннель көтерілген және әдепкі маршрут ешқашан жылжымаған. Туннельді пайдалануы тиіс меже үшін тексеруді қайталаңыз, өйткені екі тексеру, бірі алыс және бірі қарапайым, қай дизайн орнатылғанын айтады.
Таңдамалы маршруттаудың үш түрі
Толық туннель профилі әдетте интерфейске қарайтын әдепкі маршрутты жазады, немесе префикс ұзындығы бойынша жеңетін жарты ауқымды префикстер жұбын жазады, ал бастапқы әдепкі кестеде қалады. Таңдамалы маршруттау басқа таңдау және ол бірнеше түрде кездеседі. Бір профиль RDP сервері сияқты жалғыз хостты маршруттайды, екіншісі белгілі бір жерден жету қажет қоғамдық ауқымды, ал үшіншісі бір қосымшаны әдейі шығарып тастайды. Үшеуі де заңды және ешқайсысы кәдімгі сайт көретін мекенжайды өзгертпейді.
grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20Шешетін директива үшін профильді, содан кейін ол нені өндіргенін білу үшін кестені оқыңыз. Итерілген директиваны клиентте де басуға болады, сондықтан серверді кінәламас бұрын профиль мен кесте сай болуы керек.
Арғы жақ бастау мекенжайын қайта жазуы керек
Браузерден бірдей көрінетін екінші ақау бар. Маршрут туннельге кіреді, сервер пакеттерді қабылдайды, содан кейін оларды клиенттің жеке мекенжайымен бүлінбей жібереді. Келесі секірістің сол мекенжайға қайту жолы жоқ, сондықтан жауаптар жоғалады және беттер ілінеді. Сервер тым болмаса жіберуі керек және бастауды интернет кері маршруттай алатын нәрсеге айналдыруы керек.
sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADEШын мәнінде интернетке қарайтын интерфейсті атаңыз, бұл қазіргі дистрибутивте әрдайым eth0 бола бермейді. Тұрақты мекенжайы бар хостинг сервері masquerade орнына тікелей сол мекенжайға аудара алады. Екі жарты да маңызды, өйткені аудармасыз жіберу маршрутталмайтын бастауларды ағызады, ал жіберусіз аударма пакетті ешқашан көрмейді.
Атауларды шешу өз жолымен жүреді
Атауды тапқан тексеру жергілікті желідегі шешушіге барған кезде трафик туннельден шығуы мүмкін. Көрінетін мекенжай сол күйінде қалады, тексерулер олай емес, және дәл осы алшақтықты бөлінген DNS дизайны таңдайды.
resolvectl status | head -20
resolvectl query example.orgҚай сервер жауап бергенін және ол туннельге дейінгі базалық сызықтан өзгеше ме, соны байқаңыз. Бөлінген туннельде бұл әдетте адамдар мекенжайға шағымданғанда өзгерткісі келген параметр, әрі олар ешқашан қарамаған параметр.
Мәселені шешетін төрт байқау
Туннель өшірулі кезде шығу мекенжайын жазып алыңыз, содан кейін қосулы кезде. Екі күйде де меже тексеруін орындап, әр жолы интерфейсті белгілеңіз.
curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9Тексеру туннельдің ішіне түскенде және көрініс әлі де провайдердің мекенжайын көрсетсе, шығуда аударма жоқ. Тексеру физикалық адаптерге түскенде профиль таңдамалы және қоғамдық мекенжай ешқашан ойында болмаған. Көрініс қызметін сенетін қызметпен ауыстырып, төрт байқауды бірге жазыңыз, өйткені жеке-жеке олар анекдот. Бірге олар клиенттің екі жұмыстың қайсысын шын мәнінде орындағанын көрсетеді.