Klientët VPN arrijnë serverin por jo rrjetin LAN: cili rregullim?

Klienti bën ping në adresën e tunelit të serverit OpenVPN dhe merr përgjigje, pastaj provon një host në LAN-in e serverit dhe nuk merr asgjë. Kjo ndarje e ngushton ndjeshëm defektin: tuneli është ngritur, përcjellja ndoshta punon, dhe përgjigja del nga një derë që nuk të kthen mbrapsht. Ka tre rregullime, dhe e sakta varet nga ajo që kontrolloni dhe ajo që jeni gati të hiqni dorë. Përgjigjuni tre pyetjeve më poshtë me radhë dhe zgjedhja nuk është më çështje shije.

Së pari, vërtetoni cila drejtim është i prishur

Kërkesa arrin në ndërfaqen e tunelit me një adresë burimi nga pishina VPN. Serveri e përcjell te hosti në LAN, dhe ai host i përgjigjet portës që emërton tabela e tij, zakonisht ruterit të LAN-it. Nëse ruteri nuk ka rrugë drejt pishinës, përgjigja vdes atje ose endet drejt internetit.

Provoni të dyja makinat përpara se të ndryshoni ndonjërën. Pyetni tabelën e rrugëtimit në server se si do të arrinte një klient; pyetni hostin në LAN se si do të arrinte të njëjtën adresë. Kërkimi i parë zakonisht tregon tunelin dhe i dyti ruterin e LAN-it, dhe ky ndryshim është defekti në një rresht. Dy kërkime kushtojnë më pak se një audit i murit të zjarrit dhe përcaktojnë drejtimin e problemit.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Nëse hosti në LAN tashmë tregon serverin VPN, problemi juaj është një rregull i murit të zjarrit ose një kufi MTU, jo një rrugë kthimi që mungon. Mos shtoni rrugë për të rregulluar një filtër.

Pyetja e parë: a mund të redaktoni ruterin e LAN-it të largët?

Kur ruteri i LAN-it është i juaji, përgjigja e pastër është një rrugë statike drejt pishinës VPN me adresën LAN të serverit VPN si hap tjetër. Ajo i mban të paprekura adresat burimore të klientëve, gjë që ka rëndësi kur hostet në LAN regjistrojnë, filtrojnë ose kufizojnë shpejtësinë sipas adresës. Gjithashtu nuk kërkon përkthim në server, kështu që tuneli mbetet një rrugë e pastër. Detyrimi që krijon është dokumentimi, sepse pishina, rruga dhe konfigurimi i serverit duhet të përputhen.

Ajo dështon në heshtje ditën kur dikush ndryshon pishinën. Shkruajeni vlerën një herë dhe trajtoni një ndryshim në cilindo nga tre vendet si një ndryshim në të tre.

Një NAS ose një komutator i shtresës 3 që strehon shërbimin ka nevojë për të njëjtën rrugë, përveç nëse dërgon gjithçka përmes një ruteri që e ka atë. Kontrolloni pajisjen që përfundon nënrrjetin, jo vetëm atë që shikon nga interneti. Rrjetet e vogla shpesh kanë tre pajisje me mendim për rrugëtimin.

Pyetja e dytë: a mundet LAN-i të ndalojë së parë adresat e klientëve?

Kur ruteri i përket dikujt tjetër, përkthimi në serverin VPN nuk kërkon bashkëpunim. Hosti në LAN sheh adresën LAN të serverit, i përgjigjet asaj, dhe serveri përkthen mbrapsht. Kjo është arsyeja pse pajisjet dhe rolet e aksesit në distancë të bazuara në NAT sillem kështu.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Çmimi është atribuimi: adresat për klient zhduken nga regjistrat e LAN-it. Çdo listë lejimesh në hostin e LAN-it duhet atëherë të emërtojë serverin në vend të pishinës.

Zgjidhni përkthimin kur bashkëpunimi nuk është i disponueshëm, jo kur është thjesht i papërshtatshëm. Ai e fsheh klientin nga çdo hetim i ardhshëm, përfshirë ato ku duhet të dini cili laptop hapi një lidhje. Mund të prishë edhe protokolle që futin adresa në ngarkesë, sepse përkthimi jeton në krye. Asnjëra mundësi nuk është më e avancuar; ato përgjigjen pyetje të ndryshme rreth pronësisë.

Pyetja e tretë: a është vetë serveri klient i një tuneli tjetër?

Imagjinoni topologjinë tjetër: serveri VPN thërret edhe një ofrues komercial, kështu që ka dy tunele dhe dy grupe adresash. Trafiku që përcjell për klientët e vet del përmes ofruesit, dhe ai nuk do t'i drejtojë përgjigjet mbrapsht te adresat e pishinës. Kjo është arsyeja pse përgjigjet zhduken edhe pse të dy tunelit janë të shëndetshëm.

Rregullimi është të maskohet edhe tuneli dalës, që ofruesi të shohë vetëm adresën e tunelit të serverit. Drejtimi i kundërt kërkon rregullin e vet, sepse serveri që nis një lidhje drejt një klienti të vet është një rrjedhë tjetër. Pa atë rregull, klienti përgjigjet në një adresë që nuk mund ta rrugëtojë. Vendoseni rregullin e ngushtë përpara çdo maskimi të gjerë, që përkthimi specifik të fitojë.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Hostet me ndërfaqe të shumta shtojnë një defekt të afërm që duket identik nga klienti. Përgjigja del përmes ndërfaqes me metrikë më të ulët sepse adresa burimore u zgjodh nga një tabelë tjetër. Kontrolloni rrugën e kthimit me një kërkim, në vend që të supozoni se rruga e shkuarjes e përfshin.

Pastaj verifikoni të dy drejtimet dhe të dy madhësitë

Pas ndryshimit, bëni ping nga klienti te një host në LAN dhe pastaj nga hosti në LAN te klienti. Drejtimi i dytë është ai që njerëzit e anashkalojnë, dhe është ai që zbulon një rregull përkthimi të paplotë. Regjistroni të dy rezultatet me vulë kohe, që një regres i mëvonshëm të jetë i krahasueshëm.

Pastaj lëvizni të dhëna reale, sepse një ping i vogël që kalon ndërsa një transferim i madh ngec është një simptom MTU. Ai defekt shfaqet menjëherë pasi të keni uruar veten për rregullimin e rrugës.

Së fundi, riprovoni pas një rindezjeje. Komandat e rrugës dhe të murit të zjarrit në kohë ekzekutimi nuk i mbijetojnë, dhe një rregullim që zhduket në nisjen tjetër do të diagnostikohet përsëri nga dikush me më pak kontekst. Bëjeni ndryshimin të përhershëm në mënyrën që sistemi juaj e bën tashmë, pastaj rindizni një herë me qëllim.