Varför OpenVPN-klienter missar gatewayens IPsec-väljare

Pinga en värd bakom den avlägsna IPsec-tunneln från gatewayen och den svarar rent, så tunneln ser frisk ut och ärendet går vidare. Sedan försöker en ansluten klient samma värd och får ingenting tillbaka. Den pinget var aldrig bevis för klientens flöde, eftersom den gick ut med gatewayens egen källadress och matchade en annan IPsec-väljare. Att förstå varför de två fallen skiljer sig är det mesta av rättelsen.

Gatewayens ping testar ett flöde som din klient aldrig använder

Källadressen avgör vilken policy som gäller. Ett paket som skapas på gatewayen går ut med en adress från dess lokala LAN eller från tunnelns ändpunkt, och policyn som matchar det skrevs just för det fallet. En klients paket kommer in på OpenVPN-gränssnittet med en adress från klientpoolen, vilket är en helt annan väljare.

Därför ser felet ut som ett routingproblem när det egentligen är ett policyomfattningsproblem. Nåbarhet från gatewayen bevisar att motparten är uppe och att förslagen förhandlades, och det bevisar ingenting om poolen är skyddad.

Pusha det avlägsna prefix som applikationen faktiskt behöver

Ta det illustrativa paret 10.8.0.0/24 för anslutna klienter och 172.30.239.0/25 för det skyddade avlägsna nätet. Det en klient behöver är en rutt till det andra prefixet, inte till gatewayens LAN och inte till någon annan tunneladress. En rutt som pushas till poolen är det som får klienten att lämna över trafiken till gatewayen över huvud taget. Utan den når paketet aldrig det policybeslut du felsöker.

På en Community-server som accepterar pushade rutter tar direktivet den riktiga masken: push "route 172.30.239.0 255.255.255.128". Access Server konfigurerar samma mål via den installerade versionens inställningar för privat nätverk eller åtkomstregler, med routat eller översatt läge valt medvetet. Att redigera genererade brandväggskedjor i stället för den ägande konfigurationen är hur en fungerande installation blir omöjlig att återskapa.

Efter anslutning, läs klientens routingtabell i stället för serverns avsikt. En rutt som bara täcker poolen betyder att pushen aldrig kom fram, och en standardrutt genom tunneln är bredare än detta krav och kommer att överraska dig senare. Kontrollera masken såväl som prefixet, eftersom ett /25 som pushas som /24 skickar trafik för grannadresser in i en väg som inte kan bära den. Bekräfta sedan att klienten valde tunnelgränssnittet för det målet.

Låt väljarna omfatta klientpoolen

För routad åtkomst som bevarar klientadresser, måste IPsec-policyn skydda trafik mellan poolen och det avlägsna prefixet. Väljare skrivna för gatewayens eget LAN släpper igenom pinget och släpper klientens begäran, och det är precis den asymmetri som startade denna undersökning.

Granska den förhandlade policyn såväl som de konfigurerade förslagen, till exempel med ipsec statusall på strongSwan eller motsvarande statuskommando för din implementation. Med policybaserad IPsec kan den vanliga rutten peka på ett fysiskt gränssnitt medan matchande trafik fortfarande krypteras, så en saknad tunnelenhet bevisar ingenting. Jämför väljar paren med poolen och prefixet du skrev ned.

Generisk käll-NAT på gatewayen kan också bryta matchningen. Om en masquerade-regel skriver om klientens källa före policykontrollen ser paketet inte längre ut som väljaren du skrev. Det är en anledning till att en bred masquerade-regel är en dålig lösning för ett andra VPN: den ändrar vilken policy som gäller och vilken adress den avlägsna sidan loggar. Undanta trafiken du vill routa, eller översätt den medvetet och uppdatera väljarna.

Välj routning eller översättning med avsikt

Routning håller klientadressen synlig för den avlägsna sidan, så avlägsna loggar och regler per källa förblir meningsfulla, och det kräver att den avlägsna gatewayen känner till returvägen till poolen. Översättning döljer poolen bakom en enda adress, vilket tar bort returruttproblemet och förstör identiteten per klient.

Välj en design och skriv ned den, eftersom de två behöver olika väljare och en annan brandväggsordning. En halvt tillämpad masquerade hamnar mellan dem och tillfredsställer ingen av dem. Det nedskrivna valet är också det som låter nästa ingenjör skilja ett fel från ett medvetet beslut.

Slut cirkeln vid vidarebefordran och svaret

Gatewayen måste vidarebefordra protokollet och målet du avser, vilket betyder att IP-vidarebefordran är på och att en vidarebefordringskedja tillåter paret. Den avlägsna sidan måste sedan skicka svar tillbaka via IPsec-vägen, och det är ett routingbeslut på deras gateway och inte din. Båda halvorna är vanlig konfiguration, och båda lämnas lätt halvfärdiga. Testa dem var för sig så att en saknad vidarebefordringsregel inte tas för en trasig tunnel.

Verifiera med en riktig begäran från klient till applikation och se den passera OpenVPN-gränssnittet, IPsec-beslutet och den avlägsna värden. Granska svaret som en separat observation, eftersom en begäran som anländer och ett svar som aldrig kommer tillbaka ser likadana ut från klientens plats. En spårad begäran är värd mer än vilket antal pingar från gatewayen som helst.

Håll målauktoriseringen snäv medan du testar, och bekräfta att en klient utan regeln inte når tjänsten. En installerad rutt plus en etablerad association är inte samma sak som beviljad åtkomst.