Klienti VPN i rrugëzuar arrin serverin, por jo hostet e LAN-it

Tuneli ngrihet, klienti bën ping serverin VPN, dhe një ndarje në një makinë një hap më larg nuk përgjigjet kurrë. Asgjë në konfigurimin e klientit nuk e shpjegon këtë, sepse kërkesa vërtet doli nga klienti dhe vërtet mbërriti. Ajo që dështoi është udhëtimi i kthimit, dhe pajisja që dështoi është zakonisht porta e LAN-it dhe jo hosti VPN. Gjurmimi i paketës së përgjigjes shpjegon të gjithë këtë klasë simptomash.

Ndiqni përgjigjen, jo kërkesën

Serveri VPN deshifron paketën e klientit dhe e përcjell në LAN me adresën e klientit ende në fushën e burimit. Hosti i destinacionit përgjigjet në atë adresë, dhe tani tabela e tij e rrugëzimit vendos gjithçka. Porta e tij e parazgjedhur nuk di asgjë për grupin e tunelit, kështu që përgjigja del drejt ofruesit të internetit dhe hidhet diku përgjatë asaj rruge.

Në klient simptoma është një skadim kohe i heshtur: asnjë refuzim, asnjë rivendosje, thjesht asgjë. Shfletimi i një ndarje ngec, ping-u raporton se nuk ka përgjigje, dhe regjistrat e serverit duken të shëndetshëm sepse serveri bëri punën e tij.

Vendosni rrugën e kthimit aty ku shikojnë hostet

Çdo host i LAN-it konsulton portën e tij të parazgjedhur, prandaj porta është pajisja e vetme që duhet të dijë ku ndodhet grupi i tunelit. Shtoni atje një rrugë statike dhe çdo host trashëgon rrugën e saktë pa u prekur.

Nëse porta shpërndan adresën e saj si opsion DHCP, shpërndani rrugën në atë mënyrë që makinat e reja ta marrin automatikisht. Përndryshe rruga jeton në një skedar konfigurimi dhe zhduket në rindërtimin tjetër.

# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14

Pse NAT-i i burimit duket se e rregullon

Maskimi i grupit të klientëve pas adresës së serverit VPN e heq problemin duke hequr adresën e klientit nga paketa. Përgjigjet kthehen pastaj te serveri, i cili tashmë e di se si të arrijë tunelin, dhe gjithçka funksionon. Kostoja është që hostet e brendshme nuk mund të shohin më kush është klienti, dhe çdo lidhje duket se vjen nga një makinë e vetme.

Ky shkëmbim ndonjëherë është i saktë, për shembull kur një pajisje e një furnizuesi nuk mund të marrë një rrugë statike. Mos e bëni rregullin më të gjerë se grupi aktual, sepse një rregull i shkruar për /24 pushon së përputhuri ditën kur grupi rinumërohet në /16, dhe shenja e parë është një grup klientësh të rinj që lidhen dhe nuk arrijnë asgjë.

iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v

Rruga në re kërkon tre rregullime

Në një VPC e njëjta boshllëk kthehet në një formë tjetër, sepse nënrrjeti nuk ka fare rrugë për intervalin e klientëve. Tabela e rrugëzimit ka nevojë për një zë për grupin e tunelit që synon ndërfaqen e rrjetit të instancës, dhe ndërfaqja duhet ta ketë kontrollin e burimit dhe destinacionit të çaktivizuar që platforma të pranojë paketa burimi i të cilave nuk është adresa e saj. Grupet e sigurisë dhe ACL-të e rrjetit duhet gjithashtu ta lejojnë grupin në të dy drejtimet.

Çdo heqje prodhon një dështim të pjesshëm të veçantë. Hiqni zërin e tabelës së rrugëzimit dhe instancat private përgjigjen në një nënrrjet që nuk mund ta çojë përgjigjen përsëri në grup. Me kontrollin ende aktiv, platforma e hedh përgjigjen pasi instanca e ka dërguar tashmë. Pa rregullin e grupit të sigurisë vetë kërkesa nuk mbërrin kurrë, dhe klienti e sheh skadimin e kohës një shtresë më herët.

Kryeni kontrollet në këtë rend

Konfirmoni përcjelljen dhe politikën e filtrimit përpara se të fajësoni rrugëzimin, sepse një host që nuk do të përcjellë dështon në të njëjtën mënyrë të heshtur. Më pas lexoni rregullimin efektiv të rrugës së kthimit në ndërfaqen që mbart tunelin, pasi një filtër i rreptë mund të hedhë përgjigje që vijnë nga një drejtim i papritur.

Përfundoni me një kapje të marrë në hostin e LAN-it ndërsa klienti i bën ping. Një kërkesë që mbërrin pa përgjigjen përkatëse vërteton rrugën e kthimit, dhe një kërkesë që nuk mbërrin kurrë e kthen fajin te serveri ose tuneli.

sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp

Kontrolli i burimit dhe destinacionit dokumentohet në udhëzuesin e ndërfaqes elastike të rrjetit. Vendoseni në ndërfaqen që mbart vërtet trafikun e tunelit, jo në një përshtatës të palidhur të bashkangjitur në të njëjtën instancë.