Pse një përgjigje UDP e OpenVPN del nga adresa e gabuar

Një klient OpenVPN thërret një adresë, serveri përgjigjet nga një tjetër, dhe tuneli nuk ngrihet kurrë. Regjistri i serverit tregon paketën që mbërrin dhe një kapje tregon një përgjigje që del, prandaj defekti i atribuohet klientit. Në një host me disa ndërfaqe, ose me disa adresa në një ndërfaqe, dy palët thjesht nuk bien dakord se cila adresë është në përdorim. Përgjigja është e vlefshme në shtresën IP, megjithatë shumë klientë hedhin poshtë një datagram, burimi i të cilit nuk është adresa që kontaktuan.

Çfarë sheh klienti kur ndryshon burimi

Një socket UDP që nuk është i lidhur me një adresë të caktuar lokale nuk ka burim fiks, prandaj kerneli zgjedh një në momentin e dërgimit. Kjo zgjedhje vjen nga një kërkim rruge drejt adresës së klientit, dhe burimi bëhet adresa e ndërfaqes që zgjedh kërkimi. Në një makinë me një ndërfaqe zgjedhja është e padukshme; në një host me adresë administrimi, adresë publike dhe adresë dytësore në të njëjtën kartë rrjeti, varet nga metrikat dhe politika e rrugëtimit. Rrugëtimi i bazuar në politika e bën mospërputhjen më të mundshme dhe jo më pak, sepse një rregull mund të zgjedhë një lidhje sipërme ku klienti nuk arriti kurrë. Mjafton një rrugë e paracaktuar e mësuar nga një ofrues plus një rregull burimi që tregon një tjetër.

Klientët që filtrojnë përgjigjet, dhe gjurmimi i lidhjeve që pret katërshen e saktë dhe burimin, do ta hedhin përgjigjen pa një mesazh të dobishëm. Atëherë tuneli skadon sikur të mos kishte mbërritur asgjë, dhe kjo është arsyeja pse kjo merret gabimisht si problem i murit të zjarrit në anën e klientit. Një kapje e bërë vetëm në server e konfirmon gabimin në vend që ta shpjegojë, sepse përgjigja vërtet del. Krahasoni burimin e përgjigjes me adresën që thirri klienti përpara se të ndryshoni çdo gjë tjetër.

Çfarë bën në të vërtetë opsioni multihome

Direktiva shkruhet si multihome në një skedar konfigurimi dhe si --multihome në rreshtin e komandës, dhe e bën një server UDP të përgjigjet nga adresa ku arriti paketa e klientit. Kerneli e dorëzon adresën origjinale të destinacionit si të dhëna shtesë gjatë marrjes, dhe OpenVPN e përdor atë vlerë si burim të përgjigjes. Kështu një server që dëgjon në një adresë të përgjithshme, local 0.0.0.0 për IPv4 ose ekuivalenti i tij IPv6, sillet sikur çdo klient të kishte arritur një dëgjues të dedikuar. Klientët që erdhën përmes adresës publike marrin përgjigje nga adresa publike, dhe klientët në një adresë të brendshme i marrin nga ajo. Asgjë tjetër në rrugën e paketës nuk lëviz: rruga, rregullat e filtrit dhe konfigurimi i tunelit mbeten saktësisht ashtu si ishin.

Pikërisht kjo veti e fundit e bën opsionin të sigurt për t'u shtuar në një server që funksionon ndryshe, dhe është gjithashtu arsyeja pse nuk mund të rregullojë një filtër që lejon vetëm një adresë. Paketa ende duhet të pranohet në rrugën që ndjek, prandaj korrigjimi i burimit ndryshon origjinën e përgjigjes dhe asgjë më shumë. Është gjithashtu vetëm për UDP: një dëgjues TCP nuk e ka këtë problem në të njëjtën formë, sepse lidhja identifikohet nga katërshe dhe jo nga adresa e burimit të përgjigjes.

Kur një adresë lokale fikse është parazgjedhja e gabuar

