VPN-ja e ruterit funksionon, por klientët LAN nuk kanë internet

Statusi thotë se tuneli është aktiv, një shfletues në vetë ruterin ngarkon faqe, dhe çdo pajisje pas tij përsëri skadon. Ky kombinim e ngushton problemin në një shtresë që shumica e udhëzuesve të VPN nuk e përmendin kurrë: ruteri nuk është i vetmi host, paketat e të cilit duhet t'i mbijetojnë tunelit. Trafiku i krijuar lokalisht dhe trafiku i përcjellë ndjekin shtigje të ndryshme përmes të njëjtit kuti. Provo nga një klient dhe ndryshimi nuk është më teorik.

Lexoja dështimin nga një host LAN

Fillo nga pajisja që dështon, sepse një diagnozë e ekzekutuar në ruter përgjigjet një pyetjeje tjetër. Konfirmo që porta e paracaktuar e klientit është ky ruter, shëno adresën e burimit dhe nënrrjetin e tij, dhe më pas shiko çfarë del nga ndërfaqja e tunelit të ruterit.

Nëse adresa e klientit përkthehet, ana e largët sheh adresën e tunelit, dhe nga atje gjithçka duket e shëndoshë ndërsa klienti vazhdon të dështojë. Nëse nuk përkthehet, ana e largët duhet të njohë një rrugë përsëri drejt nënrrjetit të klientit, dhe shumë porta nuk e kanë një rrugë të tillë si parazgjedhje. Në çdo rast, suksesi i vetë ruterit është i parëndësishëm, sepse paketat e tij u krijuan lokalisht dhe nuk e kaluan kurrë shtegun e përcjelljes.

Trafiku lokal dhe ai i përcjellë janë të ndryshëm

Linux dhe shumica e firmware-ve të ruterave i trajtojnë paketat e krijuara nga vetë kutia ndryshe nga paketat që kalojnë përmes saj. Zinxhiri output sheh llojin e parë, zinxhiri forward sheh të dytin, dhe një politikë e përshtatur për trafikun e vetë ruterit mund ta lërë përcjelljen të paprekur.

sysctl net.ipv4.ip_forward
ip -4 address show br-lan
ip route get 203.0.113.9
nft list ruleset | grep -A 6 'chain forward'

Kontrollo nëse përcjellja është aktivizuar fare, pastaj lexo zinxhirin forward në vend të zinxhirit output. Një rregull që lejon lidhjen e jashtme të kriptuar nuk është një rregull që lejon përcjelljen e paketave të dekriptuara, dhe ngatërrimi i të dyjave prodhon pikërisht këtë simptomë. Tuneli aktiv vërteton vetëm të parin.

Duhet të ekzistojë edhe rruga e kthimit

Përkthimi i burimit vendos nëse nevojitet një rrugë kthimi. Me masquerading në ndërfaqen e tunelit, përgjigjet kthehen në adresën e tunelit dhe ruteri i përkthen përsëri. Pa të, porta e largët ka nevojë për një rrugë të qartë drejt nënrrjetit të klientit, dhe politika e saj duhet ta lejojë atë drejtim.

Shëno cila nga dy modelet përdoret nga vendosja përpara se të ndryshosh gjithçka, sepse riparimet tregojnë drejtime të kundërta. Shtimi i përkthimit fsheh një rrugë kthimi që mungon dhe thyen aplikacionet që kanë nevojë për adresën origjinale të burimit. Shtimi i një rrugë kthimi pa përkthim dështon në heshtje kur firewall-i i largët hedh burimin e panjohur. Zgjidh një, dokumentoje dhe përshtat anën tjetër.

DNS-ja e klientit bën pjesë në të njëjtën rishikim. Zgjidhësi i ruterit mund të përgjigjet ndërsa një klient i drejtuar te një server tjetër nuk merr asgjë.

Verifiko një rrjedhë të lejuar dhe një të refuzuar

Pas korrigjimit, provo një lidhje të re nga një klient, jo një sesion ekzistues të ruterit. Pastaj konfirmo që një segment që nuk duhet të përdorë tunelin vazhdon të mos e përdorë.

curl -sS --max-time 8 https://api.ipify.org
ip route get 203.0.113.9
dig +short intranet.example.net

Kontrollo adresën e burimit të vërejtur në skajin e largët, sepse kjo të tregon cili model po ekzekutohet në të vërtetë. Verifiko edhe kërkimin e emrit edhe adresën, sepse sjellja e zgjidhësit është një shteg i veçantë përmes të njëjtit kuti.

Mbaji rregullat të kufizuara në rrjetet e klientëve që kanë nevojë për tunelin, dhe rezisto tundimit për të çaktivizuar filtrin e përcjelljes që të kalojë një test. Ai ndryshim e rregullon testin dhe heq kufirin që tuneli duhej të siguronte. Shkruaj adresën e burimit, vendimin e përkthimit dhe rrugën e kthimit në një shënim, me datë.