Zgjerimi i faqes VPN: ndiqni rrugën e kthimit përtej portës

Trafiku nga një degë përfundon në një portë, LAN-i i së cilës nuk përmban aplikacionin që ju kërkuan të arrinit. Serveri ndodhet në një qendër të dytë të dhënash, përtej një lidhjeje të brendshme që VPN-ja nuk e konfiguroi kurrë. Shtimi i një prefiksi tjetër në portën e afërt nuk bën asgjë për atë rast, sepse porta e largët është pikë fundore e kriptimit, jo ruteri i fundit. Rruga kërkon një rrugë përpara, një pranim në kufirin e sigurisë së largët dhe një vendim kthimi në vetë rrjetin e destinacionit.

Porta e largët është pikë fundore e kriptimit

IPsec ndërmjet portave mbron trafikun ndërmjet dy pajisjeve të sigurisë, dhe adresat e brendshme udhëtojnë përgjatë atij segmenti të kriptuara. Përtej portës së largët merr drejtimin rrugëtimi i zakonshëm, duke përfshirë çdo politikë që ekziston ndërmjet qendrave të dhënash. Prandaj segmenti i mbrojtur mbulon një pjesë të udhëtimit dhe jo pjesën tjetër. Të supozosh të kundërtën është mënyra se si një projekt përfundon me një tunel të shëndetshëm dhe një aplikacion të paarritshëm.

Vizatoni rrugën në tre pjesë: dega në portën e afërt, e afërta në të largëtën, porta e largët në aplikacion. Secila pjesë ka pronarin e vet dhe mënyrën e vet të dështimit.

Lexoni të dy drejtimet e politikës së tunelit

Politika e tunelit zakonisht shkruhet nga këndvështrimi i anës lokale, dhe pikërisht nga ky zakon vijnë konfigurimet e pjesshme. Të dy palët duhet të listojnë burimin e degës dhe destinacionin ashtu siç do të shfaqen brenda tunelit, duke përfshirë çdo përkthim që projekti synon. Përditësimi vetëm i skajit të afërt prodhon një mospërputhje të fazës së dytë që duket si dështim rrugëtimi. Krahasoni dy grupet e politikave përpara se të prekni çdo rrugë.

Shkruani burimin dhe destinacionin si adresa, jo si emra faqesh. Paqartësia këtu rishfaqet më vonë si një asimetri e çuditshme.

Shtoni rrugën përpara dhe konfirmoni pranimin

Porta e largët ka nevojë për një rrugë drejt nënrrjetit të aplikacionit, dhe çdo ruter ndërmjet tyre duhet të pranojë burimin e degës. Verifikoni çfarë ka vërtet porta e largët, në vend të asaj që pretendon diagrami.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

Komanda e parë raporton ndërfaqen e daljes dhe hopin tjetër që porta e largët do të zgjidhte për atë burim, një pyetje së cilës një tabelë e zakonshme rrugëtimi nuk mund t’i përgjigjet. Gjurma tregon ku ndalen paketat, dhe një ndërprerje pas portës së largët tregon tranzit të brendshëm dhe jo tunelin. Kur rruga ekziston dhe trafiku prapë zhduket, kapni në portën e largët dhe lexoni adresën e burimit që mbërrin, sepse një adresë e papritur do të thotë që përkthimi po ndodh diku pa plan. Të gjitha adresat këtu janë zëvendësues, prandaj zëvendësoni nënrrjetet e vërteta të degës, tranzitit dhe aplikacionit.

Testoni nga dega, pastaj ritestoni rrugën e vjetër

Pranimi kërkon një burim të vërtetë, jo një sondë nga porta e largët. Ekzekutoni kontrollin nga një host i degës dhe mbani destinacionet që funksiononin më parë në të njëjtin test.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Një përgjigje nga aplikacioni dëshmon bashkë rrugën përpara dhe rrugën e kthimit, ndërsa ping-u drejt destinacionit të vjetër dëshmon që ndryshimi nuk prishi atë që funksiononte tashmë. Kapni adresën e burimit që regjistron aplikacioni, sepse rregullat e tij të aksesit dhe çdo rrugë kthimi duhet të përputhen me atë vlerë. Aty ku dega përkthen përpara tunelit, adresa e politikës dhe adresa që sheh aplikacioni ndryshojnë sipas projektit, prandaj regjistroni të dyja. Përsëriteni testin pas një rinovimi çelësi ose një ndryshimi rrugëtimi, sepse këto rrugë zakonisht vërtetohen një herë dhe pastaj harrohen.

Caktoni një pronar për secilin nga tre segmentet dhe për rrugën e kthimit brenda rrjetit të destinacionit. Një rrugë me katër pronarë dështon në boshllëqet ndërmjet tyre.