Molnbrandvägg kontra värdbrandvägg för en VPN-server

Tillåt VPN-porten i molnprincipen och handskakningen kan ändå dö på instansen: gästen kör sitt eget filter och sin egen lyssnarbindning, och båda kan kasta det som molnet godkände. Det omvända händer också, när en värdregel tillåter porten och en princip högre upp kastar den först. Två ägare, två regeluppsättningar, en paketväg. Gå den i ordning i stället för att gissa på det mest misstänkta lagret.

Börja vid kanten och gå inåt

Ordningen är fast: offentlig slutpunkt, resursgränssnitt, kopplad molnprincip, gästadress, processlyssnare, lokala indataregler. Varje steg släpper igenom paketet eller avslutar utredningen, och därför slösar man mest tid på att börja hos gästen.

Vidarebefordrad klienttrafik är ett eget steg som inspekteras efter att tunneln avkapslats. Molnlagret ser bara den yttre tunneln, så det kan godkänna en anslutning och ändå inte ha något med en intern tjänstebegäran att göra. En tunnel som ansluter men inte når en intern värd pekar oftast på vidarebefordran, inte på en stängd port.

Läs molnprincipen innan du rör gästen

Bekräfta indataregeln för VPN-porten, protokollet och källomfånget som matchar din testklient. Kontrollera också subnätets åtkomstlista: ett andra filter med egna regler och standardvärden. Båda måste tillåta flödet innan ett paket når instansen. En tillåtelse i den ena och en nekad i den andra är den vanliga formen av det här felet.

Snäva in omfånget tills det betyder något. Att öppna VPN-porten mot hela internet är lätt att bevisa och svårt att försvara, medan en regel fäst vid en adress går sönder när testklienten byter nätverk. Anteckna regelidentiteten och principens ägare, så att nästa ändring går att spåra till en person.

Bekräfta lyssnaren, sedan indatakedjan

På instansen, kontrollera att VPN-processen är bunden till den adress och port du förväntar dig, till exempel med ss -lntp 'sport = :1194'. En daemon som bara är bunden till 127.0.0.1 tar emot lokala klienter och inget genom tunneln, vilket utifrån ser precis ut som en filtrerad port.

Läs sedan de lokala reglerna i den syntax du skulle använda för att ändra dem, som iptables -S INPUT eller nft list chain inet filter input. En regel som skrivits till en fil men aldrig lästs in, eller ett standardkast utan matchande tillåtelse, kastar paket i tysthet. För en gateway som vidarebefordrar, kontrollera också inställningarna för vidarebefordran och returväg. De avgör vad som händer med paket som dirigeras genom instansen i stället för att adresseras till den.

Stateful i ett lager, stateless i nästa

Säkerhetsgrupper minns de flöden de tillät och släpper in svaren igen. Åtkomstlistor för subnät och många värdbrandväggar håller ingen sådan status, så en regel som bara täcker utgående riktning släpper igenom begäran och kastar svaret. Överför aldrig ett antagande om returtrafik mellan lager utan att läsa det andra lagrets regel (second layer's rule).

Räknare avgör detta snabbare än att läsa varje regel i kontot. En räknare som stiger betyder att paketet kom fram och kastades där, medan en som frysts på noll betyder att det aldrig kom så långt; iptables -vnL INPUT och nft list ruleset visar de siffrorna när reglerna lästes in med räknare.

Testa med en färsk session, inte en levande

Låt källnätverket och testprofilen vara i fred medan du jämför vyer, och öppna en ny anslutning efter varje ändring. Att nå webbkonsolen på 443 säger inget om huruvida VPN-daemonen är bunden till 1194, så testa porten du behöver. En befintlig session är det sämsta vittnet här. Den fortsätter att fungera medan varje ny inloggning avvisas.

Innan du redigerar en fjärrprincip, säkra en väg tillbaka som inte beror på den väg du ändrar. Öppna sedan en andra administrationssession vid sidan av VPN-testet: en som upprättats tidigare kan överleva regeln som blockerar nya. Anteckna båda principernas ägare så att ingen återuppbyggnad återställer halva vägen; om båda lagren är överens och tunneln ändå misslyckas, fånga på gästens gränssnitt och kontrollera adressen och porten som klienten faktiskt använder.