A VPN csatlakozva van, a tűzfal mégis blokkol: hogyan állapítsuk meg, melyik

A kliens szerint csatlakozva van, az erőforrás továbbra is elutasít, és a szokásos következő lépés valami kikapcsolása. A mondat két vezérlése különböző munkát végez: a VPN utat épít a lefedett forgalomnak, a tűzfal pedig kapcsolatonként dönti el, hogy a forgalom átmehet-e. Egy működő alagút elutasító házirenddel pontosan úgy néz ki a felhasználó székéből, mint egy törött alagút, ezért a feladat annak megállapítása, melyik réteg válaszol. Íme a sorrend, amit követek, azzal az olvasattal, amely azt mondja, állj meg.

Válasszuk külön az útvonalat a házirendtől

Kezdjük a hiba alakjával, mert az ingyenes információ. A csomag eldobása időtúllépést okoz: a kliens újrapróbálkozik, semmi nem jön vissza, és a parancs addig lóg, amíg fel nem adja. Az elutasítás tagadást vagy visszaállítást okoz: valami válaszolt és nemet mondott. A szolgáltatás, amely nem figyel, magán a gazdagépen utasít el, tűzfal nélkül.

Ez a három kimenet különböző rétegekre mutat. Az időtúllépés azt jelenti, hogy valahol egy házirend csendben eldob, vagy az útvonal soha nem hagyja el a gépet. Az elutasítva azt jelenti, hogy elérted a gazdagépet, és a verme vagy a helyi tűzfala nemet mondott. Teljes csend, felállított alagút-interfésszel és a cél felé vezető útvonal nélkül azt jelenti, hogy az útvonal rossz, és egyetlen tűzfalszabály sem javítja meg.

Olvassuk el az útvonalat egy menetben

Erősítsük meg, hogy az alagút lefedi a célt, mielőtt egyetlen szabályra néznénk. A megosztott alagút, amely csak az irodai alhálózatot viszi, nem irányítja a kérést más tartományba, és akkor a hiba tűzfalblokkolásnak látszik, ami nem az:

ip route get 10.20.4.15
ip -brief address show
wg show
sudo ipsec statusall

Az útvonal kimenete megnevezi az interfészt, amelyen a csomag elhagyja a gépet, és a forrás címet, amelyet viselni fog. Ha ez az interfész a fizikai hálózati kártya és nem az alagút, a probléma az útválasztásban vagy az alagút engedélyezett tartományaiban van, és a VPN konfigurációjához tartozik, nem a tűzfalhoz.

Egy VPN-specifikus csapda külön ellenőrzést érdemel. A WireGuardban a partner AllowedIPs egyszerre útvonal és kriptográfiai szűrő: az a csomag, amelynek forrás címe nem illik a partner engedélyezett halmazába, még azelőtt eldobódik, hogy bármely tűzfalszabályt megnéznének. Így egy teljesen helyes gazdagép-tűzfal állhat egy csendes eldobás mögött, amely házirendnek látszik, és a javítás egy kulcskonfigurációs sor, nem szabály.

Olvassuk el a házirendet abban a rétegben, amely válaszol

Ha az útvonal helyes, járjuk végig a házirendet a gazdagéptől kifelé, és figyeljük azt az egyetlen réteget, amelynek számlálói mozognak:

ss -ltn | grep ':443'
sudo nft list ruleset
sudo iptables -S INPUT
sudo ufw status verbose

A figyelő socket más kérdésre válaszol, mint a szabályok. Ha semmi nem figyel a porton, a kernel elutasítja a kapcsolatot, és egyetlen bejövő szabály sem releváns. Ha a socket létezik, és a kapcsolat egy távoli klienstől lejár, valahol az útvonalon eldobás történik, és a szabályok számlálói megmondják, hogy itt történik-e.

Kapcsoljuk be a naplózást arra a profilra vagy láncra, amelyre gyanakszunk, ahelyett hogy kívülről találgatnánk. Egyetlen naplózott eldobás, amely megnevezi a forrást, a célt és a portot, azonosítja a réteget és a szabályt, és azt is bizonyítja, hogy a csomag megérkezett, amit semmilyen kliensoldali teszt nem tud megállapítani.

Olvassuk el az átjáró döntését, amikor az alagút ott végződik

Helyek közötti vagy távoli hozzáférésű átjárón a VPN hitelesíti a felhasználót, a házirend pedig engedélyezi az erőforrást, és ezek külön engedélyek. Aki bejut az alagútba, az nem automatikusan jut be minden belső gazdagépre, és az elutasítás gyakran továbbítási szabályból jön, miközben maga az alagút egészséges. Ugyanez a szétválasztás jelenik meg az IPsecben, ahol a forgalmat kiválasztó biztonsági házirend különbözik az azt beengedő szűrőtől, és ezért dokumentálják a kettőt különböző mechanizmusként itt: RFC 4301.

Ellenőrizzük a visszautat ugyanolyan gondosan, mint a kimenőt. Az állapotalapú szűrésnek látnia kell a választ, ezért az aszimmetrikus útválasztás az alagúton át az egyik irányban és körülötte a másikban olyan eldobásokat okoz, amelyek véletlenszerűnek látszanak, és csak bizonyos kliensektől ismétlődnek. Ha a forgalom eléri az átjárót és megáll, olvassuk együtt a továbbítási szabályt és a visszautat, mielőtt bármit szélesítenénk.

Az átjáró az a hely is, ahol a NAT- vagy álcázószabály elrejtheti a valódi forrást. Ha a belső gazdagépek az átjáró címét látják a kliens helyett, a kliensmedencére illeszkedő gazdagép-tűzfalszabályaik soha nem fognak illeszkedni, és a javítás az átjáróhoz tartozik, nem minden kiszolgálóhoz.

Módosítsuk a legszűkebb réteget, majd ellenőrizzük

Álljunk ellen a széles javításnak. A gazdagép-tűzfal kikapcsolása, egy mindent engedélyező szabály hozzáadása vagy minden interfész megbízható profilba kényszerítése mindig eltávolítja a vezérlést, amely a dolgát végezte, és a változás túléli az incidenst. A forrástartományra és az érintett portra korlátozott szabály könnyebben átnézhető, könnyebben eltávolítható, és a gép többi házirendjét érintetlenül hagyja.

Ellenőrizzük ugyanazzal a teszttel, amely meghiúsult, ugyanarról a kliensről, majd még egyszer újracsatlakozás után, mert egy szabály, amely az alagút újratárgyalása előtt illeszkedett, utána megszűnhet illeszkedni:

nc -vz 10.20.4.15 443
curl -v --max-time 5 https://10.20.4.15/

Mielőtt lezárjuk:

• A cél felé vezető útvonal az alagút interfészén hagyja el a gépet, és a forráscím megfelel annak, amit a házirend vár.
• Valami figyel a porton, és az elutasítás vagy az időtúllépés egy megnevezett szabályhoz van rendelve, nem feltételezve.
• Az átjáró mindkét irányban továbbít, és a cél látja azt a forrást, amelyre a szabályaidat írták.
• Egyetlen vezérlést sem kapcsoltunk ki, hogy a teszt átmenjen, és az általad tett változás egy forrástartományt és egy portot nevez meg.