Låt en OpenVPN-klient nå en annan via SSH utan att öppna poolen

En klient behöver nå en annan klients SSH-tjänst, och resten av poolen bör förbli lika isolerad som i dag. Den frestande växeln är client-to-client, som slår på peer-åtkomst för alla på en gång och ger beslutet till OpenVPN i stället för till kärnan. Ett snävare svar håller den växeln avstängd och låter serverns egen routning och brandvägg bära exakt ett flöde.

Mekanismen betyder mer än regeltexten, eftersom de två angreppssätten placerar paketet på olika ställen. Att veta vilket du valde förklarar både regeln som verkar göra ingenting och peeren som ansluter utan den.

Vart client-to-client flyttar paketet

Med client-to-client påslaget vidarebefordrar servern ett peer-paket internt i stället för att skicka ut det igen genom tunnelenheten, så paketet når aldrig kärnans vidarebefordringsväg. Det är bekvämt och betyder också att din brandvägg aldrig ser det flöde den skulle övervaka. Låt alternativet vara av och servern dirigerar paketet ut igen genom samma gränssnitt, vilket sätter det framför netfilter. Samma gränssnitt in, samma gränssnitt ut, och FORWARD-kedjan får rösten.

Byten är tydlig: du vinner en policypunkt och tar på dig routnings- och vidarebefordringsarbetet som genvägen gjorde för dig. Det arbetet är litet för ett enda flöde och växer med varje undantag du lägger till. Räkna undantagen nu, för det är i regeluppsättningen som policyn mellan peers faktiskt bor.

Vägen som ett peer-paket faktiskt tar

Anta en Linux Community OpenVPN 2.6-tjänst, TUN-behandling i användarutrymmet i stället för DCO, subnätstopologi, tun0 och en pool på 10.44.0.0/24 med klient A på 10.44.0.21 och klient B på 10.44.0.37. Med subnätstopologi täcker adressen och nätmasken som A fick redan poolen, så A skickar paketet till tunnelenheten utan en extra pushad rutt. Kontrollera den effektiva rutten på A i stället för att anta en.

På servern anländer paketet adresserat till B, vilket inte är en lokal adress, så det vidarebefordras. IPv4-vidarebefordran måste vara på för att det överhuvudtaget ska ske, och ruttuppslaget måste skicka paketet ut igen genom tun0. Brandväggen ser därför ett vidarebefordrat flöde med samma gränssnitt på båda sidor, och det är detaljen som de flesta regeluppsättningar missar. Här behövs ingen källöversättning, och det är genom att hålla A:s adress intakt som B kan tillämpa sin egen källbaserade regel.

Två regler på servern, i den här ordningen

Tre regler bär hela tillståndet: vidarebefordran, parundantaget och en standard-drop för tunnelparet. Acceptera-regeln namnger paret och tjänsten, så tillståndet överlever en pool som växer. Placera den före varje generell nekande av tunnel-till-tunnel-trafik, eftersom första träffen vinner:

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

De kommandona är illustrativa och hör hemma i vilken mekanism din värd än använder för att bevara regler; en insättning vid körning försvinner vid nästa start. Det är den tillståndsfulla regeln som låter B:s svar och TCP-handskakningen komma tillbaka utan en andra, speglad acceptans.

Kontrollera räknarna efteråt i stället för regellistan, eftersom en regel som aldrig matchar ser identisk ut med en som fungerar. Om räknarna stannar på noll tar paketet inte den väg du tror.

Vad B fortfarande måste tillåta

B kör SSH-tjänsten, så B avgör om något lyssnar på tunneladressen och om den egna värdbrandväggen accepterar källan. Ett nätverkstillstånd på servern är inte tillstånd för något konto på B, och värdnyckelverifiering och användarautentisering gäller fortfarande som från var som helst annars.

Testa det positiva fallet först: en ny SSH-anslutning från A till B:s tunneladress, accepterad med den förväntade värdnyckeln. Testa sedan en annan peer eller en annan port och bekräfta att den nekas, för ett tillstånd som tyst tillåter allt går inte att skilja från ett som fungerar förrän det spelar roll. Båda halvorna av det testet behövs, och den andra är den folk hoppar över.

Skriv ner de tilldelade adresserna, de effektiva rutterna på båda klienterna och de exakta reglerna på servern och på B. En lyckad ping till gatewayen eller en öppen port på servern bevisar inget av detta, eftersom båda kan vara sanna medan vidarebefordran mellan peers fortfarande är blockerad. Skriv ner de siffrorna medan tunneln är uppe, för adressen som en klient får efter en återanslutning kan vara en annan.