Зошто адресата на вашиот VPN тунел не отвора влезна порта
Адресата на тунелот го идентификува вашиот клиент пред партнерите што можат да насочуваат кон неа и никогаш не создава слушател. Проверете го врзувањето, повратната рута, потоа политиката.
Поврзете се на канцеларискиот VPN, стартувајте мала услуга на портата 8443, испратете ја адресата на тунелот до колега и гледајте како врската не успева додека клиентот сѐ уште известува дека е поврзан. Ништо во тунелот не е расипано: адресата е доделена, сесијата е активна, а пакетите што би го носеле одговорот едноставно никогаш не се пропуштаат. Изведете ги трите проверки подолу по ред и застанете на онаа што не успева, бидејќи секоја има различен поправка и само една од нив се однесува на VPN-от.
Започнете од тоа каде сокетот е навистина врзан
Пред нешто да биде насочено, нешто мора да слуша на адреса до која повикувачот може да стигне. Развојните сервери се вообичаениот виновник, бидејќи многу од нив стандардно се врзуваат за loopback и прифаќаат само врски што потекнуваат од истиот компјутер. Адресата на тунелот не го менува тоа врзување, и оперативниот систем ќе ја одбие врската многу пред VPN-от воопшто да биде вклучен.
ss -ltnp | grep 8443
netstat -ano | findstr 8443Читајте ја колоната со локална адреса, а не состојбата. 127.0.0.1:8443 значи само loopback, а поправката е врзување на 0.0.0.0 или на самата адреса на тунелот. 0.0.0.0:8443 прифаќа на сите интерфејси, што е пошироко отколку што повеќето луѓе имаат намера кога компјутерот има и јавна адреса; 10.64.7.15:8443 е тесната верзија што слуша само таму каде колегата може да стигне. Забележете го и името на процесот во истиот излез, бидејќи залутана инстанца од претходен тест е честа причина портата да изгледа отворена и да одговара со погрешна содржина.
Потоа прашајте дали нешто може да насочува кон таа адреса
Адресата на тунелот има смисла само за партнерите конфигурирани да го испраќаат тој префикс во тунелот. Компјутерот на колегата има своја табела и, ако нема рута за подмрежата на тунелот, пакетот оди до стандардниот gateway и умира на место што нема поим дека адресата постои. Ова е прашање на рутирање на страната на повикувачот, не дозвола на вашата страна.
| Symptom from the caller | What it usually means | Where to look next |
|---|---|---|
| Connection refused immediately | Nothing is listening on the address the packet reached | The bind address and the process owning the port |
| Connection times out with no reply | A policy dropped the packet, or no route returns | Server forwarding, host firewall, cloud security group |
| Works from the same machine only | Listener is on loopback, or no route reaches the tunnel address | Bind address, then the caller's route to that prefix |
Серверот меѓу двата клиенти е исто толку важен. Во вообичаениот дизајн за далечински пристап секој клиент отвора излезна врска кон gateway-от и gateway-от ја чува состојбата на тие текови, така што одговорите се враќаат по пат што тој веќе го знае. Врската од еден клиент кон друг е нов тек што gateway-от мора да го прифати и проследи, и многу поставувања го исклучуваат тоа намерно за да ги држат клиентите изолирани еден од друг. Потрошувачките VPN услуги обично изолираат стандардно; корпоративните gateway-и понекогаш го дозволуваат по групи.
Проверете го правецот пред да промените нешто на домаќинот. Ако адресата на тунелот одговара од самиот gateway, но не од партнер, разликата е поставката клиент-кон-клиент на gateway-от, и никакво уредување на локалниот огнен ѕид не може да ја замени.
На крајот, најдете ја политиката што го дозволува текот
Три слоја политики стојат меѓу насочениот пакет и услугата што одговара: одлуката за проследување на VPN серверот, огнениот ѕид на домаќинот и која било облачна безбедносна група пред инстанцата. Сите три мора да се согласат и тие не успеваат на различни начини, затоа симптомот во табелата погоре е покорисен од пораката за грешка во прелистувачот.
Огнениот ѕид на домаќинот е слојот што луѓето го забораваат по успешно врзување, бидејќи правилото што ја дозволува портата на LAN интерфејсот не ја дозволува автоматски на интерфејсот на тунелот. Правилата ограничени на интерфејс се правилен дизајн и истовремено вообичаената причина за услуга што работи од канцеларија, но не од дома. Читајте го опфатот на правилото, а не неговиот број на порта.
Филтрирањето со состојба го објаснува обратниот случај. Излезната врска од вашиот лаптоп создава состојба и одговорите на неа се пропуштаат без влезно правило. Врската на колегата е сосема нов тек без состојба зад себе, затоа ѝ треба изречна дозвола. Таа асиметрија е целата причина зошто работна сесија во прелистувачот на вашиот компјутер не кажува ништо за тоа дали услугата е достапна однадвор.
Кога една проверка не успева, сменете го дизајнот, а не тунелот
Ако барањето е колега да ја отвори вашата локална услуга, чесниот одговор обично е механизам изграден за влезен пристап. Обратен SSH тунел е најмалиот: вашиот компјутер се поврзува излезно кон домаќин што колегата веќе може да го достигне, а слушателот постои на тој домаќин.
ssh -N -R 8443:127.0.0.1:8443 [email protected]Релето бара GatewayPorts clientspecified во конфигурацијата на својот SSH сервер, инаку проследениот слушател се врзува за loopback на релето и колегата наидува на истото одбивање како претходно. За сѐ што трае подолго од едно попладне, балансерот на оптоварување или ingress со здравствена проверка и сертификат за објавеното име е подобриот инструмент, а тунелот од локација до локација со рути за двете подмрежи е вистинскиот одговор кога две мрежи навистина треба да разговараат.
Секој од тие дизајни ја прави изложеноста експлицитна и тоа е поентата. VPN-от пренесува пакети меѓу мрежи за кои веќе бевте овластени; тој не објавува услуга и не претвора лаптоп во домаќин свртен кон интернет. Задачата е да одлучите кој од трите слоја да го смените, а тунелот ретко е еден од нив.