Жашыл белги, ошол эле коомдук 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

Текшерүү туннелдин ичине түшкөндө жана чагылдыруу дагы эле провайдердин дарегин көрсөтсө, чыгууда которуу жок. Текшерүү физикалык адаптерге түшкөндө профиль тандама жана коомдук дарек эч качан оюнда болгон эмес. Чагылдыруу кызматын ишенген кызматыңыз менен алмаштырып, төрт байкоону чогуу жазыңыз, анткени өзүнчө алар анекдот. Чогуу алар клиент эки иштин кайсынысын чындыгында аткарганын көрсөтөт.