route-gateway nuk është redirect-gateway: çfarë ndryshon në të vërtetë

Tuneli juaj ngrihet, nënrrjeti privat përgjigjet, dhe shfletimi i zakonshëm vazhdon të zhduket në VPN edhe pse dikush e ka fshirë rreshtin e portës nga profili. Ai kombinim është gjurma e direktivës së gabuar që u redaktua. Ajo që u hoq i jepte klientit një hop tjetër për rrugët që instalon; ajo që vazhdoi të kapte trafikun erdhi nga diku tjetër dhe u shty nga serveri. Mbulimi dhe hopi tjetër janë detyra të ndara, dhe vetëm njëra prej tyre vendos nëse destinacionet publike përdorin tunelin.

Rreshti që hoqët ishte një hop tjetër, jo një çelës politike

Çdo rrugë që instalon klienti ka nevojë për një adresë porte drejt së cilës të tregojë, dhe direktiva e portës është burimi i asaj adrese kur një rrugë nuk emërton asnjë vetë. Fshijeni dhe ato rrugë nuk kanë ku të kapen, kështu që ose nuk instalohen ose përfundojnë në një shteg që nuk të çon askund. Nënrrjeti privat është pikërisht ajo që mbante një rrugë e tillë.

Ndërkohë sjellja që mbijetoi ka një autor tjetër: një opsion ridrejtimi në bllokun e shtyrë, i cili lëviz trafikun normal dalës në tunel sipas flamujve të tij. Heqja e portës as e çaktivizon as e dobëson atë. Rezultati është më i keqi i të dy gjendjeve, me trafikun publik ende të kapur dhe destinacioni privat që justifikonte tunelin tani i paarritshëm. Kjo është arsyeja pse redaktimi i dytë, bërë në të njëjtin frymë, gjithashtu nuk ndryshon asgjë.

Katër levë, katër detyra të ndryshme

Në këtë diskutim katër direktiva citohen në mënyrë të këmbyeshme, dhe vetëm njëra prej tyre drejton mbulimin, domethënë cilat destinacione kalojnë fare përmes tunelit. E dyta cakton hopin tjetër që përdorin rrugët, e treta instalon një prefiks të vetëm, dhe e katërta hedh poshtë gjithçka që shtyu serveri, përfshirë rrugët private që i nevojiten vendosjes. Tabela i rendit sipas asaj që administratori po përpiqet të ndryshojë dhe jo sipas emrit, sepse emrat janë ata që shkaktojnë konfuzionin. Trajtojini si katër vendime të ndara dhe zgjidhni atë që vërtet dëshironi të ktheni mbrapsht.

Në praktikë të katërta shpesh vijnë në një bllok të vetëm të shtyrë, rresht pas rreshti, gjë që i bën të duken si pjesë të një cilësimi të vetëm. Nuk janë, dhe referenca e OpenVPN i dokumenton si mekanizma të veçantë pikërisht për këtë arsye. Të kuptuarit se cilën vendim po ktheni mbrapsht është puna; redaktimi është një rresht.

Filtroni rreshtin e shtyrë, mbani hopin tjetër

Nëse mbulimi kundër të cilit protestoni vjen si opsion i shtyrë, përgjigjja e ngushtë është të injoroni atë opsion sipas emrit dhe të lini pjesën tjetër të bllokut të shtyrë të paprekur. I shkruar si filtër, duket si rreshti më poshtë, dhe vendi i tij është në profilin e klientit të prekur, jo në konfigurimin e serverit.

pull-filter ignore "redirect-gateway"

Ngushtësia është çështja. Meqenëse filtri krahason një prefiks teksti, një model më i shkurtër përputhet edhe me direktivën e hopit tjetër, gjë që zhvesh pikërisht informacionin nga i cili varen rrugët private dhe përsërit gabimin origjinal në një petk të ri. Filtri vepron gjithashtu vetëm mbi opsionet e shtyra, kështu që nuk prek kurrë një rresht ekuivalent të shkruar lokalisht ose të imponuar nga një menaxher rrjeti. Rilidhuni pas kësaj, sepse një sesion i gjallë nuk rivlerëson atë që shtyu serveri.

Lexoni kërkimin, jo tabelën

Pas ringarkimit të profilit, pyesni kernelin ku do të shkonin vërtet dy destinacione: një brenda prefiksit privat dhe një në internetin publik. Një dump i plotë i tabelës kryesore është më i vështirë për t'u lexuar dhe më i lehtë për t'u lexuar gabimisht, sepse një rrugë mund të ekzistojë dhe gjithsesi të humbasë ndaj një përputhjeje më specifike. Në rrugëtimin e bazuar në politika, rregulli, tabela dhe adresa burimore janë gjithashtu pjesë e kontrollit.

ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show

Varianti def1 meriton njohuri, sepse lë të dukshëm zërin e vjetër të parazgjedhur ndërsa një çift gjysmë-parazgjedhurish fitojnë kërkimin. Prandaj një rresht 0.0.0.0/0 në dalje nuk provon asgjë në vetvete. Kërkimi përgjigjet pyetjes së cilës lista vetëm duket se i përgjigjet.

DNS, IPv6 dhe rruga private duhet ende të funksionojnë

Refuzimi i një ridrejtimi IPv4 nuk thotë asgjë për zgjidhësin, kështu që një opsion DNS i shtyrë mund të vazhdojë të dërgojë pyetje në tunel ndërsa rrugët duken të sakta. Një parazgjedhur IPv6 mund të bëjë të njëjtën gjë për një familje adresash që kontrolli IPv4 nuk e preku kurrë. Të dyja kërkojnë një vendim të qartë në vend të një supozimi. Më pas konfirmoni që shërbimi privat ende përgjigjet, sepse një tunel i ndarë që ka humbur rrugën e tij private nuk është tunel i ndarë, është i thyer.

Një mjet më i gjerë meriton një paralajmërim: route-nopull hedh poshtë çdo rrugë të shtyrë dhe çdo opsion DNS të shtyrë, gjë që ndalon me siguri tunelin e plotë dhe po aq me siguri thyen rrugët private nga të cilat varet vendosja, pra është një çekan shumë më i madh se një filtër emri i drejtuar nga një opsion. Kontrolloni destinacionin privat, një destinacion publik dhe zgjidhësin pas çdo ndryshimi, dhe trajtojeni një shtrëngim duarsh të përfunduar si provë për asgjë tjetër përveç shtrëngimit.