Hvorfor en kildeport-regel ødelægger en af dine SSH-veje

To administrative indgange på én vært, én serviceport og en politikregel, der skulle hjælpe begge. Reglen matcher kildeport 22, sender opslaget til en tabel, der kun kender WAN-standardruten, og VPN-indgangen holder op med at svare på nye logins, mens den direkte indgang fortsætter med at virke. Intet af det er mystisk, når selektoren læses korrekt. En kildeport identificerer en tjeneste, ikke den vej en forbindelse kom ind ad.

To indgange, én serviceport

Værten har en adresse på LAN-siden og en VPN-adresse, og sshd lytter på begge. En direkte session og en tunnel-session deler derfor serviceporten og adskiller sig kun ved, hvilken lokal adresse der modtager forbindelsen.

Denne forskel er nok til at vælge en svarvej, og det er præcis den forskel, en portbaseret regel kasserer. Begge sessioner producerer svar med kildeport 22, så en regel, der matcher den port, kan ikke skelne dem. Den sender begge opslag til samme tabel, og det ene af dem får et svar, der ikke passer. Rettelsen er at matche den egenskab, der faktisk adskiller sig.

At give hver indgang sin egen port ville også virke, og at behandle det som et krav er et designvalg snarere end en egenskab ved SSH.

Læs reglen, læs derefter tabellen

En politikregel er en ordnet selektor, og den første, der returnerer et brugbart svar, afslutter opslaget. Læs listen i rækkefølge, og bemærk hvilken regel der kan vinde.

Læs derefter den tabel, reglen peger på, fordi en regel, der opløses med succes, ikke er en regel, der opløses nyttigt. En tabel med kun en standardrute sender svaret med VPN-oprindelse ud gennem WAN-grænsefladen. En mere specifik rute i en senere tabel konsulteres aldrig, og derfor ændrer tilføjelsen af en anden tabel så ofte intet. Den valgte tabel er det, der skal undersøges.

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

De to output forklarer tilsammen resultatet; hvert af dem alene inviterer til en forkert konklusion.

Begræns reglen til det flow, du mener

Den egenskab, der adskiller de to indgange, er den lokale kildeadresse. En regel, der matcher den adresse, sender kun tunnel-sessionerne til den private tabel og lader direkte sessioner blive på hovedtabellen.

Den regel skal parres med en tabel, der indeholder den private rute og returvejen for det subnet. Begræns begge til administrationstrafik i stedet for hver tjeneste på værten. En regel, der fanger al trafik fra den adresse, vil også omdirigere alt andet, værten sender derfra. Smalt slår smart her, fordi den næste person skal læse 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 indgange oversættes til én lokal adresse, forsvinder den forskel, og designet har brug for forbindelsesbevidst tilstand i stedet.

Hold lytter, tilladelse og svarvalg adskilt

Tre separate ting skal være sande, før en session virker: adressen findes, tjenesten lytter på den, og svaret finder vej tilbage. En ruteændring retter kun det tredje.

Lytterkonfiguration er sin egen fil og sin egen genindlæsning, og flere lytteadresser er normale. Godkendelse er igen en tredje beslutning, og en routing-undtagelse giver ingen adgang. Hold værtsnøgleverifikation, kontogodkendelse og kildebegrænsninger på begge indgange, og modstå fristelsen til at svække tunnelens andre kontroller, så én administrativ vej virker.

Hold en genopretningskanal, der ikke afhænger af den vej, du ændrer, fordi en fejl her låser selve rettelsen ude.

Bevis det med en ny session, ikke en gammel

En etableret terminal beviser intet, da den blev lukket ind før ændringen. Åbn en frisk session gennem hver tilsigtet indgang.

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

Gentag derefter VPN-genopkoblingen, og prøv igen, fordi en rute, der overlever en genopkobling, ikke er det samme som en, der er føjet til en tabel, som genopkoblingen tømmer. Observer de afviste kilder adskilt fra de tilladte, så et blokeret forsøg ikke gemmer sig bag en fungerende session. Gem den lokale adresse, reglen og tabellen ved siden af resultatet. Hvis du i stedet deler portene, skal du registrere det som en driftsbeslutning snarere end som en begrænsning i SSH.