Qasja në LAN përmes OpenVPN është prishur? Kontrolloni zonat, rrugët dhe rrugën e kthimit

Tuneli raporton lidhje të suksesshme, faqja e vetë ruterit ngarkohet, dhe mapimi i diskut drejt një makine pas tij ende skadon. Asgjë në këtë kombinim nuk është kontradiktore: ruteri përgjigjet si vetvetja, dhe arritja e diçkaje pas tij është një vendim tjetër i marrë në një vend tjetër. Kryeni kontrollet më poshtë me radhë dhe ndaloni në dështimin e parë, sepse secili mbështetet tek ai i mëparshmi. Kur kalojnë të katër, defekti është sipër tunelit dhe jo brenda tij.

Cili filtër sheh një paketë drejt LAN-it

Një paketë e adresuar drejt ruterit konsumohet lokalisht; një paketë e adresuar drejt një hosti pas tij duhet përçuar, dhe muret e zjarrit i gjykojnë këto dy raste veçmas. Pra leja për të arritur ruterin nuk thotë asgjë për lejen për ta kaluar atë. Firmware-i që fsheh grupet e rregullave të tij zbaton gjithsesi të dyja, zakonisht si një përzgjedhës që ofron LAN-in, internetin ose të dyja. Nëse përzgjedhësi lë jashtë LAN-in, asnjë kontroll i mëvonshëm nuk do të ketë rëndësi.

OpenWrt e bën këtë ndarje të inspektueshme, dhe dallimi vlen një lexim. Zona që përfundon tunelin ka nevojë për një rregull përçimi drejt zonës LAN, ndërsa një rregull hyrjeje qeveris vetëm shërbimet në vetë ruterin. Një faqe administrimi që funksionon pranë një LAN-i të vdekur është rezultati i zakonshëm i atij rregulli përçimi që mungon.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Shikoni objektivin e përçimit të zonës që mban tunelin: accept është ajo që i duhet shkallës, dhe reject shpjegon çdo skadim më poshtë. Dy cilësime fqinje prodhojnë të njëjtin simptom, prandaj përjashtojini ndërsa jeni këtu. Izolimi me valë i fsheh hostet me tel nga klientët me valë, dhe një ruter që i trajton hostet LAN joaktivë si jashtë linje mund t'i hedhë përgjigjet edhe pasi përçimi funksionon.

Pse një tunel i ndarë ka nevojë për prefiksin e shtyrë

Një klient që dërgon gjithë trafikun përmes tunelit e ka tashmë prefiksin LAN përmes rrugës së tij të paracaktuar, prandaj nuk ka çfarë të shtohet. Tuneli i ndarë është rasti që kërkon prefiksin e deklaruar në mënyrë eksplicite, sepse asgjë tjetër në konfigurim nuk e përmend atë. Shtoni direktivën në konfigurimin e serverit dhe ringarkoni shërbimin.

push "route 192.168.50.0 255.255.255.0"

Profilet që përmbajnë route-nopull i injorojnë rrugët e shtyra, prandaj i njëjti prefiks i takon skedarit të klientit. Në çdo rast, konfirmoni se hyrja mbërriti në vend që ta supozoni, sepse një zëvendësim i heshtur duket identik me një problem muri zjarri.

ip route show | grep 192.168.50

Një palë site-në-site kërkon më shumë se një shtytje. Serveri duhet të mësojë cilat prefikse qëndrojnë pas asaj pale, gjë që e bën një rresht iroute në skedarin e tij client-config-dir, dhe tabela e tij ka nevojë për një rrugë përputhëse në tunel.

Përgjigjes i duhet një adresë që mund ta arrijë

Përçimi i kërkesës është vetëm gjysma e një shkëmbimi, sepse hosti LAN duhet t'i përgjigjet një adrese në grupin e tunelit. Ruterët e vegjël e rregullojnë zakonisht këtë duke përkthyer burimin në zonën e tunelit, kështu që përgjigja adresohet drejt ruterit dhe nuk kërkon konfigurim diku tjetër. Hiqni atë përkthim dhe hosti ka nevojë për rrugën e vet drejt grupit, të cilën e merr falas kur ruteri është porta e tij e paracaktuar. Një host me adresë të vendosur me dorë dhe një portë tjetër përgjigjet përmes asaj porte, dhe klienti sheh një sesion që hapet dhe më pas ngec.

tcpdump -ni tun0 host 192.168.50.20

Ekzekutoni këtë në ruter ndërsa klienti përsërit kërkesën, dhe lexoni destinacionin e përgjigjes dhe jo kërkesën. Një përgjigje e adresuar drejt grupit do të thotë që rruga e kthimit funksionon dhe defekti është më thellë. Mungesa e plotë e përgjigjes do të thotë që hosti nuk e pranoi kurrë paketën, gjë që ju kthen te grupi i rregullave.

Një shkallë që përfundon në vendin e duhur

Katër kontrolle lokalizojnë shtresën, dhe secili është një komandë e vetme dhe jo një gjykim. Ekzekutojini me radhë dhe ndaloni në dështimin e parë. Rendi ka më shumë rëndësi se komandat, sepse një hap i mëvonshëm që kalon fsheh arsyen pse një i mëparshëm dështoi.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Emrat i takojnë fundit të shkallës, kurrë fillimit. Një ndarje që përgjigjet si 192.168.50.20 por jo si nas.local tregon te zgjidhja e emrave ose te një prapashtesë kërkimi, dhe ndryshimet në murin e zjarrit nuk mund të ndryshojnë asnjërën.

Shënoni hapin e parë që dështoi, pastaj jepini porteve të shërbimit raundin e tyre, sepse një dëgjues dhe një leje hosti janë kërkesa të ndara. Ndarja e skedarëve, desktopi në distancë dhe rrjedhat e kamerave kanë nevojë për të dyja, dhe një mur zjarri hosti që i beson nënrrjetit LAN por jo grupit të tunelit e hedh klientin ndërsa ping ende kalon. Kur të gjitha kontrollet kalojnë dhe aplikacioni ende dështon, defekti është sipër tunelit: një shërbim i lidhur me një ndërfaqe ose një përfaqësues i konfiguruar te klienti.