Shtoni një rrugë të parazgjedhur përmes tunelit dhe paketat e vetë tunelit do t'i binden asaj. Tabela atëherë përmban një rregull që e mund vetveten. Lidhja e kriptuar me serverin përpiqet të udhëtojë brenda lidhjes që po përpiqet të krijojë.

Dy mekanizma e pengojnë atë lak. Njëri është i dukshëm në tabelën e rrugëzimit, tjetri jeton brenda aplikacionit.

Trafiku i brendshëm dhe i jashtëm janë vendime të ndryshme

Një paketë aplikacioni hyn në ndërfaqen virtuale dhe inkapsulohet. Rezultati është një paketë e re e adresuar drejt adresës publike të serverit. Ajo paketë ka nevojë për një rrugë në rrjetin fizik, sepse asgjë prej saj nuk mund të hyjë në tunel.

Të dyja janë vendime rrugëzimi, dhe vetëm e para i përket tunelit. Kur klienti instalon një rrugë të parazgjedhur që mbulon edhe serverin, edhe paketa e jashtme kapet.

Simptomat janë të menjëhershme dhe totale. Shtrëngimi i duarve përfundon dhe pastaj asgjë nuk rrjedh, ose lidhja bie në çastin kur instalohet rruga. Në të dyja rastet keepalive nuk mund të dalë më.

Opsioni një: një rrugë hosti për pikën fundore

Qasja e drejtpërdrejtë shton një rrugë për adresën e serverit përmes portës origjinale. Kërkon vetëm një rresht. Është e dukshme për këdo që lexon tabelën. Është gjithashtu e lehtë për t'u shpjeguar në një regjistër ndryshimesh.

Dobësia e saj shfaqet kur ndryshon shtegu themelor. Rruga e ruajtur emërton një portë dhe një ndërfaqe nga rrjeti i vjetër. Pas një ndryshimi Wi-Fi ajo portë mund të mos ekzistojë, dhe rruga mbetet pas, duket e saktë dhe nuk bën asgjë.

# before the tunnel: which path reaches the endpoint?
ip route get 198.51.100.7

# pin it through the current gateway
ip route add 198.51.100.7/32 via 192.168.1.1 dev wlan0

# after the tunnel is up, confirm the pin survived
ip route get 198.51.100.7

Një emër hosti e bën këtë më të vështirë. Nëse pika fundore është një emër që zgjidhet në disa adresa, përjashtimi duhet të mbulojë adresën që përdoret në të vërtetë. Një kërkim i mëvonshëm mund të kthejë diçka që rruga nuk e ka mbuluar kurrë.

Opsioni dy: mbrojtja e socket-it

Qasja tjetër nuk e prek kurrë tabelën e rrugëzimit. Klienti shënon ose mbron socket-in që mbart tunelin, kështu që sistemi operativ dërgon trafikun e atij socket-i jashtë tunelit sipas politikës. Android e ekspozon mekanizmin drejtpërdrejt për aplikacionet VPN. Klientët e desktopit zbatojnë ekuivalente me shenja të murit të zjarrit ose thirrje lidhjeje me pajisjen.

Avantazhi është se përjashtimi ndjek lidhjen dhe jo një portë të ruajtur. Një ndryshim rrjeti rishkruan shtegun themelor, dhe socket-i i mbrojtur lëviz me të sepse nuk ishte kurrë i gozhduar në një adresë. Tabela e rrugëve mbetet e pastër.

Kostoja është dukshmëria. Asgjë në tabelën e rrugëzimit nuk e tregon përjashtimin, kështu që një rishikues që kërkon një rrugë hosti nuk gjen asgjë dhe mund të konkludojë se projektimi nuk është i sigurt. Mbrojtja jeton në kodin e klientit dhe në rregullat e politikës që ai kod instalon.

Zgjedhja mes tyre

Zgjidhni mekanizmin në nivel socket-i kur klienti e mbështet, sepse i mbijeton ndryshimeve të rrjetit që thyejnë një rrugë të gozhduar. Zgjidhni rrugën e hostit kur përjashtimi duhet të jetë i dukshëm për mjete të tjera, ose kur klienti nuk ofron asgjë më të mirë.

Asnjë mekanizëm nuk e heq nevojën që adresa e serverit të jetë fare e arritshme. Një portë private ka një adresë publike dëgjimi, dhe është pikërisht ajo adresë që duhet të mbetet jashtë tunelit. Rrjetet e brendshme pas saj bëhen të arritshme vetëm pasi tuneli ekziston.

Çfarëdo që të zgjidhni, mbajeni pranë komponentit që zotëron tunelin. Një rrugë hosti e humbur e shtuar me dorë funksionon deri në rrjetin tjetër, dhe pastaj bëhet ndërprerja misterioze e nesërmes.

Artikuj të ngjashëm