OpenVPN и HTTPS на порта 443: чиј е слушачот?

Две служби можат и двете да одговараат на портата 443 без никогаш да се натпреваруваат, бидејќи слушачот се одредува според транспортот, адресата и портата заедно, а не само според бројот. Ставете веб-сервер и OpenVPN на една машина, и единственото прашање што вреди прво да се одговори е кој сокет го бара секој процес од јадрото. Запишете го тој список пред да уредите конфигурација, и повеќето грешки „адресата е веќе во употреба“ сами ќе се објаснат. Сето по списокот е избор помеѓу UDP слушач, заеднички TCP сокет или преден дел што насочува по протокол.

Започнете со сокетот што го бара секој процес

Bind успева или не успева според таа тројка, па два демони се судираат само кога сите три дела се совпаѓаат. Затоа веб-страница на TCP 443 неограничено коегзистира со OpenVPN слушач на UDP 443, и затоа преместувањето на едниот од нив на втора локална адреса на истиот хост исто така ја завршува расправата. Читајте ги живите слушачи, а не датотеките што требаше да ги создадат, бидејќи застарен include или заборавена unit-датотека го надживува уредувањето што се сеќавате дека сте го направиле.

Стартувајте ss -lntup како root и прочитајте го секој ред што спомнува 443, вклучително IPv6 записите. Обично џокер слушачот за v6 прифаќа и v4 сообраќај, и така заборавен слушач ја држи портата зафатена откако ќе ја смените датотеката што сте мислеле дека е одговорна. Ако името на процесот ве изненади, стеснете го излезот со ss -lntup 'sport = :443' пред да допрете нешто.

Префрлете го тунелот на UDP кога мрежата дозволува

UDP слушачот целосно го заобиколува судирот и обично е најкратката поправка, бидејќи ниту еден сокет не се споделува и ниту еден дополнителен производ не влегува во патеката. Но тоа не е бесплатно. Некои клиентски мрежи фрлаат UDP 443 без да испратат reset, па тунелот престанува да се воспоставува наместо да не успее bind, и корисникот пријавува дека VPN е исклучен без грешка за читање. UDP слушачот исто така го преживува рестартирањето на веб-слојот, што се брои на машина чија страница често се прераспоредува. Тестирајте од мрежата каде што седат корисниците, бидејќи школка на серверот само докажува дека серверот стигнува до себе.

Сменете го транспортот во конфигурацијата на серверот и во профилот на клиентот заедно. Профил што уште бара TCP ќе се врти во циклуси на повторно поврзување кон слушач само со UDP, и тоа изгледа како мрежна дефект додека не ги споредите двете датотеки.

Дозволете процесот на VPN да го поседува TCP 443 и префрлете го остатокот

Community OpenVPN во режим на TCP сервер ги чита првите бајти на влезната врска и префрла сето она што не е неговиот протокол на HTTPS заднина, и за тоа служи директивата port-share. Заднината е обичен веб-сервер со вклучен TLS, именуван со хост и порта во таа директива, а не со URL.

port-share 10.0.0.5 8080

На машина каде страницата држи втора приватна адреса, таа линија го испраќа не-VPN сообраќајот на 10.0.0.5:8080, па HTTPS виртуелниот хост мора да биде врзан таму и огнениот ѕид мора да го дозволи локалниот скок. Веб-серверот мора сам да го заврши TLS, бидејќи бајтите што пристигнуваат се оригиналниот ракување на прелистувачот и ништо помеѓу не ги дешифрирало. Насочете ја директивата кон обичен HTTP слушач и прелистувачот добива грешка за неважечки метод, која се чита како расипана страница, а не како погрешно поставена заднина. Директивата постои само во режим на TCP сервер, а UDP слушачот нема тек за проверка.

Бидејќи процесот на VPN прифаќа секоја врска, веб-апликацијата го гледа префрленото барање како доаѓа од една од сопствените адреси на хостот наместо од посетителот. Сето она што бара вистинската адреса на клиентот зависи од поддршката за PROXY протокол во заднината или од преден дел што ја додава. Преместувањето на заднината на друга локална адреса не ја враќа адресата на посетителот; тоа само менува која од адресите на хостот страницата ја запишува. Запишете го ова ограничување во белешките за распоредување пред извештајот за аналитика да го постави прашањето.

Обратниот прокси е погрешен алат; рутерот од четврти слој не е

HTTP обратниот прокси го завршува TLS за да може да чита барања, што значи дека не може да пропушти OpenVPN тек недопрен. Рутер од четврти слој што префрла според SNI или според проверка на првиот пакет може да стои пред двете, под услов да не ја заврши сесијата од која зависи VPN. Двата уреда изгледаат слично на дијаграм и се однесуваат сосема различно кај сокетот.

Комерцијалниот Access Server доаѓа со свои поставки за споделување на портата, и тие не се совпаѓаат еден-на-еден со директивата на заедницата. Идентификувајте го производот и верзијата пред да прилагодите водич напишан за другиот. Копирана поставка што тивко се игнорира е полоша од никаква поставка, бидејќи списокот на слушачи потоа уште изгледа веродостојно.

Тестирајте ја веб-страницата и тунелот како два одделни патеки

Вчитајте ја страницата и поврзете го тунелот, потоа прочитајте го списокот на слушачи повторно за да видите кој процес сега го поседува 443. Страница што се вчитува не докажува ништо за VPN, а тунел што се поврзува не докажува ништо за страницата, иако двете го користат истиот број. Трите команди подолу го проверуваат заедничкиот сокет, веб-патеката и услугата VPN во тој редослед.

ss -lntup 'sport = :443'
curl -sI https://vpn.example.com/ | head -n 1
journalctl -u openvpn-server@server -n 20

Споредете ја адресата на клиентот во пристапниот дневник на заднината со онаа во дневникот на VPN за истиот момент. Ако страницата го запишува секој посетител како самиот хост, префрлањето работи, а ракувањето со адресата не. Ако двата дневници молчат, предниот дел никогаш не ја предал врската. Како и да е, списокот на слушачи одлучува кој го прифаќа сокетот, и тоа е фактот што треба да се потврди пред да смените уште една датотека.

Оставете ја таа карта на слушачи до конфигурацијата за следниот човек што ќе допре 443 да знае кој процес прифаќа и каде отишол другиот протокол. Потврдете го сопствеништвото по промената наместо да верувате во она што уредувањето требаше да го направи.