Žalia piktograma, tas pats viešas IP: kurį maršrutą VPN praleido

Prisijungta, žalia dėklės piktograma, o adresą atspindintis puslapis vis dar rodo tiekėjo adresą, bet tai automatiškai nereiškia gedimo. Klientas atlieka du atskirus darbus: stato tunelį ir redaguoja maršrutų lentelę. Bet kuris gali įvykti be kito, o selektyvusis maršrutizavimas yra ta konfigūracija, kurioje antrasis sąmoningai praleidžiamas.

Ką klientas iš tikrųjų įdiegė

Užuot klausę, ar tunelis pakeltas, paklauskite, kuri sąsaja nuneštų paketą į tikrą paskirties vietą. Tunelis be maršruto į tą vietą yra privatus kelias, kuriuo niekas nevažiuoja.

ip route get 9.9.9.9
Find-NetRoute -RemoteIPAddress 9.9.9.9
route print -4

Pirmoji komanda atsako Linux ir macOS, o kitos dvi yra Windows atitikmenys, kur pakanka vienos. Jei atsakyme nurodytas fizinis adapteris, tunelis pakeltas ir numatytasis maršrutas niekada nejudėjo. Pakartokite patikrinimą paskirties vietai, kuri turėtų naudotis tuneliu, nes du patikrinimai, vienas tolimas ir vienas įprastas, pasako, kuri schema įdiegta.

Trys selektyviojo maršrutizavimo formos

Viso tunelio profilis paprastai įrašo numatytąjį maršrutą į sąsają arba įrašo pusės diapazono priešdėlių porą, kuri laimi pagal priešdėlio ilgį, o pradinis numatytasis lieka lentelėje. Selektyvusis maršrutizavimas yra kitas pasirinkimas, ir jis būna kelių formų. Vienas profilis maršrutizuoja vieną hostą, pavyzdžiui, RDP serverį, kitas – viešą diapazoną, kurį reikia pasiekti iš tam tikros vietos, o trečias sąmoningai išskiria vieną programą. Visi trys yra teisėti, ir nė vienas nekeičia adreso, kurį mato įprasta svetainė.

grep -nE "redirect-gateway|route-nopull|route " /etc/openvpn/client/*.conf
ip route show table main | head -20

Skaitykite profilį ieškodami sprendžiančios direktyvos, o paskui lentelę – ką ji pagimdė. Stumiamą direktyvą galima ir nuslopinti kliente, todėl profilis ir lentelė turi sutapti, prieš kaltinant serverį.

Kita pusė turi perrašyti šaltinio adresą

Yra antras gedimas, kuris iš naršyklės atrodo identiškai. Maršrutas veda į tunelį, serveris gauna paketus ir tada persiunčia juos su nepažeistu privačiu kliento adresu. Kitas šuolis neturi grįžimo kelio tam adresui, todėl atsakymai dingsta ir puslapiai stringa. Serveris turi apskritai persiųsti ir turi išversti šaltinį į tai, ką internetas gali maršrutizuoti atgal.

sysctl net.ipv4.ip_forward
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -S | grep MASQUERADE

Įvardykite sąsają, kuri iš tikrųjų žiūri į internetą, o tai moderniame platinime ne visada eth0. Nuomojamas serveris su fiksuotu adresu gali aiškiai išversti į tą adresą vietoj masquerade. Abi pusės svarbios, nes persiuntimas be vertimo nutekina nemaršrutizuojamus šaltinius, o vertimas be persiuntimo niekada nemato paketo.

Vardų skyrimas eina savo keliu

Srautas gali išeiti per tunelį, kol vardą radęs patikrinimas nuėjo į vietinio tinklo sprendėją. Matomas adresas lieka tas pats, patikrinimai – ne, ir būtent šį tarpą pasirenka skaidytas DNS sprendimas.

resolvectl status | head -20
resolvectl query example.org

Atkreipkite dėmesį, kuris serveris atsakė ir ar jis skiriasi nuo bazinės linijos prieš tunelį. Skaidytame tunelyje tai paprastai tas nustatymas, kurį žmonės norėjo pakeisti skųsdamiesi adresu, ir būtent tas, į kurį jie niekada nepažiūrėjo.

Keturi stebėjimai, kurie išsprendžia klausimą

Užfiksuokite išėjimo adresą su nuleistu tuneliu, paskui su pakeltu. Paleiskite paskirties patikrinimą abiem būsenomis ir kiekvieną kartą pažymėkite sąsają.

curl -sS https://ifconfig.me/ip
ip route get 9.9.9.9

Kai patikrinimas patenka į tunelį, o atspindys vis dar rodo tiekėjo adresą, išėjime trūksta vertimo. Kai patikrinimas patenka ant fizinio adapterio, profilis yra selektyvus ir viešas adresas niekada nebuvo žaidime. Pakeiskite atspindžio tarnybą tokia, kuria pasitikite, ir užrašykite keturis stebėjimus kartu, nes atskirai jie yra anekdotai. Kartu jie parodo, kurį iš dviejų darbų klientas iš tikrųjų atliko.