Offentligt prefix via OpenVPN: reparera returvägen

Se tunneln komma upp och klienten pinga andra sidan, och sedan svarar en offentlig adress som hör hemma bakom VPN:en från någon annanstans, eller inte alls. Det symptomet har oftast inget med chiffer eller certifikat att göra. Ett prefix som leverantören routar levereras som en IP-rutt, och att bära det över OpenVPN innebär att återskapa rutten på två nivåer och bevara källadressen på returvägen. Det är inte nödvändigt att broa WAN:et, och att lägga till adressen på ett gränssnitt skapar inte den uppströms rutten.

Prefixet måste först routas till dig

Fråga leverantören hur blocket levereras. Ett prefix som routas till serverns huvudadress är något annat än adresser som leverantören förväntar sig att nå direkt på ett WAN-segment. Bara den första modellen fungerar med designen här.

Om leverantören routar 198.51.100.64/28 till din ingångsserver kommer paketen för det intervallet till servern och stannar där om du inte vidarebefordrar dem. Om leverantören i stället broar intervallet till din uplink måste servern svara på ARP för det, vilket är ett annat problem.

Testa leveransmodellen innan du rör OpenVPN: pinga en adress i blocket utifrån och se vilket gränssnitt som tar emot den. Om inget kommer hjälper ingen tunnelkonfiguration. Om adressen svarar direkt på WAN:et broar leverantören i stället för att routa, och designen nedan gäller inte.

Två routingnivåer: kärnrutt och iroute

OpenVPN behöver prefixet på två ställen. Kärnan måste veta att prefixet tillhör tunneenheten, så att vidarebefordrade paket går in i OpenVPN i stället för standardrutten. OpenVPN måste också veta vilken autentiserad klient som äger prefixet, och det är iroute-posten i den klientspecifika katalogen.

Rutten på serversidan ser ut så här, och prefixet och masken måste matcha tilldelningen:

ip route add 198.51.100.64/28 dev tun0

Den klientspecifika konfigurationen tilldelar ägarskap. Lägg den i CCD-filen som är uppkallad efter klientcertifikatets vanliga namn, och bekräfta att just den katalogen är den servern faktiskt läser:

iroute 198.51.100.64 255.255.255.240

OpenVPN:s dokumentation om routade nätverk beskriver båda nivåerna och varför de är åtskilda. En kärnrutt utan iroute skickar paket in i tunneln utan ägare, och OpenVPN kastar dem. En iroute utan kärnrutten lämnar paketen på serverns standardväg. Båda felen ser ut som en trasig tunnel från klientsidan.

Var tjänstadressen bor

Det delegerade prefixet är inte samma sak som tunnelns egna adresser. Numrera länken från det privata utrymmet om du vill, och placera den offentliga tjänstadressen där tjänsten faktiskt körs.

På en Linux-klient som avslutar tjänsten lokalt räcker en enda värdadress:

ip address add 198.51.100.70/32 dev lo

Om prefixet routas vidare till en VM-värd eller ett annat LAN, konfigurera i stället den nedströmsvägen och dess returrutt. Det är inte nödvändigt att tilldela varje adress i blocket till VPN-klienten, och det skapar konflikter senare.

Behåll den offentliga källan på returvägen

Ett svar från det delegerade prefixet måste lämna tunneln och nå leverantörens rutt. Om fjärrvärden skickar det via sin egen ISP ser källadressen förfalskad ut, och leverantören eller destinationen kastar det. Lösningen är en källbaserad regel eller en dedikerad routingtabell, inte en bredare NAT. Utan den fungerar tjänsten från tunnelpartnern och misslyckas överallt annars.

På ingångsservern är en bred masquerade-regel den vanliga boven. Den skriver om den offentliga källan till serverns huvudadress, och klienten ser aldrig den riktiga:

iptables -t nat -S POSTROUTING

Begränsa NAT till de privata VPN-klienter som behöver det och låt det delegerade prefixet vara oöversatt. Bekräfta sedan att servern vidarebefordrar prefixet överhuvudtaget, eftersom en vidarebefordringskedja med standardavvisning kastar det tyst.

Verifiera båda riktningarna innan du litar på det

Verifieringen är fyra observationer, inte en. Bekräfta att leverantörens rutt anländer, att kärnan skickar prefixet in i tunneln, att OpenVPN tilldelar det till rätt klient, och att svaret kommer tillbaka med den offentliga källan intakt. Varje observation har sitt eget kommando, så ett fel pekar på ett lager i stället för hela designen. Kör dem i den ordningen efter varje konfigurationsändring.

Fråga kärnan vilken väg en delegerad adress tar, och följ tunneln medan en begäran körs:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Filtrering av omvänd väg kan ogiltigförklara en korrekt rutt. Kontrollera den effektiva inställningen på tunneln och på uplinken, och kom ihåg att ett strikt läge avvisar trafik vars källa inte matchar gränssnittet den kom in på:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Till sist, testa felet. Stoppa tunneln och bekräfta att det offentliga prefixet inte läcker ut genom den vanliga uplinken. Att återställa VPN:en bör föra tillbaka tjänsten utan att utöka vilka portar värden exponerar.