Plik o nazwie /check.txt na hoście proxy brzmi jak oczywisty cel kontroli kondycji. Haczyk polega na tym, że jawny nasłuch przekazywania Squida nie jest zwykłą stroną, która serwuje katalog główny dokumentów tego hosta.

Żądanie w stylu źródła, takie jak HEAD /check.txt HTTP/1.1, pomija bezwzględny cel oczekiwany dla zwykłego żądania HTTP przez proxy przekazujące. W zależności od konfiguracji może zostać odrzucone lub obsłużone przez inną usługę lokalną. Oba wyniki mogą powiedzieć mniej, niż sugeruje pulpit.

Wybierz usługę, którą musisz utrzymać dostępną

KontrolaPrzydatny dowód
Połączenie TCP z nasłuchem proxyOsiągalny proces akceptuje to połączenie.
CONNECT do kontrolowanego celuProxy akceptuje to żądanie tunelu.
Pobranie HTTP przez proxyWybrana ścieżka żądania może zwrócić oczekiwaną odpowiedź.

W trzecim przypadku żądanie potrzebuje celu, na przykład:

HEAD http://probe.example.internal/proxy-ready HTTP/1.1
Host: probe.example.internal

Nazwa hosta jest tylko przykładowa. Użyj kontrolowanego punktu końcowego, który proxy potrafi rozwiązać i do którego ma celowo dozwolony dostęp. http-check send w HAProxy pozwala wybrać metodę, URI, wersję i nagłówki; skonfiguruj to żądanie jawnie, zamiast dziedziczyć bez zmian przykład serwera źródłowego.

HEAD może sprawdzić status odpowiedzi i nagłówki. Nie zweryfikuje treści odpowiedzi, która nigdy nie jest przesyłana. Jeśli kontrakt kondycji wymaga znacznika w treści, wybierz odpowiednią kontrolę GET i zweryfikuj ten znacznik.

Gdy w grę wchodzi uwierzytelnianie proxy, utrzymuj konto kontrolne i ograniczenia źródła wąsko. Zwolnienie całego nasłuchu z uwierzytelniania dla zielonego znacznika zmienia usługę, która jest chroniona.

Na koniec zdecyduj, co ma usuwać nieudana kontrola. Kontrolowana awaria źródła może jednocześnie oblać kontrolę przekazywania każdego proxy. To może być dokładnie ta zależność, którą chcesz mierzyć, albo powód, by kondycję nasłuchu i dostępność od końca do końca trzymać jako osobne sygnały.

Powiązane artykuły