Klienti lidhet, tuneli transporton ping deri te porta dhe asgjë përtej saj nuk përgjigjet. Ky gjendje është normale për një portë që është menduar gjithmonë vetëm për akses në rrjete të mbrojtura, dhe është defekt për një portë të reklamuar si dalje e tunelit të plotë. Përpara se të ndryshoni rregulla, konfirmoni cila shërbim u premtua. Më pas ndiqni një kërkesë publike nëpër katër vendet ku mund të ndalet. Një kërkesë dhe një regjistrim paketash zgjidhin më shumë se një faqe supozimesh.

Konfirmoni nëse dalja në internet ishte ndonjëherë projektimi

Profili i tunelit të ndarë drejton në VPN vetëm nënrjetet e mbrojtura, kështu që shfletimi publik vazhdon përmes lidhjes lokale dhe nuk e prek kurrë portën. Profili i tunelit të plotë instalon një rrugë të parazgjedhur në tunel, çka e bën portën përgjegjëse për të gjithë rrugën. Të dyja janë projektime legjitime, dhe ngatërrimi i tyre prodhon një raport defekti atje ku nuk ka. Lexoni rrugët e shpallura nga klienti përpara se të provoni çdo gjë tjetër, sepse tabela e rrugëve përgjigjet pyetjes që bileta zakonisht e parashtron gabim.

Ajo që instalon klienti nuk është gjithmonë ajo që synon profili. Një rrugë e shtyrë mund të mbizotërohet nga një rrugë lokale me metrikë më të ulët, dhe një klient që mban rrugën e LAN-it ndërsa shton një rrugë të parazgjedhur sillet si tunel i ndarë për atë nënrrjet.

Ndiqni një kërkesë publike

Zgjidhni një destinacion të vetëm dhe ndiqeni nga klienti nga jashtë. Në klient kontrolloni nëse paketa zgjedh vërtet tunelin dhe cilën adresë lokale përdor si burim. Më pas kontrolloni portën: a arrin paketa dhe a largohet nga ndërfaqja publike. Secila prej këtyre përgjigjeve heq një kategori të plotë shkaku.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Nëse porta nuk e sheh kurrë paketën, rruga e klientit ose zgjedhja e tunelit është e gabuar. Nëse arrin dhe nuk largohet, problemi është në portë dhe zbatohen tre kontrollet e mbetura.

Kontrolloni përcjelljen, rrugën dhe përkthimin

Udhëzuesi i përcjelljes që vjen me strongSwan vlen për një portë të çdo lloji tuneli: kerneli duhet të lejohet të lëvizë paketa midis ndërfaqeve, dhe një rrugë e përdorshme duhet të tregojë drejt internetit. Politika e murit të zjarrit duhet më pas të lejojë trafikun, dhe adresa e burimit duhet të jetë një të cilën pala publike mund t'i përgjigjet. Një adresë private klienti e përcjellë e pandryshuar në internet nuk merr kurrë përgjigje.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Përkthimi i burimit është pjesa e zakonshme që mungon. Me të, porta e rishkruan burimin e klientit në adresën e vet publike dhe ndjek rrjedhën; pa të, përgjigja nuk ka ku të shkojë. Platformat e resë shtojnë një kufi të dytë, ku tabela e rrugëve ose grupi i sigurisë i instancës mund të hedhë poshtë trafik që muri i zjarrit i mysafirit e lejon. Ky kufi është i lehtë për t'u anashkaluar, sepse sistemi i mysafirit duket i konfiguruar saktë nga brenda.

Filtrimi i rrugës së kundërt në një konfigurim asimetrik mund gjithashtu të hedhë poshtë paketa të vlefshme. Lexoni numëruesin e atij rregulli në vend që të supozoni se është në rregull, sepse një konfigurim i rreptë në ndërfaqen publike refuzon trafikun që vjen nga një rrugë tjetër nga ajo që parashikon tabela e rrugëve.

Rruga e përgjigjes dhe zgjidhësi janë dy përgjigje të ndryshme

Ndjekni edhe përgjigjen, jo vetëm kërkesën. Nëse kërkesa del e përkthyer dhe përgjigja kthehet në rrjedhën e përkthyer, përcjellja punon edhe kur aplikacioni ende dështon, dhe hetimi i radhës i takon aplikacionit ose DNS-it.

Një sajt që kthen një gabim HTTP është provë që përcjellja në internet punon. Një emër që nuk zgjidhet ndërsa aksesi me adresë punon është problem zgjidhësi, jo problem NAT.

Pas një korrigjimi të ngushtë, ritestoni klientin dhe çdo burim privat të kufizuar me qëllim. Dhënia e aksesit në internet nuk duhet të zgjerojë në heshtje aksesin në çdo rrjet të lidhur me portën.

Artikuj të ngjashëm