Varför hemma-NAT inte skyddar ditt VPN-gränssnitt
En hemmarouter vidarebefordrar tunneln, men värden bedömer det dekrypterade paketet. Läs lyssnaren, den inre vägen och ingångspolicyn var för sig.
Bärbara datorer bakom en hemmarouter utan portvidarebefordran accepterar fortfarande SSH-anslutningar som kommer över VPN. Det är ingen motsägelse, eftersom två olika enheter bedömer två olika paket. Routern vidarebefordrar den krypterade transporten, och värden avgör vad som ska hända med det dekrypterade paketet som når dess tunnelgränssnitt. Att hålla de två besluten åtskilda är hela övningen.
Routern vidarebefordrar tunneln, värden bedömer paketet
Rita vägen från den avlägsna källan till tjänsten innan du tittar på en enda regel. Den yttre delen är VPN-transporten, som hanteras av routern och gatewayen. Den inre delen börjar när slutpunkten tar bort tunnellagret och värden tar emot ett paket som är adresserat till dess VPN-adress.
Slå ihop de två delarna och routern får äran för ett beslut som värden fattar. En sida för portvidarebefordran eller en routerlogg beskriver bara yttre samtal, och ingen av dem säger vilken dekrypterad trafik värden kommer att acceptera. Värden tillämpar sin egen ingångspolicy på det inre paketet, på samma sätt som på varje paket som anländer till ett gränssnitt. Det är i den policyn exponeringsfrågan faktiskt avgörs.
En jokertecken-lyssnare är inte en offentlig tjänst
På Linux innebär bindning till INADDR_ANY varje lokal adress, så en tjänst kan svara på ett tunnelgränssnitt som den aldrig har namngett. IP-socketreferensen beskriver den bindningen, och den är värd att läsa innan du drar slutsatser från en lyssnarlista. En jokerteckenpost är ett faktum om socketen, inte ett påstående om nåbarhet.
De två raderna nedan är samma tjänst i två olika bindningar, och skillnaden är hela svaret på om gränssnittet spelar roll. Läs vilken adress socketen sitter på före allt annat.
ss -lntp "sport = :22"
LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=812,fd=3))
LISTEN 0 4096 10.8.0.6:22 0.0.0.0:* users:(("sshd",pid=812,fd=4))
Namnge det arrangemang som skulle kunna nå porten
Tre arrangemang sätter ett paket på det gränssnittet, och de har olika ägare. Att namnge det rätta avgör vem som måste ändra en policy.
| Arrangement | What reaches the port | Where the decision lives |
|---|---|---|
| Another permitted VPN peer | A packet from the same tunnel subnet | Gateway forwarding policy and host input rules |
| A deliberate public forward | Traffic the gateway publishes on purpose | Gateway service definition |
| A subnet routed behind the gateway | Client traffic from the far side | Gateway route and host input rules |
Ett webbläsarresultat som visar en offentlig utgångsadress säger ingenting om någon av de tre, eftersom det beskriver hur utgående trafik lämnar snarare än vad ingående trafik tillåts. Arbeta baklänges från lyssnaren och källadressen i tjänsteloggen i stället. Om källan är en annan tunnelpeer är gatewaypolicyn det intressanta dokumentet. Om det är en översatt adress, hitta översättningen innan du ändrar en regel.
Begränsa tjänsten till den väg du avsåg
Om SSH bara behövs från en administrationsväg, skriv ner den vägen som ett källområde plus ett gränssnitt. Begränsa sedan värdens ingångsregler efter gränssnitt, mål och källa i stället för efter nätverksnamn, eftersom ett namn som ser privat ut kan stå för vilken adress som helst. Behåll en rutt för personen som ska lösa nästa problem.
nft add rule inet filter input iifname "tun0" ip saddr 10.8.0.0/24 tcp dport 22 accept
nft list chain inet filter input
En regel som namnger tunnelgränssnittet och administrationsområdet uttrycker avsikten på ett ställe. Jämför den med en regel skriven för Wi-Fi-nätverket, som inte säger något om dekrypterad tunneltrafik. När de två lagren inte är överens är det värdens policy som paketet möter.
Låt inloggningar och patchningar stanna exakt där de är; att nå en port har aldrig varit samma sak som att ha tillåtelse att använda den. Anteckna adressfamilj och tid för varje okänd källa, och undersök innan du skyller på en funktion eller en sårbarhet. En regel som släpper in varje tunnelpeer är en annan design än en som släpper in ett administrationssubnät, och ingen logglinje kommer att säga vilken som var avsedd.
Acceptera rättelsen med en framgång och en vägran
Bevisa båda halvorna: en godkänd anslutning lyckas och en utesluten väg nekas. Vägran är den halva folk hoppar över, och det är den som visar att regeln gör arbete i stället för att stå bredvid ett tillåtande standardvärde. Testa från den uteslutna sidan i stället för att resonera om det.
Upprepa paret efter en återanslutning, eftersom en tunnel som kommer tillbaka med ett annat gränssnittsnamn tyst kan kringgå en regel som är begränsad till den gamla. Gränsen som spelar roll är den som värden tillämpar på paket som den faktiskt tar emot.