Router LAN dhe klient VPN: dy pajisje, dy tabela rrugësh

Dy pajisje përcjellin paketën dhe secila mban tabelën e vet. Routeri LAN e di se parashtesa e largët i përket klientit VPN, dhe klienti VPN e di se si ta arrijë atë parashtesë përmes tunelit të vet. Konfiguroni vetëm tabelën e parë dhe paketa arrin në një makinë pa rrugë përputhëse, prandaj del përsëri nga rruga e paracaktuar. Kjo është e gjithë defekti, dhe nga ana e LAN-it duket si një lak rrugëtimi, sepse pothuajse është.

Vizatoni dy hapat para se të prekni një rrugë

Merrni një skemë ilustruese: hoste të LAN-it në 192.168.50.0/24, routeri i zakonshëm në 192.168.50.1, një klient i dedikuar në 192.168.50.15 dhe një LAN i largët në 10.60.0.0/24 i arritshëm vetëm përmes tunelit që mban ai klient. Asnjëri prej dy intervaleve private nuk mbivendoset me tjetrin, dhe tuneli ka planin e vet të adresave.

Të dy intervalet private kanë rëndësi, sepse vendosin se cila pajisje mund të përgjigjet. Ana e largët do ta shohë paketën të vijë nga adresa e tunelit të klientit, dhe përgjigjja e saj duhet të gjejë një rrugë kthimi te 192.168.50.0/24. Nëse është konfiguruar vetëm drejtimi i daljes, kërkesa mund të funksionojë ndërsa përgjigjja zhduket.

Hapi 1: drejtojeni routerin te klienti, jo te tuneli

Në routerin LAN, shtoni një rrugë destinacioni, hapi tjetër i së cilës është adresa LAN e klientit:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

Ai rekord thotë „dërgoje te makina që mund të bëjë tunel“. Nuk thotë asgjë për mënyrën se si ndërtohet tuneli dhe nuk zë vendin e rrugës së vetë klientit. Në një router të menaxhuar, ekuivalenti jeton në faqen e rrugëve statike të pajisjes; në një router Linux ai i përket konfigurimit të ndërfaqes që zotëron LAN-in, jo një shell-i që do të mbyllni.

Kontrolloni përgjigjjen e komandës së dytë. Nëse raporton klientin si gateway dhe ndërfaqen LAN si device, hapi i parë është i saktë dhe puna e mbetur është në makinën tjetër.

Hapi 2: jepini klientit rrugën e vet nga ana e tunelit

Klienti tani merr një paketë për 10.60.0.0/24 dhe shikon tabelën e vet. Nëse konfigurimi i tunelit ka instaluar një rrugë për atë parashtesë, paketa vazhdon e kriptuar. Nëse jo, paketa përputhet me rrugën e paracaktuar të zakonshme dhe kthehet te 192.168.50.1, i cili e dërgon përsëri te klienti.

Shikoni përpara se të shtoni diçka:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

Mungesa e një rrugë parashtese në të gjitha tabelat është zbulimi që po kërkoni. Shtojeni përmes konfigurimit të vetë tunelit, që rilidhja tjetër ta instalojë përsëri; një ip route add manuale zhduket me sesionin dhe e bën defektin të kthehet në momentin më të papërshtatshëm. Hapi tjetër është ndërfaqja e tunelit ose adresa që VPN-i cakton si palë e vet, në varësi të klientit, dhe adresa e palës duhet të vijë nga profili aktual dhe jo nga një shënim i vjetër.

Laku, kur ndodh, në praktikë nuk është i pafund: TTL bie në çdo kalim dhe paketa vdes me një mesazh për kohë të tejkaluar. Prandaj një traceroute i përsëritur mund të sugjerojë një cikël, ndërsa një klient që thjesht nuk përcjell e hedh të njëjtën paketë në heshtje.

Hapi 3: lejoni përcjelljen dhe zgjidhni rrugën e kthimit

Marrja dhe përcjellja janë leje të ndryshme. net.ipv4.ip_forward=1 te klienti lejon tranzitin në nivel kerneli, dhe një rregull i firewall-it duhet ende ta lejojë atë midis ndërfaqes LAN dhe tunelit. Një rregull që lejon aksesin në faqen e administrimit të vetë klientit nuk do të lejojë tranzit drejt LAN-it të largët, dhe dallimi është i lehtë për t’u anashkaluar kur i njëjti host përgjigjet ping-ve lokalisht.

Ana e largët ka problemin e pasqyrës. Duhet ta dijë se 192.168.50.0/24 është i arritshëm përmes këtij klienti të vërtetuar. Me OpenVPN kjo zakonisht do të thotë një rrugë për çdo klient që shtyhet nga konfigurimi i serverit, ose një skedar specifik i klientit në server që deklaron LAN-in pas klientit. Pa të, LAN-i i largët ose e hedh përgjigjjen ose e dërgon te porta e vet e paracaktuar, domethënë në internet.

Përkthimi i burimit është alternativa kur parashtesa e LAN-it nuk mund të shpallet. Një rregull masquerade me shtrirje te klienti e rishkruan burimin në adresën e tunelit, dhe përgjigjjet kthehen atëherë natyrshëm. Fsheh gjithashtu cili host i LAN-it e bëri kërkesën, dhe në vetvete nuk e lejon anën e largët të nisë lidhje nga brenda. Zgjidhni me qëllim atë kompromis, në vend që të shtoni një masquerade të përgjithshme dhe ta zbuloni efektin anësor më vonë.

Hapi 4: bëjini të dyja vendimet të përhershme, më pas testoni rrugën e vërtetë

Çdo rrugë ka një pronar, dhe pronari është konfigurimi që riprodhohet në nisje ose në rilidhje. Në router mund të jetë një zë rruge statike; te klienti mund të jetë profili VPN, NetworkManager ose systemd-networkd. Verifikoni duke rilidhur tunelin dhe duke rinisur klientin, më pas lexoni tabelën përsëri në vend që t’i besoni ndryshimit.

Mbajeni të paprekur rrugën e paracaktuar që mban lidhjen e jashtme të tunelit. Zëvendësimi i saj për të „thjeshtuar“ konfigurimin prish rrugën e kriptuar përpara se ndonjë trafik i brendshëm ta përdorë atë, dhe simptoma është një tunel që nuk rivendoset kurrë pas ndryshimit.

Testoni nga një host i zakonshëm i LAN-it, jo nga klienti, sepse një kërkesë që lind te klienti nuk e ushtron kurrë hapin e parë të routerit. Sillni një shërbim që ekziston vetëm në LAN-in e largët dhe konfirmoni trupin e përgjigjjes, më pas shikoni numëruesit ose regjistrat e klientit për të parë tranzitin. Një traceroute i brendshëm që tregon hapa privatë provon përcjelljen, jo kriptimin: rruga e jashtme është vëzhgim i veçantë, dhe vetëm numëruesit e ndërfaqes së tunelit tregojnë çfarë doli përmes tij.