Një gateway VPN kërkon përcjellje IP: çfarë duhet kontrolluar

Klienti juaj mund të pingojë adresën e gateway-it ndërsa çdo burim pas tij mbetet i paarritshëm. Ky çift vëzhgimesh përshkruan një host që flet me ju dhe një ruter që nuk ruteron, të cilat janë role të ndryshme në të njëjtën makinë. Përcjellja është ndërprerësi midis tyre.

Të dy rolet janë të pavarura, dhe po ashtu të dy familjet e adresave.

Përgjigjja në adresën e vet nuk provon asgjë

Kur një paketë adresohet drejt vetë gateway-it, stack-u lokal e konsumon dhe nuk merret asnjë vendim përcjelljeje. Kjo është arsyeja pse një ping i suksesshëm drejt adresës së tunelit ose një ndërfaqeje administrimi ju thotë se daemon-i është gjallë dhe tuneli është lart, pa thënë asgjë për trafikun e destinuar për një rrjet pas kutisë. Kernel-i konsulton rrugën e tij të përcjelljes vetëm për paketat që nuk adresohen drejt tij.

Lexojeni kërkesën si rol, jo si cilësim: ky host duhet të lëvizë paketa midis dy ndërfaqeve. Një laptop që duhet vetëm të arrijë një rrjet të largët nuk e merr kurrë atë rol, dhe një pikë fundore site-në-site e merr gjithmonë. Leximi i kërkesës në këtë mënyrë shpjegon pse një konfigurim klienti që funksionon dështon kur zhvendoset në një gateway.

E njëjta fjali vlen për murin e zjarrit përpara vendimit të përcjelljes, i cili ka politikën e vet për atë që mund të përcillet.

Kontrolloni çdo familje adresash veçmas

Përcjellja IPv4 është një ndërprerës, dhe përcjellja IPv6 është një tjetër me sjelljen e vet për çdo ndërfaqe. Aktivizimi i të parit nuk thotë asgjë për të dytin, dhe një klient me dy stack-e mund të arrijë gjysmën e një rrjeti ndërsa pjesa tjetër mbetet e errët. Dy klientë nga familje të ndryshme mund, pra, të mos bien dakord për të njëjtin gateway. Pyetni cilën familje përdori klienti që dështon përpara se të modifikoni cilindo cilësim. Konfirmoni të dyja përpara se të përfundoni që dizajni i rrugëtimit është i gabuar.

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

Në shumë shpërndarje vlera që lexoni në kohë ekzekutimi është vendosur atje nga një shërbim ose skedar konfigurimi, kështu që një ndryshim i bërë me një komandë të vetme mund të zhduket në rinisje. Gjeni skedarin që zotëron cilësimin përpara se të modifikoni vlerën e ekzekutimit.

Përcjellja është një nga katër kërkesat

Një rrjedhë e përcjellë që funksionon kërkon katër gjëra njëkohësisht: klienti duhet të dijë se destinacioni është pas tunelit, gateway-i duhet të ketë një rrugë përpara, përgjigjet duhet të kenë një rrugë kthimi, dhe muri i zjarrit duhet të lejojë trafikun. Përkthimi i burimit bën pjesë në atë dizajn si opsion dhe jo si rregull, sepse një rrjet i ruteruar privat me shtigje simetrike nuk ka nevojë për të, ndërsa një asimetrik zakonisht ka. Secili nga të katërt dështon në mënyrë të pavarur, prandaj riparimi i njërit rrallë lëviz simptomën. Shkruani të katërt përpara se të ndryshoni cilindo.

Platformat e resë shtojnë një konsideratë të pestë. Disa zbatojnë kontrolle burimi dhe destinacioni në instance, gjë që hedh poshtë paketat e përcjella pavarësisht se si është konfiguruar kernel-i i mysafirit. Autoriteti atje është dokumentacioni i rrjetit i vetë platformës, jo output-i i sysctl brenda VM-së.

Testoni nga klienti, jo nga gateway-i

Një test i ekzekutuar në shell-in e vetë gateway-it nuk kalon në asnjë pjesë të rrugës së përcjelljes që sapo aktivizuat. Gjeneroni trafikun nga klienti që ka problemin dhe konfirmoni se ai arrin diçka pas gateway-it dhe jo vetë gateway-in. Ky është i vetmi test që ushtron rolin që ndryshuat.

Mbani rregullat e dëgjuesit dhe rregullat e përcjelljes të ndara në mendje dhe në regjistrin e ndryshimeve. Hapja e portës VPN i pranon klientët në shërbim; nuk u jep asgjë në rrjetin pas saj, dhe të dyja duken njësoj në një listë muri zjarri që është rritur me vite.

Nëse paketat arrijnë dhe shërbimi pastaj e refuzon përdoruesin, ju keni kaluar përtej rrjetit. Vazhdoni me autorizimin e aplikacionit në vend që të zgjeroni përsëri politikën e përcjelljes.