Hvorfor hjemme-NAT ikke beskytter din VPN-grænseflade
En hjemmerouter videresender tunnelen, men værten vurderer den dekrypterede pakke. Læs lytteren, den indre vej og inputpolitikken hver for sig.
Bærbare computere bag en hjemmerouter uden portforwarding accepterer stadig SSH-forbindelser, der ankommer over VPN. Det er ikke en modsigelse, fordi to forskellige enheder vurderer to forskellige pakker. Routeren videresender den krypterede transport, og værten beslutter, hvad der skal ske med den dekrypterede pakke, der når dens tunnelgrænseflade. At holde de to beslutninger adskilt er hele øvelsen.
Routeren videresender tunnelen, værten vurderer pakken
Tegn vejen fra den eksterne kilde til tjenesten, før du ser på en enkelt regel. Det ydre ben er VPN-transporten, som håndteres af routeren og gatewayen. Det indre ben begynder, når endepunktet fjerner tunnellaget, og værten modtager en pakke adresseret til dens VPN-adresse.
Flet de to ben sammen, og routeren får æren for en beslutning, værten træffer. En portforwarding-side eller en routerlog beskriver kun ydre samtaler, og ingen af dem siger, hvilken dekrypteret trafik værten vil acceptere. Værten anvender sin egen inputpolitik på den indre pakke, på samme måde som på enhver pakke, der ankommer til en grænseflade. Det er i den politik, eksponeringsspørgsmålet faktisk afgøres.
En jokerlytter er ikke en offentlig tjeneste
På Linux betyder binding til INADDR_ANY enhver lokal adresse, så en tjeneste kan svare på en tunnelgrænseflade, den aldrig har navngivet. IP-socketreferencen beskriver den binding, og den er værd at læse, før du drager konklusioner fra en lytterliste. En jokerpost er et faktum om socketen, ikke en udtalelse om tilgængelighed.
De to linjer nedenfor er den samme tjeneste i to forskellige bindinger, og forskellen er hele svaret på, om grænsefladen betyder noget. Læs, hvilken adresse socketen sidder på, før alt andet.
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))Navngiv den ordning, der kunne nå porten
Tre ordninger sætter en pakke på den grænseflade, og de har forskellige ejere. At navngive den rigtige afgør, hvem der skal ændre en politik.
| 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 |
Et browserresultat, der viser en offentlig udgangsadresse, siger intet om nogen af de tre, fordi det beskriver, hvordan udgående trafik forlader, snarere end hvad indgående trafik har lov til. Arbejd baglæns fra lytteren og kildeadressen i tjenesteloggen i stedet. Hvis kilden er en anden tunnelpeer, er gatewaypolitikken det interessante dokument. Hvis det er en oversat adresse, find oversættelsen, før du ændrer en regel.
Afgræns tjenesten til den vej, du tilsigtede
Hvis SSH kun er nødvendig fra en administrationsvej, så skriv den vej ned som et kildeområde plus en grænseflade. Afgræns derefter værtens inputregler efter grænseflade, destination og kilde i stedet for efter netværksnavn, da et navn, der ser privat ud, kan stå for enhver adresse. Behold en rute til den person, der skal løse det næste 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 inputEn regel, der navngiver tunnelgrænsefladen og administrationsområdet, angiver hensigten ét sted. Sammenlign den med en regel skrevet til Wi-Fi-netværket, som intet siger om dekrypteret tunneltrafik. Når de to lag er uenige, er værtens politik den, pakken møder.
Lad logins og patching være præcis, hvor de er; at nå en port har aldrig været det samme som at have lov til at bruge den. Noter adressefamilien og tidspunktet for enhver ukendt kilde, og undersøg, før du giver en funktion eller en sårbarhed skylden. En regel, der tillader hver tunnelpeer, er et andet design end en, der tillader et administrationssubnet, og ingen loglinje vil fortælle, hvilken der var tilsigtet.
Accepter rettelsen med én succes og én afvisning
Bevis begge halvdele: én godkendt forbindelse lykkes, og én udelukket vej afvises. Afvisningen er den halvdel, folk springer over, og det er den, der viser, at reglen gør arbejde i stedet for at stå ved siden af en tilladende standard. Test fra den udelukkede side i stedet for at ræsonnere om det.
Gentag parret efter en genopkobling, fordi en tunnel, der vender tilbage med et andet grænsefladenavn, stille kan omgå en regel, der er afgrænset til den gamle. Den grænse, der betyder noget, er den, værten anvender på pakker, den faktisk modtager.