Miért a rossz címről érkezik az OpenVPN UDP-válasza

Egy OpenVPN-kliens egy címre tárcsáz, a szerver egy másikról válaszol, és az alagút soha nem jön létre. A szervernapló mutatja az érkező csomagot, a rögzítés pedig a távozó választ, ezért a hibát a kliensre fogják. Több interfésszel rendelkező gazdagépen, vagy egy interfészen több címmel, a két fél egyszerűen nem ért egyet abban, melyik cím van használatban. A válasz az IP-rétegen érvényes, mégis sok kliens eldobja azt a datagramot, amelynek forrása nem az a cím, amelyet megkerestek.

Mit lát a kliens, amikor a forrás megváltozik

Az UDP-csatorna, amely nincs egy adott helyi címhez kötve, nem rendelkezik rögzített forrással, ezért a kernel küldéskor választ egyet. Ez a választás a kliens címéhez vezető útvonalkeresésből származik, és a forrás annak az interfésznek a címe lesz, amelyet a keresés kiválaszt. Egyinterfészes gépen a választás láthatatlan; olyan gazdagépen, amelyen van kezelési cím, nyilvános cím és másodlagos cím ugyanazon a hálózati kártyán, az útvonal-metrikáktól és a szabályoktól függ. A szabályalapú útválasztás valószínűbbé, nem pedig kevésbé valószínűvé teszi az eltérést, mert egy szabály olyan felső kapcsolatot választhat, amelyet a kliens soha nem ért el. Elég ehhez egy szolgáltatótól tanult alapértelmezett útvonal és egy másikra mutató forrásszabály.

Azok a kliensek, amelyek szűrik a válaszokat, és a kapcsolatkövetés, amely a pontos négyest és a forrást várja, hasznos üzenet nélkül dobják el a választ. Aztán az alagút úgy jár le, mintha semmi nem érkezett volna, és ezért ezt tévesen kliensoldali tűzfalproblémának tartják. A csak a szerveren készült rögzítés megerősíti a hibát ahelyett, hogy megmagyarázná, mert a válasz valóban távozik. Hasonlítsa össze a válasz forrását azzal a címmel, amelyet a kliens tárcsázott, mielőtt bármi mást megváltoztatna.

Mit tesz valójában a multihome beállítás

Az utasítás multihome alakban kerül a konfigurációs fájlba és --multihome alakban a parancssorba, és arra készteti az UDP-szervert, hogy arról a címről válaszoljon, amelyet a kliens csomagja elért. A kernel fogadáskor kiegészítő adatként adja át az eredeti célcímet, és az OpenVPN ezt az értéket használja a válasz forrásaként. Így egy helyettesítő címen figyelő szerver, local 0.0.0.0 az IPv4-hez vagy annak IPv6-os megfelelője, úgy viselkedik, mintha minden kliens külön figyelőt ért volna el. A nyilvános címen érkező kliensek a nyilvános címről kapnak választ, a belső címen lévő kliensek pedig arról a címről. Semmi más nem mozdul a csomag útvonalán: az útvonal, a szűrőszabályok és az alagút konfigurációja pontosan úgy marad, ahogy volt.

Éppen ez az utolsó tulajdonság teszi biztonságossá a beállítás hozzáadását egy egyébként működő szerverhez, és ez az oka annak is, hogy nem tud megjavítani egy olyan szűrőt, amely csak egy címet engedélyez. A csomagot továbbra is el kell fogadni azon az útvonalon, amelyen halad, tehát a forrás javítása a válasz eredetét változtatja meg, és semmi mást. Ez is csak UDP-re vonatkozik: a TCP-figyelőnél nem ilyen formában jelentkezik ez a probléma, mert a kapcsolatot a négyes azonosítja, nem a válasz forráscíme.

Mikor rossz alapértelmezés a rögzített helyi cím

Mielőtt a beállításhoz nyúlna, ellenőrizze, hogy a szerver egy adott helyi címet köt-e, mert a kötött figyelő mindig arról a címről válaszol. Ez helyes egy egyinterfészes telepítésnél, és helytelen, amint a kliensek jogszerűen több címet használnak. Ha a kötés szándékos volt, döntse el, hogy a szervernek egyáltalán fogadnia kell-e forgalmat további címeken. A kötés eltávolítása növeli a kitettséget, ezért az engedélyezett interfészeket és forráshálózatokat a szolgáltatásnak és a szűrőnek kell kikényszerítenie, nem csak a kötési címnek.

Az OpenVPN-referencia UDP-szerverekre korlátozza a beállítást, megjegyzi a csomagútvonal további feldolgozását, és rögzíti, mely platformok támogatják. Erősítse meg ezt a telepített kiadáson, mielőtt tervezne vele. Ahol nem támogatott, az alternatíva az adott cím kötése vagy a visszaútvonal javítása, és mindkettő szűkebb változtatás, mint amilyennek első pillantásra tűnik. A helyettesítő címen való figyelésnek a válaszokon túl is vannak következményei: az összes címen futó szerver minden hálózatból elérhető, amelyhez a gazdagép csatlakozik, és ez talán nem az a kitettség, amelyet bárki szándékolt.

Bizonyítsa a válasz forrását kívülről

Teszteljen a szerveren kívülről, és rögzítse a pontos címet és átvitelt, amelyet a kliens használt, mielőtt bármit rögzítene. Az alábbi három vizsgálat három különböző kérdésre válaszol, és a sorrend számít.

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

A rögzítés a válasz forráscímét mutatja, és ezen a tényen nyugszik az egész cikk. A csatornalista megmutatja, mit kötött valójában a szerver, mert a helyettesítő és az adott figyelő ugyanúgy néz ki egy konfigurációs fájlban, és másként viselkedik a hálózaton. Az útvonalkeresés megmutatja, melyik forrást választaná a kernel ehhez a folyamhoz, és ez megmagyarázza a rögzítést, mielőtt bármit megváltoztatna. Ismételje meg mindhármat IPv4-re és IPv6-ra külön, mert külön figyelők és külön keresések, és az egyik családra vonatkozó helyettesítő bejegyzés semmit nem mond a másikról.

Az útválasztás, a felderítés és a szűrés külön marad

A válasz forrásának megőrzése nem telepít kimenő útvonalat, nem frissíti a dinamikus DNS-t, és nem éri el, hogy az egyik címcsalád elfogadja a másikat. Több felső kapcsolattal rendelkező szerveren minden forrás visszaútját szándékosan kell egyeztetni, különben a válaszok olyan interfészen hagyják el a gépet, amelyet a kliens szűrője soha nem engedélyezett. Hasonlóképpen, az előtagváltás utáni új címnek el kell jutnia a kliensekhez a felderítésen és a támogatott újracsatlakozási folyamaton keresztül, nem a régi rekordon át.

Hagyja a szerveridentitás-ellenőrzéseket és a tanúsítványok ellenőrzését pontosan úgy, ahogy vannak, mert egy megváltozott cím nem igazolja egy nem ellenőrzött partner elfogadását. Ha a válasz most a szándékolt forrásról távozik, és az alagút továbbra is meghiúsul, tekintse a forrásproblémát megoldottnak, és lépjen tovább. A következő megfigyelt hiba az útválasztáshoz, a szűréshez vagy a hitelesítéshez tartozik, és a figyelő újbóli módosítása nem éri el. Írja be a válasz forrását a jegybe a kliens által tárcsázott cím mellé, hogy a következő ember ugyanazt a tényt egyetlen paranccsal ellenőrizhesse.