Varför en källportsregel bryter en av dina SSH-vägar

Två administrationsingångar på en värd, en serviceport och en policyregel som skulle hjälpa båda. Regeln matchar källport 22, skickar uppslaget till en tabell som bara känner till WAN-standarden, och VPN-ingången slutar svara på nya inloggningar medan den direkta ingången fortsätter att fungera. Inget av detta är mystiskt när väljaren läses korrekt. En källport identifierar en tjänst, inte vägen en anslutning kom in på.

Två ingångar, en serviceport

Värden har en adress på LAN-sidan och en VPN-adress, och sshd lyssnar på båda. En direkt session och en tunnelsession delar därför serviceporten och skiljer sig bara i vilken lokal adress som tar emot anslutningen.

Den skillnaden räcker för att välja en svarsväg, och det är precis den skillnad en portbaserad regel kastar bort. Båda sessionerna producerar svar vars källport är 22, så en regel som matchar den porten kan inte skilja dem. Den skickar båda uppslagen till samma tabell, och ett av dem får ett svar som inte passar. Rättelsen är att matcha det attribut som faktiskt skiljer sig.

Att ge varje ingång sin egen port skulle också fungera, och att behandla det som ett krav är ett designval, inte en egenskap hos SSH.

Läs regeln, sedan tabellen

En policyregel är en ordnad väljare, och den första som returnerar ett användbart svar avslutar uppslaget. Läs listan i ordning och notera vilken regel som kan vinna.

Läs sedan tabellen som regeln pekar på, eftersom en regel som löses med framgång inte är en regel som löses användbart. En tabell med bara en standardrutt skickar svaret med VPN-ursprung ut genom WAN-gränssnittet. En mer specifik rutt i en senare tabell konsulteras aldrig, och därför ändrar det så ofta ingenting att lägga till en andra tabell. Den valda tabellen är det som måste undersökas.

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

De två utskrifterna förklarar tillsammans resultatet; var för sig inbjuder de till en felaktig slutsats.

Begränsa regeln till det flöde du menar

Attributet som skiljer de två ingångarna är den lokala källadressen. En regel som matchar den adressen skickar bara tunnelsessionerna till den privata tabellen och låter direkta sessioner stanna på huvudtabellen.

Den regeln måste paras med en tabell som innehåller den privata rutten och returvägen för det subnätet. Begränsa båda till administrationstrafik i stället för varje tjänst på värden. En regel som fångar all trafik från den adressen kommer också att omdirigera allt annat värden skickar därifrån. Smalt slår smart här, eftersom nästa person måste läsa 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

Om båda ingångarna översätts till en lokal adress försvinner den skillnaden, och designen behöver i stället anslutningsmedvetet tillstånd.

Håll lyssnare, behörighet och svarsval åtskilda

Tre separata saker måste vara sanna innan en session fungerar: adressen finns, tjänsten lyssnar på den, och svaret hittar vägen tillbaka. En ruttändring åtgärdar bara det tredje.

Lyssnarkonfigurationen är sin egen fil och sin egen omladdning, och flera lyssnaradresser är normala. Autentisering är återigen ett tredje beslut, och ett routingundantag ger ingen åtkomst. Behåll värdnyckelverifiering, kontoautentisering och källbegränsningar på båda ingångarna, och motstå frestelsen att försvaga tunnelns övriga kontroller så att en administrationsväg fungerar.

Håll en återställningskanal som inte beror på vägen du ändrar, eftersom ett fel här låser ute själva rättelsen.

Bevisa det med en ny session, inte en gammal

En etablerad terminal bevisar ingenting, eftersom den släpptes in före ändringen. Öppna en ny session genom varje avsedd ingång.

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

Upprepa sedan VPN-återanslutningen och försök igen, eftersom en rutt som överlever en återanslutning inte är samma sak som en som läggs till i en tabell som återanslutningen tömmer. Observera de nekade källorna separat från de tillåtna, så att ett blockerat försök inte gömmer sig bakom en fungerande session. Spara den lokala adressen, regeln och tabellen bredvid resultatet. Om du i stället delar portarna, registrera det som ett driftbeslut och inte som en begränsning i SSH.