Ien SSH-sesje, ien webapp en ien namopsykje kinne ien inkele VPN-ferbining diele sûnder om poarten te fjochtsjen. De klient bout ien fersifere stream nei de gateway, en elk applikaasjepetear reizget dêryn. Fan bûten is allinnich it eigen ferfier en de poarte fan 'e tunnel sichtber. Fan binnen hâldt elke tsjinst syn eigen poarte en hat noch altyd syn eigen tastimming nedich.

Wat de bûtenstream draacht, en wat er ferberget

De klient pakket elk pakket yn it ferfier fan 'e tunnel foardat it de masine ferlit. Dy bûtenstream hat ien bestimmingspoarte, fêststeld doe't de VPN konfigurearre waard. Yn 'e ferpakking hâldt elk orizjineel pakket it adres en de poarte fan 'e tsjinst dy't it rjochtet. De gateway hellet de ferpakking fuort en rûtelet op 'e binnenkop, sadat it bestimming in gewoane klient sjocht dy't fan it netwurk komt.

In opname op 'e WAN-ynterface toant dêrom ien petear, net trije. De binnenpoarten ferskine pas nei dekapsulaasje. Dêrom kin ien inkele fjoerwurdomgong SSH, HTTPS en DNS tagelyk drage.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

De TUN/TAP-dokumintaasje behannelt de oerdracht wêrby't in rûtele TUN-apparaat IP-pakketten tusken de kearn en in brûkersromteproses trochjaan. Dy oerdracht is wat de binnenkop sichtber makket foar de rûtele- en fjoerwurkoade fan 'e gateway. It ferklearret ek wêrom't de bûtenpoarte neat seit oer hokker tsjinsten tastien binne.

De NAT-trochstjoering heart by de listener, net by de applikaasjes

In selshoste gateway efter IPv4-NAT hat ien ynkommende oersetting nedich: it iepenbiere adres en de poarte mapt op 'e VPN-listener. Der is gjin regel nedich foar SSH, HTTPS of DNS, allinnich om't tunnêlbrûkers se berikke. It publisearjen fan dy poarten soe tsjinsten bleatstelle dy't de tunnel al beskermet. De trochstjoeringsregel beskriuwt berikberens fan 'e listener, net in tastimming foar eat binnen.

It omkearde jildt ek. It iepenjen fan 'e tunnelpoarte bleatstelt neat oars, dus in tsjinst dy't allinnich troch de tunnel berikber is, hâldt syn iepenbiere oerflak sluten. Dy skieding is gewoanlik krekt de reden om de tsjinst privee te hâlden.

Binnenbelied is wêr't tagong echt besletten wurdt

Fersifering beskermet it paad; it autorisearret gjin bestimming. Klientrûtes kieze hokker foarheaksels de tunnel yngean, it trochstjoeringsbelied fan 'e gateway beslút oft pakketten him ferlitte meie, en de fjoerwurd fan 'e bestimming plus oanmelding beslute oft de tsjinst antwurdet. DNS is it dúdlikste gefal: it dragen fan fragen makket net dat in resolver se út jo klientpool akseptearret. Eltse laach kin selsstannich nee sizze.

Test elk tsjinst apart troch de tunnel. In suksesfolle opsoch seit neat oer de webpoarte, en in suksesfol webferzoek seit neat oer SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

As de tunnel omheech is en alles mislearret, lês dan earst de rûtetabel fan 'e klient. As ien tsjinst mislearret wylst de oare wurkje, sit de flater by dy bestimming. Dy twa waarnimmings wize op ferskillende eigners, en se trochinoar helje is tiidfergriem.

WireGuard lûkt deselde line

WireGuard neamt syn bûtenlistener mei ListenPort, en in binnenapplikaasje brûkt noch altyd hokker tsjinstpoarte dan ek dy't er nedich hat. AllowedIPs is in set rûtele foarheaksels, net in list fan tastiene tsjinstpoarten. It lêzen as in poartetastimmingslist produsearret regels dy't net oerienkomme mei wat de tunnel docht. De nammejouwing is oars; de laachopbou net.

Stean de tsjinst ta yn lokaal-ynfierbelied as er op it einpunt sels draait, of yn trochstjoeringsbelied as er efter dat einpunt sit. It ûnderskie beslút hokker regelset it pakket sjocht.

De algemiene foarm is ien bûtenferfier mei in soad binnenpetearen. Produkten dy't ferskate bûtenútwikselings of in oar IP-protokol nedich hawwe, binne in herinnering dat it patroan fan ien iepenbiere poarte dit ûntwerp beskriuwt en net elke VPN.

Relatearre artikelen