Gatewayen är värd för sin egen adminsida: inre eller offentlig adress

En adminsida svarar från en telefon på mobildata och får timeout från en bärbar dator som är ansluten till VPN:en. Inget i tunneln är trasigt, eftersom begäran aldrig kommer in i den. Värdnamnet löses till gatewayens offentliga adress, och den adressen går bara att nå från utsidan av tunneln som den avslutar. Att åtgärda detta innebär att ge tjänsten en privat ingång i stället för att flytta den yttre ändpunkten.

Sidan laddas utifrån och inte genom tunneln

Två olika begäranden jämförs. Från mobildata når webbläsaren den offentliga adressen direkt. Inifrån tunneln löses samma namn till samma offentliga adress, och paketet måste nu lämna tunneln för att nå en adress på tunnelns egen bortre sida. Samma namn, samma adress, två mycket olika positioner.

En destinationsrutt väljer en adress, inte en port. Inget i routingtabellen vet att port 443 är för administration och port 1194 är transporten, så båda behandlas som samma destination.

Det är därför sidan ibland fungerar och ibland inte, beroende på vilket namn och vilket nätverk klienten använde. Det är ett vägproblem och inte ett autentiseringsproblem. Båda klienterna autentiserar alldeles utmärkt.

Håll den yttre ändpunkten nåbar

Profiler för full tunnel behöver en undantagsrutt för VPN-ändpunkten, och OpenVPN:s redirect-gateway-alternativ dokumenterar just det: den fjärra ändpunkten behåller en rutt genom den redan befintliga gatewayen så att tunneln inte routar in i sig själv. Ta bort det undantaget och den krypterade transporten följer tunneln, vilket avslutar sessionen i en loop. Det undantaget är anledningen till att ändpunktsadressen förblir nåbar inifrån tunneln.

Konsekvensen är att den offentliga adressen förblir nåbar från klienten, och det är också därför en webbläsarbegäran till den adressen kan följa samma undantag och gå ut utan att gå in i tunneln. Undantaget gör sitt jobb, och namnet gör skadan.

Läs ruttbeslutet i stället för gränssnittslistan innan du ändrar något. Kommandona nedan skriver ut beslutet i stället för inventariet. Kör dem från klienten som misslyckades.

ip -4 route get 203.0.113.77
ip -4 rule show
ip -4 route show table all

Om uppslaget visar ändpunktens rutt genom den fysiska gatewayen är beteendet korrekt och adminsidan skickas helt enkelt ned fel väg. Det är punkten där namnupplösning blir åtgärden.

Ge tjänsten ett privat namn

Tjänsten behöver ett namn som löses till gatewayens adress inne i tunneln, samtidigt som certifikat- och värdnamnssemantiken som programmet förväntar sig behålls. En privat zonpost för adminnamnet är det vanliga svaret, och den lämnar transportnamnet orört.

Peka inte om transportnamnet till den inre adressen, eftersom nästa tunneluppkoppling då skulle försöka nå en adress som bara finns inne i en tunnel. Det misstaget ger en VPN som fungerar exakt en gång.

Kontrollera även båda adressfamiljerna, eftersom en kvarlämnad AAAA-post kan skicka webbläsaren någonstans där den privata planen aldrig nådde.

dig +short admin.hq.internal
dig +short -t AAAA admin.hq.internal
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://admin.hq.internal/

Anpassa policyn till var processen körs

En inbyggd process som lyssnar på gatewayen nås via den lokala ingångsvägen, så ingångskedjan och socket-bindningen avgör om begäran accepteras. Vidarebefordringsregler och IP-vidarebefordran får inte en lokal lyssnare att svara. Tillåt tunnelns källor i ingångspolicyn och bekräfta att processen är bunden till en adress som tunneln kan nå.

En container som publiceras på en värdport följer en annan väg, eftersom paketet destinationsöversätts och vidarebefordras. Den begäran möter värdens vidarebefordringspolicy och Dockers egna regler, och därför kan en fungerande inbyggd lyssnare samexistera med en container som avvisar samma port.

Startordningen spelar roll i båda fallen, eftersom en bindning till en adress som först dyker upp efter att tunneln kommer upp misslyckas tyst vid uppstart.

Kontrollera privat åtkomst och en nekad offentlig väg

Gör en färsk namngiven begäran från en auktoriserad klient med programmets egna identitetskontroller intakta. Prova sedan samma tjänst från utsidan av tunneln och bekräfta att den inte svarar. Ett privat namn är en bekvämlighet och inte en begränsning, och en lyssnare som fortfarande är bunden till den offentliga adressen är fortfarande exponerad. Det är den sista kontrollen som de flesta granskningar hoppar över.

Läs bindningarna och filtertillståndet i stället för värdnamnet användarna fick. Exponering är en egenskap hos socketen och inte hos namnet. Den skillnaden överlever varje DNS-ändring.

ss -lntp | grep ':443'
nft list ruleset | grep -n 443
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://203.0.113.77/

När den inre begäran returnerar sidan och den yttre begäran får timeout har tjänsten en avsiktlig privat väg och transporten förblir nåbar. När den yttre begäran fortfarande svarar måste lyssnaren eller en publicerad containerpost snävas in innan någon beskriver tjänsten som bara intern.