Cloud vatrozid nasuprot vatrozidu hosta za VPN poslužitelj

Dopustite VPN port u cloud politici i rukovanje ipak može pasti na instanci: gost pokreće vlastiti vatrozid i vlastito vezivanje slušatelja, 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 završna točka, sučelje resursa, pridružena cloud politika, adresa gosta, slušatelj procesa, lokalna ulazna pravila. Svaka faza ili propušta paket ili zaključuje istragu, zato početak na gostu gubi najviše vremena.

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

Pročitajte cloud politiku prije nego što dotaknete gosta

Potvrdite ulazno pravilo za VPN port, njegov protokol i raspon izvora koji odgovara vašem testnom klijentu. Provjerite i popis za kontrolu pristupa podmreže: drugi filtar s 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 ove pogreške.

Suzite raspon dok nešto ne znači. Otvaranje VPN porta prema cijelom internetu lako je dokazati i teško braniti, dok se pravilo vezano uz 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 slušatelj, zatim ulazni lanac

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

Zatim pročitajte lokalna pravila u sintaksi koju biste rabili da ih promijenite, 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 što 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. Popisi za kontrolu pristupa podmreža i mnogi vatrozidi hosta ne čuvaju takvo stanje, pa pravilo koje pokriva samo izlazni smjer propušta zahtjev i odbacuje odgovor. Nikada ne prenosite pretpostavku o povratnom prometu 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 ovdje je 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 sučelju gosta i provjerite adresu i port koje klijent zaista rabi.