Kan en roaming VPN-klient vara värd för en tjänst åt kontoret?

Din kontorsbärbara kan ringa in hemifrån och ändå leverera något som kontoret behöver, men bara när tre separata beslut sammanfaller. Tunneln är transport, den inre adressen är målet och policyn avgör vem som får knacka. Behandlar du något av dem som hela svaret får du det välbekanta klagomålet: värden svarar på ping men applikationen ansluter aldrig. Rollerna är inte desamma, och skillnaden är exakt där designarbetet bor.

Inringningsriktningen säger ingenting om tjänsteriktningen

När en klient startar en tunnel öppnar den en väg som båda riktningarna kan använda när den väl finns. Om en ny anslutning får komma in från hubben mot den klienten är en fråga om gatewaypolicy, inte en egenskap hos den som ringde in. På en routad OpenVPN-hubb behöver servern till exempel en rutt till klientens inre adress och vidarebefordran som tillåter peer-förhållandet.

Föreställ dig ett lagerhanteringssystem som pollar en agent på roamingbärbara datorer, eller en utvecklare som behöver ett test-API från en arbetsstation hemma. Båda vill att kontorssidan ska inleda samtalet, vilket är motsatsen till det vanliga klient-till-server-mönstret.

Hostade fjärråtkomstprodukter varierar här, och variationen är inte en bugg. Vissa hanterade VPN-tjänster blockerar medvetet oombedda anslutningar mot anslutna klienter eftersom deras modell är klient-till-resurs, inte resurs-till-klient. Läs produktens dokumenterade arkitektur innan du lovar en kollega att dennes bärbara kan fungera som server.

Följ returvägen innan du öppnar en port

Vägen har tre delar: en rutt på gatewayen som pekar på klientens inre adress, en policy som tillåter den specifika anroparen och en lyssnande tjänst på målet. Varje del misslyckas olika, därför säger «VPN:et är uppe» nästan ingenting.

Den goda nyheten är att den inre vägen inte behöver portvidarebefordran på klientens hemrouter. Det är hela poängen med att publicera tjänsten på tunneladressen i stället för på hemmets WAN-adress, där exponeringen och NAT-reglerna skulle vara helt annorlunda. En hemrouter kan också vägra att hairpinna en anslutning som kommer från kontoret, så WAN-rutten misslyckas av skäl som inte har med ditt VPN att göra. Att hålla trafiken inom tunneln undviker båda problemen på en gång.

Kontrollera även målsidan. En tjänst som bara är bunden till 127.0.0.1 kan inte ta emot en anslutning som anländer på tunnelgränssnittet, hur korrekta gatewayens rutter än är. En värdbrandväggsregel som bara tillåter porten från det lokala subnätet släpper också kontorstrafik, och den regeln är oberoende av VPN-policyn ovanför.

Namn och adresser är designbeslut

En adress inne i tunneln är inte automatiskt ett namn. En privat DNS-post som du kontrollerar är tydligare än att hoppas att ett upptäcktsprotokoll korsar tunneln, eftersom link-local multicast-namnlösning stannar i det lokala segmentet och inte blir DNS mellan subnät.

Adressstabilitet betyder lika mycket. Om VPN-klienter hämtar från en pool med korta lån ändras bärbarens inre adress mellan sessioner och varje bokmärke, brandväggsomfång och övervakningskontroll som byggts på den går sönder tyst. Använd en reservation eller en dokumenterad dynamisk uppdateringsväg.

Kom överens om namnet med den som äger VPN-identiteten, så att posten, adresstilldelningen och åtkomstpolicyn ändras tillsammans i stället för i tre separata ärenden.

Testa tjänsten, inte medlemskapet

Bekräfta från målet vad som lyssnar och på vilken adress, bekräfta sedan gatewayens syn på returvägen:

$ ss -ltnp | grep 8080
LISTEN 0 128 10.80.0.23:8080 0.0.0.0:*
$ ip -4 addr show tun0 | grep inet
inet 10.80.0.23/24 scope global tun0
$ ip route get 10.80.0.1
10.80.0.1 dev tun0 src 10.80.0.23

Testa nu från kontorssidan med en riktig begäran i stället för ett eko. Ett lyckat curl mot tjänsten bevisar rutten, policyn och lyssnaren på en gång, medan ett lyckat ping bara bevisar att ICMP är tillåtet. Om begäran misslyckas går du baklänges genom de tre delarna i stället för att vidga brandväggen och hoppas.

Tillgänglighet hör till samma samtal. En bärbar sover, roam mellan nätverk och kopplar från vid dagens slut. En tjänst som måste svara vilken timme som helst hör på en alltid påslagen värd, medan en best-effort-tjänst kan stanna på klienten med den begränsningen nedskriven.

Publicera resursen medvetet, med ett namn, en lista över tillåtna anropare och en ägare, och fjärrenheten blir en stödd tjänst i stället för en oavsiktlig server.