Si të dërgoni një destinacion IPv4 jashtë një tuneli OpenVPN
Një rrugë e vetme pritësi përmes net_gateway mund të dërgojë një adresë IPv4 jashtë një tuneli OpenVPN. Verifikoni hopin tjetër, shtrirjen e DNS, IPv6 dhe çdo bllokim të klientit.
Shumica e konfigurimeve të tunelit të plotë dërgojnë çdo paketë përmes VPN, dhe direktiva redirect-gateway është ajo që e bën të mundur. Një destinacion i vetëm mund të përjashtohet gjithsesi. Shtimi i një rruge pritësi për atë adresë me mbajtësin e vendit net_gateway i thotë klientit ta arrijë përmes portës origjinale të makinës, ndërsa gjithçka tjetër vazhdon të përdorë tunelin.
Rreshti duket i pafajshëm dhe shpesh është i tillë, por zgjidh vetëm një pyetje: ku shkojnë paketat për atë adresë të saktë IPv4. Nuk ndryshon DNS, IPv6, politikën e firewall-it apo cili proces e hapi lidhjen, dhe secili prej tyre mund ta anulojë përjashtimin në heshtje.
Çfarë emërton në të vërtetë net_gateway
Zëri i profilit për atë përjashtim është një rresht: route 198.51.100.77 255.255.255.255 net_gateway. Adresa e parë është mbajtëse dokumentacioni për destinacionin, maska e kthen atë në një rrugë pritësi të vetëm, dhe shenja e fundit emërton mbajtësin e portës. OpenVPN zgjidh mbajtësit e portës kur instalon rrugët. vpn_gateway nënkupton portën e vetë tunelit, anën e largët të lidhjes VPN. net_gateway nënkupton portën e parazgjedhur që pritësi kishte para se VPN të ndryshonte gjithçka, e cila zakonisht është ruteri lokal në rrjetin fizik.
Një mbajtëse e tretë, remote_host, i referohet adresës së serverit VPN, dhe ekziston që tuneli të mund të arrijë serverin përmes rrugës fizike. Ngatërrimi i këtyre të treve është arsyeja më e zakonshme që një përjashtim shkon në vendin e gabuar ose nuk instalohet fare.
Vlera lexohet në momentin e lidhjes, nuk shkruhet në skedar. Nëse makina kalon në një rrjet tjetër, porta para VPN ndryshon dhe rruga ndjek atë të re. Kjo është zakonisht ajo që dëshironi, por do të thotë gjithashtu që sjellja e përjashtimit varet nga rrjeti nga i cili klienti filloi.
Pse një rrugë pritësi mund portën e parazgjedhur të tunelit
Rrugëtimi vendoset nga prefiksi përputhës më specifik. redirect-gateway def1 zakonisht nuk e zëvendëson rrugën e parazgjedhur; shton dy gjysma, një rrugë për gjysmën e poshtme të hapësirës së adresave dhe një për gjysmën e sipërme, kështu që rruga origjinale e parazgjedhur ruhet për përdorime të tjera. Këto gjysma janë më të gjera se një adresë e vetme.
Një rrugë për një adresë me maskë 255.255.255.255 është një /32, që është specifikimi maksimal që IPv4 mund të japë. Kur vlerësohet një paketë për atë adresë, /32 përputhet dhe fiton pavarësisht se cila rrugë u instalua e para. Ky është mekanizmi pas përjashtimit, dhe funksionon njësoj në Linux, macOS dhe Windows për sa kohë rruga është vërtet e pranishme.
Windows shton një dimension të dytë. Kur dy rrugë janë njësoj specifike, fiton ajo me metrikë më të ulët, dhe një përshtatës VPN mund të mbajë një metrikë ndërfaqeje që ndryshon rezultatin. Një /32 mbetet më specifike se gjysmat, kështu që përjashtimi zakonisht qëndron, por një rrugë e vjetër nga një sesion i mëparshëm mund të japë një rezultat konfuz nëse është njësoj specifike.
Çfarë nuk mbulon përjashtimi
DNS është boshllëku i parë. Klienti mund të shtyjë cilësime të brendshme të zgjidhësit, dhe sistemi operativ do të vazhdojë t'i përdorë ato për kërkime. Një aplikacion që zgjidh një emër para se të lidhet mund të marrë një adresë të brendshme për një shërbim që duhet të shkojë direkt, ose një adresë të jashtme që zgjidhet saktë por më pas pengohet në boshllëkun tjetër.
IPv6 është i dyti. Direktiva e rrugës trajton vetëm IPv4. Një destinacion me stivë të dyfishtë mund të preferojë IPv6, i cili sipas politikës ndjek tunelin ose rrugën e parazgjedhur IPv6 të pritësit, kështu që përjashtimi IPv4 nuk hyn kurrë në fuqi. Ju nevojitet një rrugë IPv6 përputhëse, ose një vendim i qëllimshëm për të çaktivizuar IPv6 për atë klient.
Shtrirja e aplikacioneve është e treta. Rregulli bazohet në destinacion, kështu që çdo proces që lidhet me atë adresë përdor rrugën direkte, qoftë ai që kishit në mendje apo jo. Anasjelltas, një faqe interneti mund të përgjigjet nga disa adresa, kështu që përjashtimi i një /32 nuk e përjashton faqen. Nëse kërkesa e vërtetë është rrugëtimi për çdo aplikacion, tabela e rrugëve e klientit Community është mjeti i gabuar.
Verifikimi i përjashtimit pa mashtruar veten
Filloni me rrugën e instaluar, jo me shfletuesin. Në Linux, pyesni kernelin cilën rrugë dhe hop tjetër do të përdorë për adresën konkrete; në Windows, lexoni tabelën e rrugëve për atë /32. Konfirmoni që porta është ajo fizike dhe jo tuneli. Nëse zëri mungon, profili nuk u aplikua ose klienti nuk kishte privilegjin të ndryshonte rrugët.
Pastaj provoni dy destinacione. Një kërkesë drejt adresës së përjashtuar duhet të dalë përmes ndërfaqes fizike, dhe një kërkesë drejt një adrese të brendshme kontrolli duhet të vazhdojë të përdorë tunelin. Testimi vetëm i adresës së përjashtuar nuk provon asgjë për pjesën tjetër të tunelit, dhe testimi i një faqeje publike teston adresën në të cilën ajo faqe u zgjidh, e cila mund të mos jetë ajo e rregullit.
Së fundi, kontrolloni kontrollet që mund të mbizotërojnë rrugën. Një kill switch në anën e klientit ose një cilësim block-outside-dns i Windows mund të ndalojë trafikun direkt, gjë që shfaqet si një lidhje që dështon edhe pse rruga është e saktë. Mos i çaktivizoni ato kontrolle për ta bërë përjashtimin të duket se funksionon; nëse politika ndalon rrugën direkte, përjashtimi është problem projektimi për pronarin e shërbimit VPN.
Rikontrolloni pas rilidhjes ose ndryshimit të rrjetit, sepse porta para VPN dhe rruga e disponueshme janë veti të momentit, jo të profilit.