Përpara se t'i drejtoheni opsionit, kontrolloni nëse serveri lidh një adresë të caktuar lokale, sepse një dëgjues i lidhur përgjigjet gjithmonë nga ajo adresë. Kjo është e saktë për një vendosje me një ndërfaqe dhe e gabuar sapo klientët përdorin ligjërisht më shumë se një adresë. Nëse lidhja ishte e qëllimshme, vendosni nëse serveri duhet të pranojë trafik në adresa shtesë. Heqja e lidhjes rrit ekspozimin, prandaj ndërfaqet dhe rrjetet burimore të lejuara duhet t'i zbatojnë shërbimi dhe filtri, jo vetëm adresa e lidhjes.

Referenca e OpenVPN e kufizon opsionin te serverët UDP, shënon përpunimin shtesë në rrugën e paketës dhe regjistron cilat platforma e mbështesin. Konfirmojeni këtë në versionin e instaluar përpara se të planifikoni mbi të. Aty ku nuk mbështetet, alternativa është lidhja e adresës specifike ose rregullimi i rrugës së kthimit, dhe të dyja janë ndryshime më të ngushta sesa duken në shikim të parë. Dëgjimi në adresë të përgjithshme ka pasoja edhe përtej përgjigjeve: një server në të gjitha adresat është i arritshëm nga çdo rrjet ku hosti është i lidhur, dhe ky mund të mos jetë ekspozimi që dikush kishte ndërmend.

Provoni burimin e përgjigjes nga jashtë

Testoni nga jashtë serverit, dhe regjistroni adresën dhe transportin e saktë që përdori klienti përpara se të kapni çdo gjë. Tre provat më poshtë përgjigjen tre pyetjeve të ndryshme, dhe radha ka rëndësi.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Kapja tregon adresën e burimit në përgjigje, dhe ky është fakti mbi të cilin qëndron i gjithë artikulli. Lista e socket-ëve tregon se çfarë lidhi vërtet serveri, sepse një dëgjues i përgjithshëm dhe një i caktuar duken njëlloj në një skedar konfigurimi dhe sillen ndryshe në rrjet. Kërkimi i rrugës tregon burimin që kerneli do të zgjidhte për atë rrjedhë, dhe kjo e shpjegon kapjen përpara se të ndryshoni çdo gjë. Përsëritini të tria për IPv4 dhe IPv6 veçmas, sepse janë dëgjues të veçantë dhe kërkime të veçanta, dhe një zë i përgjithshëm për një familje nuk thotë asgjë për tjetrën.

Rrugëtimi, zbulimi dhe filtrimi mbeten të ndarë

Ruajtja e burimit të përgjigjes nuk instalon një rrugë dalëse, nuk përditëson DNS dinamik dhe nuk bën që një familje adresash të pranojë tjetrën. Në një server me disa lidhje sipërme, rruga e kthimit për çdo burim duhet të bihet dakord qëllimisht, përndryshe përgjigjet dalin përmes një ndërfaqeje që filtri i klientit nuk e lejoi kurrë. Po ashtu, një adresë e re pas një ndryshimi prefiksi duhet të arrijë klientët përmes zbulimit dhe rrjedhës së rilidhjes së mbështetur, jo përmes regjistrimit të vjetër.

Lërini kontrollet e identitetit të serverit dhe verifikimin e certifikatave saktësisht ashtu si janë, sepse një adresë e ndryshuar nuk justifikon pranimin e një pale të paverifikuar. Nëse përgjigja tani del nga burimi i synuar dhe tuneli prapë dështon, konsiderojeni problemin e burimit të zgjidhur dhe vazhdoni. Gabimi i radhës i vërejtur i përket rrugëtimit, filtrimit ose vërtetimit, dhe ndryshimi përsëri i dëgjuesit nuk do ta arrijë atë. Shkruani burimin e përgjigjes në biletë pranë adresës që thirri klienti, që personi tjetër të mund të kontrollojë të njëjtin fakt me një komandë të vetme.