Kaip nusiųsti vieną IPv4 paskirties tašką už OpenVPN tunelio

Dauguma pilno tunelio konfigūracijų siunčia kiekvieną paketą per VPN, ir būtent redirect-gateway direktyva tai užtikrina. Vieną paskirties tašką vis tiek galima išskirti. Pridėjus prieglobos maršrutą tam adresui su net_gateway rezervuotos vietos žymekliu, klientui nurodoma pasiekti jį per pradinį įrenginio šliuzą, o visa kita toliau naudoja tunelį.

Eilutė atrodo nekenksminga ir dažnai tokia yra, tačiau ji išsprendžia tik vieną klausimą: kur keliauja paketai, skirti būtent tam IPv4 adresui. Ji nekeičia DNS, IPv6, ugniasienės politikos ar to, kuris procesas atidarė ryšį, ir kiekvienas iš jų gali tyliai panaikinti išimtį.

Ką net_gateway iš tikrųjų įvardija

Tos išimties profilio įrašas yra viena eilutė: route 198.51.100.77 255.255.255.255 net_gateway. Pirmasis adresas yra dokumentacinis rezervuotos vietos žymeklis paskirties taškui, kaukė paverčia jį vieno prieglobos maršrutu, o paskutinis žetonas įvardija šliuzo žymeklį. OpenVPN išsprendžia šliuzo žymeklius, kai įdiegia maršrutus. vpn_gateway reiškia paties tunelio šliuzą, tolimąją VPN ryšio pusę. net_gateway reiškia numatytąjį šliuzą, kurį priegloba turėjo prieš VPN ką nors pakeičiant, paprastai tai vietinis maršrutizatorius fiziniame tinkle.

Trečiasis žymeklis, remote_host, nurodo VPN serverio adresą, ir jis egzistuoja tam, kad tunelis galėtų pasiekti serverį fiziniu keliu. Šių trijų painiojimas yra dažniausia priežastis, kodėl išimtis patenka ne ten, kur reikia, arba visai neįdiegiama.

Reikšmė nuskaitoma jungiantis, o ne įrašoma į failą. Jei įrenginys persikelia į kitą tinklą, šliuzas prieš VPN pasikeičia, o maršrutas seka naująjį. Paprastai to ir norite, tačiau tai taip pat reiškia, kad išimties elgsena priklauso nuo tinklo, iš kurio klientas pradėjo.

Kodėl prieglobos maršrutas nugali numatytąjį tunelio maršrutą

Maršrutizavimą lemia tiksliausias atitinkantis priešdėlis. redirect-gateway def1 paprastai nepakeičia numatytojo maršruto; jis prideda dvi puses, maršrutą apatinei adresų erdvės pusei ir vieną viršutinei, todėl pradinis numatytasis maršrutas išlieka kitiems tikslams. Tos pusės yra platesnės už vieną adresą.

Vieno adreso maršrutas su kauke 255.255.255.255 yra /32, tai didžiausias IPv4 tikslumas. Kai vertinamas tam adresui skirtas paketas, /32 atitinka ir laimi nepriklausomai nuo to, kuris maršrutas buvo įdiegtas pirmas. Tai yra išimties mechanizmas, ir jis veikia taip pat Linux, macOS ir Windows sistemose, kol maršrutas tikrai egzistuoja.

Windows prideda antrą dimensiją. Kai du maršrutai yra vienodai tikslūs, laimi tas, kurio metrika mažesnė, o VPN adapteris gali turėti sąsajos metriką, kuri pakeičia rezultatą. /32 vis tiek yra tikslesnis už puses, todėl išimtis paprastai išlieka, tačiau pasenęs maršrutas iš ankstesnės sesijos gali duoti klaidinančią rezultatą, jei jis vienodai tikslus.

Ko išimtis neapima

DNS yra pirmoji spraga. Klientas gali perstumti vidines rezolverio nuostatas, ir operacinė sistema toliau jas naudos užklausoms. Programa, kuri išsprendžia vardą prieš prisijungdama, gali gauti vidinį adresą paslaugai, kuri turėtų eiti tiesiogiai, arba išorinį adresą, kuris išsprendžiamas teisingai, bet po to užkliūva už kitos spragos.

IPv6 yra antroji. Maršruto direktyva tvarko tik IPv4. Dvigubo steko paskirties taškas gali teikti pirmenybę IPv6, kuris pagal politiką seka tunelį arba prieglobos IPv6 numatytąjį maršrutą, todėl IPv4 išimtis niekada neįsigalioja. Jums reikia atitinkančio IPv6 maršruto arba sąmoningo sprendimo išjungti IPv6 tam klientui.

Programų aprėptis yra trečioji. Taisyklė pagrįsta paskirties tašku, todėl kiekvienas procesas, jungiantis prie to adreso, naudoja tiesioginį kelią, nesvarbu, ar tai tas procesas, kurį turėjote omenyje. Ir atvirkščiai, svetainė gali atsakyti iš kelių adresų, todėl vieno /32 išskyrimas neišskiria visos svetainės. Jei tikrasis reikalavimas yra maršrutizavimas pagal programas, Community kliento maršrutų lentelė yra netinkamas įrankis.

Patikrinti išimtį neapgaunant savęs

Pradėkite nuo įdiegto maršruto, o ne nuo naršyklės. Linux sistemoje paklauskite branduolio, kokį maršrutą ir kitą šuolį jis naudos konkrečiam adresui; Windows sistemoje perskaitykite maršrutų lentelę tam /32. Patvirtinkite, kad šliuzas yra fizinis, o ne tunelis. Jei įrašo nėra, profilis nebuvo pritaikytas arba klientas neturėjo teisės keisti maršrutų.

Tada išbandykite du paskirties taškus. Užklausa išskirtam adresui turėtų išeiti per fizinę sąsają, o užklausa valdymo vidiniam adresui turėtų vis dar naudoti tunelį. Tik išskirto adreso tikrinimas nieko neįrodo apie likusį tunelį, o viešos svetainės tikrinimas tikrina adresą, į kurį ta svetainė išspręsta, kuris gali būti ne tas, kuris nurodytas taisyklėje.

Galiausiai patikrinkite valdiklius, kurie gali viršyti maršrutą. Kliento pusės kill switch arba Windows nuostata block-outside-dns gali uždrausti tiesioginį srautą, ir tai pasireiškia kaip ryšys, kuris nepavyksta, nors maršrutas yra teisingas. Neišjunkite tų valdiklių, kad išimtis atrodytų veikianti; jei politika draudžia tiesioginį kelią, išimtis yra projektavimo problema VPN paslaugos savininkui.

Patikrinkite dar kartą po prisijungimo iš naujo ar tinklo pakeitimo, nes šliuzas prieš VPN ir galimas kelias yra akimirkos savybės, o ne profilio.