Jak publiczny proxy dociera do prywatnego źródła przez VPN

Publikowanie witryny przez tunel i dawanie użytkownikom dostępu do VPN to dwa różne układy, które dzielą jeden kabel. W pierwszym publiczne odwrotne proxy przyjmuje żądanie odwiedzającego i przekazuje je przez tunel do źródła, do którego nikt nie może dotrzeć bezpośrednio. W drugim użytkownik musi dołączyć do VPN, zanim aplikacja w ogóle stanie się osiągalna. Mieszanie obu opisów to droga, na której prywatny backend kończy jako publicznie wystawiony.

Dwa modele, które na diagramie wyglądają tak samo

Narysuj strzałki, zanim cokolwiek wybierzesz. Model publicznego publikowania biegnie od przeglądarki do proxy przez HTTPS, potem od proxy do źródła przez tunel, a źródło nigdy nie przyjmuje połączenia z internetu. Model tylko z VPN biegnie od klienta do bramy, a aplikacja jest osiągalna wyłącznie od wewnątrz tej ścieżki. Laptop użytkownika siedzi w tej samej sieci co aplikacja, i to jest cały sens tego modelu.

Modele różnią się tym, kto uwierzytelnia i gdzie. W pierwszym proxy jest publicznym wejściem i przekazuje każde nadchodzące żądanie, także wrogie, zgodnie z polityką na nim skonfigurowaną. W drugim samą bramą jest osiągalność, co jest zgrubnym, ale prawdziwym wpuszczeniem.

Gdzie kończy się TLS i co faktycznie dowodzi

TLS między przeglądarką a proxy chroni ten przeskok i pozwala przeglądarce zweryfikować witrynę, którą zamierzała odwiedzić. Jeśli proxy kończy TLS, żądanie istnieje w czytelnej formie wewnątrz tego procesu, zanim zostanie przekazane. Druga sesja TLS do źródła może chronić następny przeskok i osobno zweryfikować punkt końcowy aplikacji. Żadna z sesji nie decyduje, który człowiek może używać aplikacji. Certyfikat wieloznaczny na proxy również nie rozciąga się na ten drugi przeskok.

To jest ta część, którą ludzie sprowadzają do słowa zaszyfrowane. Poufność, integralność i tożsamość serwera to właściwości transportu; autoryzacja to decyzja aplikacji. Prywatny adres za tunelem zmienia kto może dotrzeć do gniazda, a nie kto może się zalogować, gdy już tam dotrze.

Ufaj przekazywanym nagłówkom tylko od proxy

Aplikacje, które logują lub autoryzują na podstawie adresu klienta, zwykle czytają nagłówek dodawany przez proxy. Ten nagłówek to tylko tekst, więc wszystko, co może dotrzeć do źródła bezpośrednio, może twierdzić, że ma dowolny adres. Ogranicz źródło tak, aby łączyć się mógł tylko adres tunelu proxy, i skonfiguruj aplikację, aby przyjmowała nagłówek wyłącznie z tego adresu.

curl -s -o /dev/null -w '%{http_code}
' -H 'X-Forwarded-For: 203.0.113.9' http://172.20.5.40/

Jeśli to żądanie powiedzie się z hosta, który nie jest proxy, źródło ufa nagłówkowi, który powinno ignorować. Napraw odbiornik, zanim dotkniesz aplikacji. Odmowa to znacznie lepszy wynik niż linia logu niosąca sfałszowany adres.

Utrzymuj źródło osiągalne dokładnie z jednego miejsca

Powiąż odbiornik źródła z adresem tunelu lub odgrodź go zaporą sieciową w stronę proxy, a następnie potwierdź, co naprawdę nasłuchuje. Usługa uruchomiona z powiązaniem wieloznacznym przyjmuje połączenia na każdym interfejsie, który ma host, w tym na tym, o którym zapomniałeś, że jest routowalny. Tabela nasłuchu jest podstawową prawdą, a nie plik konfiguracyjny, który zamierzałeś zastosować. Jeśli powiązanie wieloznaczne jest zamierzone, zapora sieciowa nadal musi być składnikiem, który je zawęża.

ss -ltnp | grep -E ':(80|443)'

Zrób ten sam przegląd dla interfejsów zarządzania, które są zwykłym przypadkowym wystawieniem. Następnie zapisz oba modele osobno: publiczną witrynę przez proxy i interfejs administracyjny osiągalny tylko przez tunel. Zdanie, że serwer jest za VPN, nie mówi nic z tego.