Cloud-firewall kontra værts-firewall til en VPN-server

Tillad VPN-porten i cloudpolitikken, og håndtrykket kan alligevel dø på instansen: gæsten kører sit eget filter og sin egen listener-binding, og begge kan kassere det, som clouden godkendte. Det modsatte sker også, når en værtsregel tillader porten, og en politik længere oppe kasserer den først. To ejere, to regelsæt, én pakkevej. Gå den igennem i rækkefølge i stedet for at gætte på det mest mistænkelige lag.

Start ved kanten og gå indad

Rækkefølgen er fast: offentligt endepunkt, ressourceinterface, tilknyttet cloudpolitik, gæsteadresse, proceslistener, lokale inputregler. Hvert trin slipper pakken igennem eller afslutter undersøgelsen, og derfor spilder man mest tid på at starte ved gæsten.

Videresendt klienttrafik er et særskilt trin, som inspiceres efter tunellen er afkapslet. Cloudlaget ser kun den ydre tunell, så det kan godkende en forbindelse og alligevel intet have med en indre serviceanmodning at gøre. En tunell, der forbinder, men ikke kan nå en intern vært, peger som regel på videresendelse, ikke på en lukket port.

Læs cloudpolitikken, før du rører gæsten

Bekræft inputreglen for VPN-porten, dens protokol og det kildeomfang, der matcher din testklient. Tjek også subnetets adgangskontrolliste: et andet filter med sine egne regler og standarder. Begge skal tillade flowet, før en pakke når instansen. En tilladelse i det ene og en afvisning i det andet er den sædvanlige form for denne fejl.

Indsnævr omfanget, til det betyder noget. At åbne VPN-porten mod hele internettet er let at bevise og svært at forsvare, mens en regel låst til én adresse knækker, når din testklient skifter netværk. Notér regel-id og politikejer, så den næste ændring kan spores til en person.

Bekræft listeneren, derefter inputkæden

På instansen skal du kontrollere, at VPN-processen er bundet til den adresse og port, du forventer, for eksempel med ss -lntp 'sport = :1194'. En daemon, der kun er bundet til 127.0.0.1, accepterer lokale klienter og intet gennem tunellen, hvilket udefra ser præcis ud som en filtreret port.

Læs derefter de lokale regler i den syntaks, du ville bruge til at ændre dem, såsom iptables -S INPUT eller nft list chain inet filter input. En regel, der er skrevet til en fil, men aldrig indlæst, eller et standard-drop uden en matchende tilladelse, kasserer pakker i stilhed. Til en videresendende gateway skal du også tjekke indstillingerne for videresendelse og omvendt sti. De bestemmer, hvad der sker med pakker, der routes gennem instansen i stedet for at være adresseret til den.

Stateful i det ene lag, stateless i det næste

Sikkerhedsgrupper husker de flows, de tillod, og lukker svarene ind igen. Subnet-adgangskontrollister og mange værts-firewalls holder ingen sådan tilstand, så en regel, der kun dækker den udgående retning, slipper anmodningen igennem og kasserer svaret. Overfør aldrig en antagelse om returtrafik mellem lag, uden at læse det andet lags regel (second layer's rule).

Tællere afgør det hurtigere end at læse hver regel i kontoen. En tæller, der stiger, betyder, at pakken nåede frem og blev kasseret der, mens en frosset på nul betyder, at den aldrig kom så langt; iptables -vnL INPUT og nft list ruleset viser de tal, når reglerne blev indlæst med tællere.

Test med en frisk session, ikke en levende

Lad kildenettet og testprofilen være i fred, mens du sammenligner visninger, og åbn en ny forbindelse efter hver ændring. At nå webkonsollen på 443 siger intet om, hvorvidt VPN-daemonen er bundet til 1194, så test den port, du har brug for. En eksisterende session er det dårligste vidne her. Den fortsætter med at virke, mens hvert nyt login afvises.

Før du redigerer en fjernpolitik, skal du have en vej tilbage, som ikke afhænger af den sti, du ændrer. Åbn derefter en anden administrationssession ved siden af VPN-testen: en, der blev etableret tidligere, kan overleve den regel, der blokerer nye. Notér begge politikejere, så ingen genopbygning gendanner halve stien; hvis begge lag er enige, og tunellen stadig fejler, så optag på gæstens interface og tjek den adresse og port, klienten faktisk bruger.