Pse një rrugë tuneli të plotë pret serverin që e mbart
Një rrugë e parazgjedhur përmes tunelit kap edhe paketat e jashtme që e mbartin. Fikso pikën fundore me një rrugë hosti dhe mbaji përgjigjet e serverit jashtë saj.
Aktivizo një tunel të plotë dhe çdo destinacion tani i përket ndërfaqes VPN, përfshirë makinën që e përfundon. Paketat e jashtme që mbartin tunelin adresohen për atë makinë, kështu që rruga përfundimisht konsumon transportin nga i cili varet. Një rrugë specifike shtesë e zgjidh këtë, dhe arsyeja ia vlen të kuptohet. Pa atë arsye, rindërtimi tjetër e rikthen defektin.
Një rrugë që ha transportin e vet
Enkapsulimi e mbështjell çdo paketë në një kokë të dytë. Ajo e jashtmja adresohet nga adresa fizike lokale në adresën publike të serverit, dhe duhet të kalojë lidhjen fizike përpara se të mund të ekzistojë ndonjë tunel.
Tani lëre kërkimin për atë adresë publike të zgjedhë tunelin. Për të dërguar paketën, makina duhet ta enkapsulojë, gjë që kërkon një rrugë drejt të njëjtës adresë, e cila e kthen tunelin. Klientët e trajtojnë këtë në një nga dy mënyra. Ai i kujdesshëm refuzon të instalojë rrugën e parazgjedhur dhe raporton një gabim, ndërsa ai më pak i kujdesshëm raporton sukses dhe më pas nuk lëviz asgjë. Dështimi i heshtur është ai që kushton një pasdite.
Përputhja e prefiksit më të gjatë vendos kërkimin përpara se të konsultohet ndonjë metrikë, kështu që një rrugë me një adresë tejkalon çdo rrugë të parazgjedhur në makinë. Ky është i gjithë mekanizmi pas riparimit.
Instalo përjashtimin para asaj të parazgjedhur
Krijo një rrugë me një adresë për serverin, me portën fizike si hopin tjetër, përpara se rruga e parazgjedhur të lëvizë. Rendi ka rëndësi: instalimi më pas do të thotë të jetosh me një tunel të prishur ndërsa shtyp.
Shumica e klientëve e bëjnë këtë pa u kërkuar. OpenVPN kërkon adresën e largët dhe e fikson përpara se të rishkruajë portën e parazgjedhur, dhe opsioni i tij route-delay ekziston për platformat ku ajo sekuencë garon. wg-quick ndjek një rrugë krejt tjetër, duke shënuar paketat dhe duke konsultuar një rregull politike në vend që të shtojë një përjashtim. Mekanizma të ndryshëm, i njëjti kërkesë: paketa e jashtme duhet të shpëtojë nga tuneli që krijon.
ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10
Dalja e kërkimit është testi i pranimit. Duhet të emërojë pajisjen fizike dhe hopin fizik tjetër. Një pajisje tuneli në atë përgjigje do të thotë që përjashtimi mungon, ose u vendos pas diçkaje që e anulon.
Imazhi pasqyrë në server
E njëjta kurth pret në anën tjetër, e përmbysur. Jepi serverit një rrugë të parazgjedhur përmes një tuneli tjetër, ose shtyje një rrugë që mbulon adresat publike të klientëve, dhe përgjigjet e tij marrin zakonin e drejtimit të gabuar.
Imagjino një klient që lidhet dhe dërgon një kërkesë. Përgjigja adresohet për adresën publike të atij klienti, e cila tani përputhet me një rrugë tuneli, kështu që niset nga një ndërfaqe tjetër duke mbartur një burim që klienti nuk e ka zgjedhur kurrë. Klienti mund ta marrë atë paketë dhe gjithsesi ta hedhë poshtë, sepse asgjë nuk e lidh me kërkesën që dërgoi. Nis nga vendimi i rrugëzimit të serverit dhe jo nga afati i klientit, pasi vetëm njëri prej tyre tregon zgjedhjen reale.
ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44
Ekzistojnë tre riparime dhe nuk janë të barabarta. Fiksimi i shërbimit në adresën fizike, ose përkthimi i burimit, të dyja fshehin vendimin e rrugëzimit në vend që ta korrigjojnë. Dërgimi i trafikut të përgjigjeve për grupin e tunelit përmes një tabele të dedikuar rregullon shkakun, dhe dy të tjerat janë të pranueshme vetëm sa kohë dizajni i rrugëzimit është i ngrirë.
Përjashtime që tuneli vazhdon t'i vjedhë
Një grusht detyrash kanë nevojë për internetin e hapur edhe kur tuneli zotëron rrugën e parazgjedhur, dhe secila ka nevojë për përjashtimin e vet. Përditësuesi i DNS dinamik zakonisht është i pari që thyhet.
Ai zgjidh ofruesin, hap një lidhje dhe zbulon se paketat e tij po udhëtojnë përmes një tuneli adresa e të cilit ndryshoi sekonda më parë, kështu që përditësimi dështon ose publikon adresën e gabuar. Tre rrugëdalje: fikso ofruesin me një rrugë hosti përmes portës fizike, ekzekuto përditësimin përpara se tuneli të ngrihet, ose jepi përditësuesit një tabelë politike që tuneli nuk e prek kurrë. Sinkronizimi i kohës ka të njëjtën ekspozim në një pajisje që niset pa zgjidhës, dhe pikat fundore të validimit të certifikatave i përkasin listës për të njëjtën arsye.
Një përjashtim që askush nuk e shkroi është një përjashtim që rindërtimi tjetër do ta hedhë në heshtje.
Provoje pas një rilidhjeje, jo përpara
Testo tre destinacione, jo një: pikën fundore, një adresë private pas tunelit dhe një adresë publike përtej tij. Një kërkim i suksesshëm nuk thotë pothuajse asgjë për dy të tjerat.
ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1
Pastaj rinis lidhjen, sepse një klient që rindërton tabelën e tij në rilidhje do të hedhë një rrugë që e shtypët me dorë. Me një kill switch në lojë, kontrollo që pika fundore është e lejuar, përndryshe tuneli nuk mund të kthehet pas një ndryshimi rrjeti dhe simptoma duket si ndërprerje. Ruaj përjashtimin në profil ose në skedarin unit dhe jo në historikun e shell, që rilidhja ta rikrijojë në vend që ta fshijë.