Kā nosūtīt vienu IPv4 galamērķi ārpus OpenVPN tuneļa

Lielākā daļa pilna tuneļa konfigurāciju sūta katru paketi caur VPN, un tieši redirect-gateway direktīva to nodrošina. Tomēr vienu galamērķi joprojām var izslēgt. Pievienojot resursdatora maršrutu šai adresei ar net_gateway vietturi, klientam tiek pateikts sasniegt to caur mašīnas sākotnējo vārteju, kamēr viss pārējais turpina izmantot tuneli.

Rinda šķiet nekaitīga, un bieži tā arī ir, taču tā atrisina tikai vienu jautājumu: kur dodas paketes, kas paredzētas tieši šai IPv4 adresei. Tā nemaina DNS, IPv6, ugunsmūra politiku vai to, kurš process atvēra savienojumu, un katrs no tiem var klusi iznīcināt izņēmumu.

Ko net_gateway patiesībā nosauc

Profila ieraksts šim izņēmumam ir viena rinda: route 198.51.100.77 255.255.255.255 net_gateway. Pirmā adrese ir dokumentācijas vietturis galamērķim, maska to pārvērš viena resursdatora maršrutā, un pēdējais marķieris nosauc vārtejas vietturi. OpenVPN atrisina vārtejas vietturus, kad instalē maršrutus. vpn_gateway nozīmē paša tuneļa vārteju, VPN saites tālo pusi. net_gateway nozīmē noklusējuma vārteju, kas resursdatoram bija pirms tam, kad VPN kaut ko mainīja, parasti tas ir vietējais maršrutētājs fiziskajā tīklā.

Trešais vietturis, remote_host, attiecas uz VPN servera adresi, un tas pastāv, lai tunelis varētu sasniegt serveri pa fizisko ceļu. Šo trīs sajaukšana ir visbiežākais iemesls, kāpēc izņēmums nonāk nepareizā vietā vai netiek instalēts vispār.

Vērtība tiek nolasīta savienojuma laikā, nevis ierakstīta failā. Ja mašīna pārceļas uz citu tīklu, vārteja pirms VPN mainās, un maršruts seko jaunajai. Parasti tas ir tas, ko vēlaties, bet tas nozīmē arī to, ka izņēmuma uzvedība ir atkarīga no tīkla, no kura klients sāka.

Kāpēc resursdatora maršruts uzvar tuneļa noklusējumu

Maršrutēšanu nosaka visprecīzākais atbilstošais prefikss. redirect-gateway def1 parasti neaizstāj noklusējuma maršrutu; tas pievieno divas puses, maršrutu adrešu telpas apakšējai pusei un vienu augšējai, tāpēc sākotnējais noklusējuma maršruts tiek saglabāts citiem nolūkiem. Šīs puses ir platākas par vienu adresi.

Maršruts vienai adresei ar masku 255.255.255.255 ir /32, kas ir lielākā precizitāte, ko IPv4 var sasniegt. Kad tiek vērtēta pakete šai adresei, /32 atbilst un uzvar neatkarīgi no tā, kurš maršruts tika instalēts pirmais. Tas ir izņēmuma mehānisms, un tas darbojas vienādi Linux, macOS un Windows, ja vien maršruts patiešām pastāv.

Windows pievieno otru dimensiju. Kad divi maršruti ir vienlīdz precīzi, uzvar tas ar zemāku metriku, un VPN adapterim var būt saskarnes metrika, kas maina rezultātu. /32 joprojām ir precīzāks par pusēm, tāpēc izņēmums parasti saglabājas, bet vecs maršruts no iepriekšējas sesijas var radīt mulsinošu rezultātu, ja tas ir vienlīdz precīzs.

Ko izņēmums neaptver

DNS ir pirmā plaisa. Klients var iespiest iekšējos atrisinātāja iestatījumus, un operētājsistēma turpinās tos izmantot vaicājumiem. Lietotne, kas atrisina vārdu pirms savienošanas, var saņemt iekšēju adresi pakalpojumam, kam vajadzētu iet tieši, vai ārēju adresi, kas tiek atrisināta pareizi, bet pēc tam paklūp uz nākamo plaisu.

IPv6 ir otrā. Maršruta direktīva apstrādā tikai IPv4. Divkāršā steka galamērķis var dot priekšroku IPv6, kas atkarībā no politikas seko tunelim vai resursdatora IPv6 noklusējuma maršrutam, tāpēc IPv4 izņēmums nekad nestājas spēkā. Jums ir vajadzīgs atbilstošs IPv6 maršruts vai apzināts lēmums šim klientam atspējot IPv6.

Lietotņu tvērums ir trešais. Noteikums ir balstīts uz galamērķi, tāpēc katrs process, kas savienojas ar šo adresi, izmanto tiešo ceļu, neatkarīgi no tā, vai tas ir tas, ko jūs domājāt. Un otrādi, vietne var atbildēt no vairākām adresēm, tāpēc vienas /32 izslēgšana neizslēdz vietni. Ja patiesā prasība ir maršrutēšana pēc lietotnes, Community klienta maršrutu tabula ir nepareizais rīks.

Pārbaudīt izņēmumu, nemaldinot sevi

Sāciet ar instalēto maršrutu, nevis pārlūku. Linux vaicājiet kodolam, kuru maršrutu un nākamo lēcienu tas izmantos konkrētajai adresei; Windows izlasiet maršrutu tabulu šai /32. Apstipriniet, ka vārteja ir fiziskā, nevis tunelis. Ja ieraksta nav, profils netika piemērots vai klientam nebija tiesību mainīt maršrutus.

Pēc tam pārbaudiet divus galamērķus. Pieprasījumam uz izslēgto adresi jāiziet caur fizisko saskarni, un pieprasījumam uz iekšējo kontroles adresi joprojām jāizmanto tunelis. Tikai izslēgtās adreses pārbaude neko nepierāda par pārējo tuneli, un publiskas vietnes pārbaude pārbauda adresi, uz kuru šī vietne tika atrisināta, kas var nebūt noteikumā norādītā.

Visbeidzot, pārbaudiet vadīklas, kas var ignorēt maršrutu. Klienta puses kill switch vai Windows iestatījums block-outside-dns var aizliegt tiešu datplūsmu, un tas izpaužas kā savienojums, kas neizdodas, lai gan maršruts ir pareizs. Neizslēdziet šīs vadīklas, lai izņēmums izskatītos kā strādājošs; ja politika aizliedz tiešo ceļu, izņēmums ir projektēšanas problēma VPN pakalpojuma īpašniekam.

Pārbaudiet vēlreiz pēc atkārtotas savienošanas vai tīkla maiņas, jo vārteja pirms VPN un pieejamais ceļš ir momenta īpašības, nevis profila.