A site-to-site VPN csak egy irányban működik: két különböző hiba

Az A hely eléri a B-t, a B nem éri el az A-t, és az alagút mindkét irányban rendben lévőnek látszik. Mielőtt hozzányúlna az alagúthoz, döntse el, melyik hiba áll fenn valójában. A B-n indított és elutasított új kapcsolat, valamint az A-n indított kapcsolatra soha meg nem érkező válasz hasonló panaszokat és teljesen eltérő diagnózisokat eredményez. Az egyik szabályzat- vagy útvonalprobléma az úton; a másik a visszaútvonal vagy az állapot problémája egy már engedélyezett forgalom esetében.

Ez a különbség dönti el, mely parancsokat érdemes futtatni.

Két hiba, amelyek azonosnak látszanak

Az első esetben a B gazdagépe SYN-t küld az A-nak, és semmi nem jön vissza. A másodikban az A gazdagépe sikeresen megnyit egy munkamenetet, és a válasz eltűnik a visszaúton. Mindkét felhasználó egyirányúnak mondja a kapcsolatot, és mindkettő egy eltűnt csomagot ír le, így a leírás önmagában nem képes szétválasztani őket.

Kérdezze meg, melyik fél indította a sikertelen kísérletet. Ez az egyetlen tény a lehetséges okok felét kizárja.

Ezután ellenőrizze, hogy a teszt végig ugyanazokat a gazdagépeket és ugyanazt a szolgáltatást használta. Az egyik oldali ping és a másik oldali fájlmegosztási kapcsolat két különböző dolgot vizsgál, és az átjáróról indított diagnosztika olyan alagútcímet választhat, amelyet semmilyen felhasználói forgalom nem használ.

Első eset: hiányzik a visszaút

Egy távoli kiszolgáló, amely másik alapértelmezett átjárón keresztül válaszol, fogadhatja a kérést, és a választ máshová irányíthatja. Az állapotkövető tűzfalak ekkor eldobják az aszimmetrikus választ, mert az nem illeszkedik egy létrehozott folyamathoz, ami pontosan olyan iránynak látszik, amely soha nem működött. A fordítás egy másik változatot ad hozzá: a cél egy lefordított forrást lát, és arra válaszol, így az eredeti címre írt szabály soha nem illeszkedik.

Ellenőrizze a címet, amelyet a cél a fordítás után valóban lát, és a visszaútvonalat ehhez a címhez, nem az eredeti alhálózathoz.

Második eset: a szabályzat soha nem engedélyezte

Az ellenkező eset egyszerűbb és gyakoribb, mint látszik: egy irodának egy központi szolgáltatást kell fogyasztania, és soha nem szabad kapcsolatot indítania a központ felé. Ez az aszimmetria szándékos hozzáférési döntés, és az alagút a tervezés szerint működik. Olvassa el a hozzáférési szabályzatot, mielőtt bármely alagútbeállítást módosít. Hogy melyik irány volt szándékolt, azt a dokumentum mondja meg, nem a csomagrögzítés. A rögzítés csak azt mutathatja meg, mi történt, nem azt, mi volt engedélyezve.

Ha a kétirányú kezdeményezés valóban szükséges, adja hozzá az adott szolgáltatás engedélyét a platform támogatott szabálykészletén keresztül. Minden alhálózat kölcsönös megbízhatósága egyetlen alkalmazás javításáért szűk követelményből széles engedélyt csinál, és ezt a cserét később ritkán vizsgálják felül.

Hasonlítsa össze az előtte és utána állapotot ugyanazokon a gazdagépeken

Ugyanazon kísérlet mindkét végét figyelje, nem két külön kísérletet. Rögzítsen a kezdeményező gazdagép átjáróján és a célon, majd hasonlítsa össze, mi lépett be, mi ment ki, és milyen címet látott a távoli oldal.

tcpdump -ni any host 10.20.30.40 and port 445
conntrack -L | grep 10.20.30.40
ip route get 10.20.30.40
swanctl --list-sas

Ha a célon készült rögzítés a kérést váratlan forráscímmel mutatja, a válasz a fordításban vagy az útválasztásban van, nem az alagút biztonsági szabályzatában. Ha a cél egyáltalán nem mutat kérést, a csomag soha nem lépte át a védett utat.

Javítás után ismételje meg ugyanazt a tesztet ugyanarról a gazdagépről, és erősítse meg, hogy a nem kapcsolódó hozzáférés továbbra is elutasított. Az “established” alagútállapot önmagában egyik következtetést sem támasztja alá.