A dnsmasq nem tudja lekötni az 53-as portot: keresse meg a socketet, amelyik birtokolja

A dnsmasq azzal áll le, hogy a cím már használatban van, és a napló a portot nevezi meg a bűnös helyett. Egy olyan gépen, amelyen VPN is fut, az első reflex a kényszerített útvonalak hibáztatása, de a bind-hiba még azelőtt bekövetkezik, hogy bármely kliens lekérdezést küldene. Valami már birtokolja a socketet, és a feladat ennek azonosítása. Az útvonalváltoztatás nem szabadít fel egy portot.

Öt lépés ebben a sorrendben: reprodukálja a hibát, listázza a hallgatókat, értse meg a wildcardot, ossza ki a feladatot, majd ellenőrizze.

1. lépés: a hiba reprodukálása és elolvasása

Indítsa el a dnsmasq-t előtérben ugyanazzal a konfigurációval, amelyet a szolgáltatás használ, hogy a hiba a termináljában jelenjen meg, ne egy kitalálandó naplóban. Jegyezze fel az üzenet címcsaládját és helyi címét. Egy adott címre történő bind és a wildcardra történő bind két különböző hiba, különböző tulajdonosokkal.

Őrizze meg a pontos szöveget. A használatban lévő cím, az engedélyhiba és a hiányzó interfész mind indítási hibaként érkezik, és három különböző javításra mutat.

2. lépés: a tulajdonosok listázása

Először listázza a socketeket. A forrásport 53-ra vonatkozó szűrő mindkét átvitelt és a birtokló folyamatot mutatja, ha van jogosultsága látni:

ss -lntup 'sport = :53'

Olvassa a kimenetet oszlopokban: átvitel, helyi cím, port, folyamat. A TCP-hallgató és az UDP-hallgató külön socket, ezért az egyik leállítása nem szabadítja fel a másikat. A wildcard cím minden interfészt lefed, ami azt jelenti, hogy a VPN címe már foglalt, még akkor is, ha egyetlen sor sem nevezi meg. A folyamat neve pedig megmondja, hogy ez egy disztribúció által kezelt feloldó, egy konténer, vagy valami, amit egy korábbi kísérlet futva hagyott.

3. lépés: a wildcard csapdája

A bind-interfaces beállítás eldönti, hogy a dnsmasq wildcard socketet köt-e le, vagy minden beállított interfészhez egy socketet, ahogyan a dnsmasq kézikönyv leírja. Nélküle a dnsmasq lekötetheti a wildcardot, és helyette interfész szerint szűrheti a kéréseket, ami azonnal meghiúsul, ha a wildcardot egy másik daemon birtokolja. A Linux hozzáadja a bind-dynamic beállítást, amely az indítás után létrehozott interfészeket kezeli, valódi aggodalom, amikor a VPN interfész csak csatlakozáskor jelenik meg.

Ezért ütközik két daemon, amelyek mindketten különböző interfészekre beállítottnak tűnnek. Az ütközés a socketnél van, nem a szándéknál. Válassza meg tudatosan a bind módját, és a módosítás előtt olvassa el a verziójához dokumentált viselkedést.

4. lépés: a feladat kiosztása

Döntse el, melyik daemon válaszol a VPN-klienseknek és melyik a gazdagépnek. Egy feloldó, amely az alagút címén hallgat és felfelé továbbít gyakori elrendezés; két feloldó, amelyek mindegyike azt feltételezi, hogy az 53-as portot birtokolja, egyáltalán nem elrendezés.

Ezután fejezze ki ezt a döntést minden szolgáltatás saját konfigurációjában: hallgatócímek, interfészszűrők és továbbítás. Módosítsa őket a szolgáltatás tulajdonosán keresztül, legyen az a disztribúciós egység, a hálózatkezelő vagy a konténer futtatókörnyezete, hogy a változás túlélje az újraindítást.

5. lépés: a socket, majd az útvonal ellenőrzése

Az újraindítás után erősítse meg, hogy a szándékolt socketek léteznek, mielőtt klienst tesztel. Egy daemon, amely soha nem kötött le, nem menthető meg útvonallal, és a kliens hibája egy helyesen lekötött socketnél más probléma, más javítással. Ezután ellenőrizze az elérhetőséget az alagúton lévő kliensről. Csak ezután érdemes megkérdezni, hogy a szükséges nevek feloldódnak-e.

Három külön eredmény, amelyet külön kell tartani: a socket létezik, a kliens eléri, a válasz helyes.

Mit ne tegyen

Ne állítson le egy ismeretlen feloldót a port felszabadításához anélkül, hogy tudná, mi függ tőle, mert a gazdagép saját lekérdezései általában függenek. Ne másoljon el egy régi receptet, amely a második daemont nyilvános hallgatócímre helyezi, mert ez mellékhatásként eldönti, ki kérdezheti Önt. És ne adjon hozzá továbbítást, amikor a hiba helyi volt.

Ha a gépet kezelik, jegyezze fel a tulajdonjogi döntést ott, ahol a következő rendszergazda megtalálja. A portütközések minden alkalommal visszatérnek, amikor egy image újraépül.