Hvorfor hjemme-NAT ikke beskytter VPN-grensesnittet ditt
En hjemmeruter videresender tunnelen, men verten vurderer den dekrypterte pakken. Les lytteren, den indre veien og inngangspolicyen hver for seg.
Bærbare datamaskiner bak en hjemmeruter uten portvideresending godtar fortsatt SSH-tilkoblinger som kommer over VPN. Det er ingen motsetning, fordi to forskjellige enheter vurderer to forskjellige pakker. Ruteren videresender den krypterte transporten, og verten bestemmer hva som skal skje med den dekrypterte pakken som når tunnelgrensesnittet. Å holde de to beslutningene fra hverandre er hele øvelsen.
Ruteren videresender tunnelen, verten vurderer pakken
Tegn veien fra den eksterne kilden til tjenesten før du ser på en eneste regel. Den ytre delen er VPN-transporten, som ruteren og gatewayen håndterer. Den indre delen begynner når endepunktet fjerner tunnellaget og verten mottar en pakke adressert til VPN-adressen sin.
Slå sammen de to delene, og ruteren får æren for en beslutning verten tar. En side for portvideresending eller en ruterlogg beskriver bare ytre samtaler, og ingen av dem sier hvilken dekryptert trafikk verten vil godta. Verten bruker sin egen inngangspolicy på den indre pakken, på samme måte som på enhver pakke som kommer til et grensesnitt. Det er i den policyen eksponeringsspørsmålet faktisk avgjøres.
En jokerlytter er ikke en offentlig tjeneste
På Linux betyr binding til INADDR_ANY enhver lokal adresse, så en tjeneste kan svare på et tunnelgrensesnitt den aldri har navngitt. IP-socketreferansen beskriver den bindingen, og den er verdt å lese før du trekker konklusjoner fra en lytterliste. En jokerpost er et faktum om socketen, ikke en påstand om tilgjengelighet.
De to linjene nedenfor er den samme tjenesten i to forskjellige bindinger, og forskjellen er hele svaret på om grensesnittet betyr noe. Les hvilken adresse socketen sitter på før alt annet.
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))
Navngi ordningen som kunne nå porten
Tre ordninger setter en pakke på det grensesnittet, og de har forskjellige eiere. Å navngi den riktige avgjør hvem som må endre 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 |
Et nettleserresultat som viser en offentlig utgangsadresse sier ingenting om noen av de tre, fordi det beskriver hvordan utgående trafikk forlater, snarere enn hva inngående trafikk har lov til. Arbeid baklengs fra lytteren og kildeadressen i tjenesteloggen i stedet. Hvis kilden er en annen tunnelpeer, er gatewaypolicyen det interessante dokumentet. Hvis det er en oversatt adresse, finn oversettelsen før du endrer en regel.
Begrens tjenesten til veien du mente
Hvis SSH bare er nødvendig fra en administrasjonsvei, skriv den veien ned som et kildeområde pluss et grensesnitt. Begrens deretter vertens inngangsregler etter grensesnitt, mål og kilde i stedet for etter nettverksnavn, siden et navn som ser privat ut kan stå for hvilken som helst adresse. Behold en rute for personen som skal løse det neste problemet.
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 navngir tunnelgrensesnittet og administrasjonsområdet, uttrykker hensikten på ett sted. Sammenlign den med en regel skrevet for Wi-Fi-nettverket, som ikke sier noe om dekryptert tunneltrafikk. Når de to lagene er uenige, er vertens policy den pakken møter.
La innlogginger og oppdateringer være nøyaktig der de er; å nå en port har aldri vært det samme som å ha lov til å bruke den. Noter adressefamilien og tidspunktet for enhver ukjent kilde, og undersøk før du gir en funksjon eller en sårbarhet skylden. En regel som slipper inn hver tunnelpeer er et annet design enn en som slipper inn et administrasjonssubnett, og ingen logglinje vil si hvilken som var ment.
Godta rettelsen med én suksess og én avvisning
Bevis begge halvdeler: én godkjent tilkobling lykkes, og én utelukket vei avvises. Avvisningen er den halvdelen folk hopper over, og det er den som viser at regelen gjør arbeid i stedet for å stå ved siden av en tillatende standardverdi. Test fra den utelukkede siden i stedet for å resonnere om det.
Gjenta paret etter en gjenoppkobling, fordi en tunnel som kommer tilbake med et annet grensesnittnavn, stille kan omgå en regel som er begrenset til det gamle. Grensen som betyr noe, er den verten bruker på pakker den faktisk mottar.