Hapja e portes VPN nuk i lejon klientet te arrijne LAN

Tuneli ngrihet, klienti vertetohet, por LAN-i pas portes mbetet i padukshem. Rregulli qe duhej ta rregullonte kete lejon porten VPN dhe punon saktesisht sic eshte shkruar, sepse ai rregull qeveris paketat qe adresohen drejt vet portes. Trafiku i klientit drejt nje hosti pas portes ka nje destinacion tjeter dhe nje zinxhir tjeter. Nje hyrje e suksesshme nuk ndryshon se cilin prej dy zinxhireve shqyrton berthama.

Dy zinxhire, dy destinacione te ndryshme

Fati i nje pakete vendoset nga ajo se ku shkon, jo nga ajo se si erdhi. Trafiku drejt nje adrese ne porte dorzohet lokalisht dhe vleresohet me rregullat hyrese. Trafiku qe porta percjell me tej vleresohet me rregullat e percjelljes. E njejta nderfaqe tuneli mund te prodhoje te dyja llojet e paketave, prandaj nje rregull nuk mund ti mbuloj te dyja punet.

Gjithe miti ne nje fjali: lejimi i degjuesit nuk thote asgje per lejimin e rrjetit pas tij. Jane dy vendime te vecanta me prova te vecanta, dhe nje emer nderfaqeje mbi te dyja nuk i bashkon.

Cfare lejon ne te vertete rregulli i degjuesit

Paketat e degjuesit perfundojne ne procesin VPN dhe pikerisht kjo ben te mundur ndertimin e tunelit. Faqja e administrimit te portes dhe nje pergjigje diagnostike lokale perdorin gjithashtu rrugen hyrese te vet hostit, prandaj prova drejt portes kalon ndersa gjithcka pas saj deshton. Te dyja rezultatet jane te sakta dhe asnjeri nuk flet per LAN-in.

Kur procesi dekapsulon trafikun e klientit per nje destinacion tjeter, paketa hyn ne rrugen e percjelljes dhe atje kerkon leje. Vertetimi i suksesshem vendos kush eshte klienti; nuk vendos se ku mund te shkoje. Dy pyetjet kane pronare, regjistra dhe mesazhe gabimi te ndryshme.

Testoni nga nje klient, kurre nga porta

Nje prove e krijuar ne porte ndjek rrugen e daljes te vet hostit dhe mund te kaloje ndersa rruga e percjelljes eshte e mbyllur. Filloni proven nga klienti dhe vezhgoni te dy skajet e rrjedhes.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

Nese kerkesa shfaqet ne tun0 dhe asgje nuk arrin destinacionin, paketa hidhet pas mberritjes, cka tregon rregullat e percjelljes ose filtrimin e vet destinacionit. Nese ne tun0 nuk shfaqet asgje, klienti as nuk e dergon ne tunel, dhe problemi eshte rrugezimi ne klient e jo politika ne porte. Krahasoni me nje kerkese qe del sakte dhe nuk kthen asgje, qe eshte rasti i rruges se kthimit.

Percjellja kerkon tri gjerat, jo nje

Percjellja ne berthame duhet te jete e aktivizuar, nje rregull filtri duhet ta pranoje rrjedhen, dhe destinacioni duhet te jete i arritshem me nje rruge qe pergjigja te kthehet. Nese mungon njera prej te triave, heshtja eshte e njejta nga kendveshtrimi i klientit.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lexoni tri daljet bashke. Nje zero ne te paren i ben te padobishme dy te tjerat, dhe nje politike hedhjeje te parazgjedhur ne te dyten hedh paketat e klientit ndersa trafiku i vet portes vazhdon te punoje. Dalja e trete tregon pse rregulli i degjuesit nuk ishte kurre problemi.

Mbani dy grupet e rregullave te ndara ne dokumentacion

Shkruani rregullin e degjuesit dhe rregullin e sherbimit te percjelle ne rreshta te vecante, me pronare dhe arsye te vecanta. Kur porta VPN ndryshon ose publikohet nje sherbim i ri, ajo ndarje pengon qe nje ndryshim ta zgjeroje ne heshtje tjetrin.

Ne vend qe cdo pale e vertetuar te trajtohet si anetar i besuar i LAN-it, perdorni rregulla te ngushta per ato intervalet e klienteve dhe sherbimet qe u duhen. Shenimet per percjelljen te StrongSwan pershkruajne anen e rruges se kthimit dhe te perkthimit te se njejtes kufi, qe eshte perseri nje vendim i trete.

Se fundi, mbani shtresat drejt kur nje perdorues refuzohet. Nese kerkesa arrin hostin dhe aplikacioni e refuzon llogarine, rregulloni lejen e aplikacionit ne ate shtrese; zgjerimi i percjelljes nuk mund te jape kredenciale per ndarjen e skedareve dhe do te zgjeroje aksesin per te gjithe te tjeret qe lidhen me sukses.