Hvorfor en kildeportregel ødelegger en av SSH-veiene dine

To administrasjonsinnganger på én vert, én tjenesteport og en policyregel som skulle hjelpe begge. Regelen matcher kildeport 22, sender oppslaget til en tabell som bare kjenner WAN-standarden, og VPN-inngangen slutter å svare på nye innlogginger mens den direkte inngangen fortsetter å virke. Ingenting av dette er mystisk når velgeren leses riktig. En kildeport identifiserer en tjeneste, ikke veien en tilkobling kom inn på.

To innganger, én tjenesteport

Verten har en adresse på LAN-siden og en VPN-adresse, og sshd lytter på begge. En direkte økt og en tunneløkt deler derfor tjenesteporten og skiller seg bare i hvilken lokal adresse som tar imot tilkoblingen.

Denne forskjellen er nok til å velge en svarvei, og det er nøyaktig forskjellen en portbasert regel kaster bort. Begge øktene produserer svar der kildeporten er 22, så en regel som matcher den porten, kan ikke skille dem. Den sender begge oppslagene til samme tabell, og ett av dem får et svar som ikke passer. Rettelsen er å matche attributtet som faktisk skiller seg.

Å gi hver inngang sin egen port ville også fungere, og å behandle det som et krav er et designvalg, ikke en egenskap ved SSH.

Les regelen, deretter tabellen

En policyregel er en ordnet velger, og den første som returnerer et brukbart svar, avslutter oppslaget. Les listen i rekkefølge og legg merke til hvilken regel som kan vinne.

Les deretter tabellen regelen peker på, fordi en regel som løses med suksess, ikke er en regel som løses nyttig. En tabell med bare en standardrute sender svaret med VPN-opphav ut gjennom WAN-grensesnittet. En mer spesifikk rute i en senere tabell blir aldri konsultert, og derfor endrer det så ofte ingenting å legge til en andre tabell. Den valgte tabellen er det som må undersøkes.

ip -4 rule show
ip route show table 100
ip route show table main

De to utdataene forklarer sammen resultatet; hver for seg innbyr de til en feil konklusjon.

Begrens regelen til flyten du mener

Attributtet som skiller de to inngangene, er den lokale kildeadressen. En regel som matcher den adressen, sender bare tunneløktene til den private tabellen og lar direkte økter bli på hovedtabellen.

Den regelen må pares med en tabell som inneholder den private ruten og returveien for det subnettet. Begrens begge til administrasjonstrafikk i stedet for hver tjeneste på verten. En regel som fanger all trafikk fra den adressen, vil også omdirigere alt annet verten sender derfra. Smalt slår smart her, fordi neste person må lese det.

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

Hvis begge inngangene oversettes til én lokal adresse, forsvinner den forskjellen, og designet trenger tilkoblingsbevisst tilstand i stedet.

Hold lytter, tillatelse og svarvalg atskilt

Tre separate ting må være sanne før en økt virker: adressen finnes, tjenesten lytter på den, og svaret finner veien tilbake. En ruteendring retter bare det tredje.

Lytterkonfigurasjonen er sin egen fil og sin egen omlasting, og flere lyttadresser er normale. Autentisering er igjen en tredje beslutning, og et routingunntak gir ingen tilgang. Hold vertsnøkkelverifisering, kontoautentisering og kildebegrensninger på begge inngangene, og motstå fristelsen til å svekke tunnelens andre kontroller slik at én administrasjonsvei virker.

Hold en gjenopprettingskanal som ikke avhenger av veien du endrer, fordi en feil her låser selve rettelsen ute.

Bevis det med en ny økt, ikke en gammel

En etablert terminal beviser ingenting, siden den ble sluppet inn før endringen. Åpne en frisk økt gjennom hver tiltenkt inngang.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

Gjenta deretter VPN-gjenoppkoblingen og prøv igjen, fordi en rute som overlever en gjenoppkobling, ikke er det samme som én lagt til i en tabell som gjenoppkoblingen tømmer. Observer de avviste kildene atskilt fra de tillatte, slik at et blokkert forsøk ikke gjemmer seg bak en fungerende økt. Lagre den lokale adressen, regelen og tabellen ved siden av resultatet. Hvis du i stedet deler portene, registrer det som en driftsbeslutning og ikke som en begrensning i SSH.