Cloudfirewall versus hostfirewall voor een VPN-server

Sta de VPN-poort toe in het cloudbeleid en de handshake kan alsnog op de instantie sterven: de gast draait zijn eigen filter en zijn eigen listener-binding, en beide kunnen weggooien wat de cloud goedkeurde. Het omgekeerde gebeurt ook, wanneer een hostregel de poort toestaat en een beleid daarboven hem eerst laat vallen. Twee eigenaren, twee regelsets, één pakketpad. Loop het in volgorde af in plaats van te gokken op de verdachtste laag.

Begin bij de rand en ga naar binnen

De volgorde ligt vast: openbaar eindpunt, resource-interface, gekoppeld cloudbeleid, gastadres, proceslistener, lokale invoerregels. Elke fase laat het pakket door of beëindigt het onderzoek, en daarom kost beginnen bij de gast de meeste tijd.

Doorgestuurd clientverkeer is een aparte fase, die wordt geïnspecteerd nadat de tunnel is gedecapsuleerd. De cloudlaag ziet alleen de buitenste tunnel, dus kan een verbinding goedkeuren en toch niets met een interne serviceaanvraag te maken hebben. Een tunnel die verbindt maar geen interne host bereikt, wijst meestal op doorsturen, niet op een gesloten poort.

Lees het cloudbeleid voordat je de gast aanraakt

Bevestig de inkomende regel voor de VPN-poort, het protocol en de bronomvang die bij je testclient past. Controleer ook de toegangslijst van het subnet: een tweede filter met eigen regels en standaardwaarden. Beide moeten de stroom toestaan voordat een pakket de instantie bereikt. Een toestemming in het ene en een weigering in het andere is de gebruikelijke vorm van deze fout.

Vernauw de omvang tot het iets betekent. De VPN-poort voor het hele internet openzetten is makkelijk te bewijzen en moeilijk te verdedigen, terwijl een regel die aan één adres vastzit breekt wanneer je testclient van netwerk wisselt. Noteer de regel-ID en de eigenaar van het beleid, zodat de volgende wijziging naar een persoon te herleiden is.

Bevestig de listener, dan de invoerketen

Controleer op de instantie of het VPN-proces aan het adres en de poort gebonden is die je verwacht, bijvoorbeeld met ss -lntp 'sport = :1194'. Een daemon die alleen aan 127.0.0.1 gebonden is, accepteert lokale clients en niets via de tunnel, wat van buiten precies op een gefilterde poort lijkt.

Lees daarna de lokale regels in de syntaxis die je zou gebruiken om ze te wijzigen, zoals iptables -S INPUT of nft list chain inet filter input. Een regel die naar een bestand is geschreven maar nooit is geladen, of een standaard-drop zonder passende toestemming, gooit pakketten stil weg. Controleer voor een doorsturende gateway ook de instellingen voor doorsturen en terugweg. Die bepalen wat er gebeurt met pakketten die via de instantie worden gerouteerd in plaats van daaraan geadresseerd.

Stateful in de ene laag, stateless in de volgende

Beveiligingsgroepen onthouden de stromen die ze hebben toegestaan en laten de antwoorden weer binnen. Toegangslijsten van subnetten en veel hostfirewalls houden geen dergelijke status bij, dus een regel die alleen de uitgaande richting dekt, laat het verzoek door en gooit het antwoord weg. Neem nooit een aanname over retourverkeer tussen lagen mee zonder de regel van de tweede laag te lezen (second layer's rule).

Tellers beslissen dit sneller dan elke regel in het account te lezen. Een teller die oploopt betekent dat het pakket aankwam en daar werd weggegooid, terwijl een teller die op nul staat betekent dat het nooit zo ver kwam; iptables -vnL INPUT en nft list ruleset tonen die aantallen wanneer de regels met tellers zijn geladen.

Test met een verse sessie, niet met een levende

Laat het bronnetwerk en het testprofiel met rust terwijl je weergaven vergelijkt, en open na elke wijziging een nieuwe verbinding. De webconsole op 443 bereiken zegt niets over of de VPN-daemon aan 1194 gebonden is, dus test de poort die je nodig hebt. Een bestaande sessie is hier de slechtste getuige. Hij blijft werken terwijl elke nieuwe login wordt geweigerd.

Zorg voor een terugweg die niet afhangt van het pad dat je wijzigt, voordat je een beleid op afstand bewerkt. Open daarna een tweede beheersessie naast de VPN-test: een die eerder is opgezet, kan de regel overleven die nieuwe blokkeert. Noteer beide beleidseigenaren zodat geen herbouw de helft van het pad herstelt; als beide lagen het eens zijn en de tunnel toch faalt, leg dan vast op de interface van de gast en controleer het adres en de poort die de client werkelijk gebruikt.