Cloud firewall naspram host firewall-a za VPN server

Dozvolite VPN port u cloud politici, a rukovanje ipak može pasti na instanci: gost pokreće vlastiti filter i vlastito vezivanje listenera, i bilo koje od toga može odbaciti ono što je cloud odobrio. Događa se i obrnuto, kada host pravilo dopušta port, a politika iznad njega ga prva odbaci. Dva vlasnika, dva skupa pravila, jedna putanja paketa. Prođite je redom umjesto da nagađate na najsumnjivijem sloju.

Počnite na rubu i krećite se prema unutra

Redoslijed je fiksan: javna krajnja točka, interfejs resursa, priključena cloud politika, adresa gosta, listener procesa, lokalna ulazna pravila. Svaka faza ili propušta paket ili završava istragu, zato početak na gostu gubi najviše vremena.

Proslijeđeni klijentski saobraćaj je zasebna faza koja se pregleda nakon dekapsulacije tunela. Cloud sloj vidi samo vanjski tunel, pa može odobriti vezu i pritom ne imati nikakve veze sa zahtjevom unutrašnje usluge. Tunel koji se povezuje ali ne dolazi do unutrašnjeg hosta obično upućuje na prosljeđivanje, a ne na zatvoren port.

Pročitajte cloud politiku prije nego što dirate gosta

Potvrdite ulazno pravilo za VPN port, njegov protokol i obim izvora koji odgovara vašem testnom klijentu. Provjerite i listu kontrole pristupa podmreže: drugi filter sa vlastitim pravilima i zadanim vrijednostima. Oba moraju dopustiti tok prije nego paket stigne do instance. Dopuštenje u jednom i odbijanje u drugom uobičajen je oblik ovog problema.

Suzite obim dok nešto ne znači. Otvaranje VPN porta prema cijelom internetu lako je dokazati i teško braniti, dok se pravilo vezano za jednu adresu lomi kada vaš testni klijent promijeni mrežu. Zabilježite identifikator pravila i vlasnika politike, da sljedeća izmjena bude sljediva do osobe.

Potvrdite listener, zatim ulazni lanac

Na instanci provjerite je li VPN proces vezan za adresu i port koje očekujete, na primjer pomoću ss -lntp 'sport = :1194'. Daemon vezan samo za 127.0.0.1 prihvata lokalne klijente i ništa kroz tunel, što spolja izgleda tačno kao filtriran port.

Zatim pročitajte lokalna pravila u sintaksi koju biste koristili da ih mijenjate, poput iptables -S INPUT ili nft list chain inet filter input. Pravilo napisano u datoteku ali nikad učitano, ili zadano odbacivanje bez odgovarajućeg dopuštenja, tiho odbacuje pakete. Za gateway koji prosljeđuje provjerite i postavke prosljeđivanja i obrnute putanje. One odlučuju šta se događa s paketima koji se usmjeravaju kroz instancu, a nisu joj adresirani.

Stanje u jednom sloju, bez stanja u sljedećem

Sigurnosne grupe pamte tokove koje su dopustile i puštaju odgovore natrag. Liste kontrole pristupa podmreža i mnogi host firewall-i ne čuvaju takvo stanje, pa pravilo koje pokriva samo izlazni smjer propušta zahtjev i odbacuje odgovor. Nikada ne prenosite pretpostavku o povratnom saobraćaju između slojeva bez čitanja pravila drugog sloja (second layer's rule).

Brojači to rješavaju brže od čitanja svakog pravila na računu. Brojač koji raste znači da je paket stigao i tamo odbačen, a onaj zamrznut na nuli znači da nikad nije dotle stigao; iptables -vnL INPUT i nft list ruleset pokazuju te brojeve kada su pravila učitana s brojačima.

Testirajte svježom sesijom, ne živom

Ne dirajte izvornu mrežu i testni profil dok poredite prikaze, i otvorite novu vezu nakon svake izmjene. Dolazak do web konzole na 443 ne govori ništa o tome je li VPN daemon vezan za 1194, zato testirajte port koji vam treba. Postojeća sesija je ovdje najgori svjedok. Nastavlja raditi dok se svaka nova prijava odbija.

Prije uređivanja udaljene politike osigurajte put natrag koji ne zavisi od putanje koju mijenjate. Zatim otvorite drugu administrativnu sesiju uz VPN test: sesija uspostavljena ranije može nadživjeti pravilo koje blokira nove. Zabilježite oba vlasnika politika da nijedna obnova ne vrati pola putanje; ako se oba sloja slažu, a tunel i dalje ne radi, snimite na interfejsu gosta i provjerite adresu i port koje klijent zaista koristi.