Savienots, zaļa paplātes ikona un lapa, kas atgriež jūsu adresi, joprojām rāda pakalpojumu sniedzēja adresi, taču tas automātiski nenozīmē kļūdu. Klients veic divus atsevišķus darbus: būvē tuneli un rediģē maršrutēšanas tabulu. Jebkurš no tiem var notikt bez otra, un selektīvā maršrutēšana ir tā konfigurācija, kurā otro apzināti izlaiž.

Ko klients patiešām instalēja

Tā vietā, lai jautātu, vai tunelis ir pacelts, jautājiet, kura saskarne nogādās paketi īstajā galamērķī. Tunelis bez maršruta uz šo galamērķi ir privāts ceļš, pa kuru neviens nebrauc.

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

Pirmā komanda atbild uz Linux un macOS, bet pārējās divas ir Windows ekvivalenti, kur pietiek ar vienu. Ja atbildē nosaukts fiziskais adapteris, tunelis ir pacelts un noklusējuma maršruts nekad nav kustējies. Atkārtojiet pārbaudi galamērķim, kuram vajadzētu izmantot tuneli, jo divas pārbaudes, viena tāla un viena parasta, pasaka, kura shēma ir ieviesta.

Trīs selektīvās maršrutēšanas formas

Pilna tuneļa profils parasti ieraksta noklusējuma maršrutu uz saskarni vai ieraksta puspudzes prefiksu pāri, kas uzvar pēc prefiksa garuma, kamēr sākotnējais noklusējums paliek tabulā. Selektīvā maršrutēšana ir otra izvēle, un tā pastāv vairākās formās. Viens profils maršrutē vienu resursdatoru, piemēram, RDP serveri, cits maršrutē publisku diapazonu, kas jāsasniedz no noteiktas vietas, bet trešais apzināti izslēdz vienu lietojumprogrammu. Visi trīs ir likumīgi, un neviens nemaina adresi, ko redz parasta vietne.

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

Lasiet profilu, meklējot izšķirošo direktīvu, un pēc tam tabulu, lai redzētu, ko tā radīja. Iestumto direktīvu var arī apspiest klientā, tāpēc profilam un tabulai jāsakrīt, pirms vainojat serveri.

Otrajai pusei ir jāpārraksta avota adrese

Ir otra kļūme, kas no pārlūka izskatās identiska. Maršruts ved tunelī, serveris saņem paketes un pēc tam pārsūta tās ar neskartu klienta privāto adresi. Nākamajam lēcienam nav atgriešanās ceļa uz šo adresi, tāpēc atbildes pazūd un lapas karājas. Serverim vispār ir jāpārsūta, un tam ir jāiztulko avots kaut kur, ko internets var maršrutēt atpakaļ.

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

Nosauciet saskarni, kas patiešām vērsta pret internetu, un modernā distribūcijā tā ne vienmēr ir eth0. Mitināts serveris ar fiksētu adresi var tieši iztulkot uz šo adresi, nevis izmantot masquerade. Abas puses ir svarīgas, jo pārsūtīšana bez tulkošanas noplūdina nemaršrutējamas adreses, bet tulkošana bez pārsūtīšanas nekad neredz paketi.

Vārdu izšķiršana iet savu ceļu

Satiksme var iziet pa tuneli, kamēr vaicājums, kas atrada vārdu, devās uz lokālā tīkla atrisinātāju. Redzamā adrese paliek tā pati, vaicājumi ne, un tieši šo plaisu izvēlas sadalītā DNS shēma.

resolvectl status | head -20
resolvectl query example.org

Ievērojiet, kurš serveris atbildēja un vai tas atšķiras no bāzes līnijas pirms tuneļa. Sadalītā tunelī tas parasti ir iestatījums, ko cilvēki gribēja mainīt, kad sūdzējās par adresi, un tieši tas, uz ko viņi nekad nepaskatījās.

Četri novērojumi, kas visu izšķir

Fiksējiet izejas adresi ar nolaistu tuneli un pēc tam ar paceltu. Izpildiet galamērķa pārbaudi abos stāvokļos un katru reizi atzīmējiet saskarni.

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

Kad pārbaude nonāk tuneļa iekšpusē un atbalss joprojām rāda pakalpojumu sniedzēja adresi, izejā trūkst tulkojuma. Kad pārbaude nonāk uz fiziskā adaptera, profils ir selektīvs un publiskā adrese nekad nav bijusi spēlē. Nomainiet atbalss pakalpojumu ar tādu, kuram uzticaties, un pierakstiet četrus novērojumus kopā, jo atsevišķi tie ir anekdotes. Kopā tie parāda, kuru no diviem darbiem klients patiešām veica.

Saistītie raksti