Dau ddyluniad, un cymhwysiad HTTPS, ac mae'r pecyn yn cymryd llwybr gwahanol ym mhob un. Mae porth cyfeirio yn newid ble mae'r pecyn yn cael ei ddosbarthu ac yn gadael gweddill y pecyn yn llonydd. Mae VPN yn cario'r pecyn hwnnw y tu mewn i becyn arall yn gyntaf, felly mae gwrandawr y cymhwysiad yn gweld ffynhonnell wahanol a llwyth mwyaf llai. Mae'r amgryptiad y mae pobl yn dadlau yn ei gylch yn bresennol yn y ddau achos, oherwydd bod y cymhwysiad yn dal yn HTTPS; yr hyn sy'n wahanol yw pwy all agor cysylltiad a beth all y rhwydwaith rhyngddynt ei arsylwi. Mae'r gwahaniaeth hwnnw yn setlo'r rhan fwyaf o'r cwestiynau ymarferol.

Mae rheol DNAT yn ailysgrifennu'r cyrchfan ac yn stopio yno

Ar borth Linux, mae cyhoeddi gwasanaeth yn golygu rheol yn gadwyn PREROUTING y tabl nat, neu'r cyfwerth yn nftables. Mae'r rheol yn cyfateb i'r cyfeiriad a'r porth cyhoeddus, yna'n ailysgrifennu'r cyrchfan i gyfeiriad preifat y cymhwysiad. Mae cyfeiriad y ffynhonnell, porth y ffynhonnell a'r llwyth yn aros yn ddigyfnewid, ac mae conntrack yn cofnodi'r mapio fel bod atebion yn cael eu hailysgrifennu'n ôl wrth fynd allan. Ymddygiad yw'r model cyfieithu cyfeiriad traddodiadol a ddisgrifir yn RFC 3022.

sudo iptables -t nat -A PREROUTING -d 203.0.113.10 -p tcp --dport 443 \
  -j DNAT --to-destination 10.20.30.40:443
sudo iptables -t nat -L PREROUTING -n -v
sudo conntrack -L -p tcp --dport 443

Nid yw gwrandawr y cymhwysiad byth yn dysgu bod y cysylltiad wedi cyrraedd drwy gyfieithiad. Mae'n gweld gwir gyfeiriad ffynhonnell y cleient, sy'n ddefnyddiol ar gyfer cofnodion mynediad a therfynau cyfradd, ac mae'n ateb y cyfeiriad preifat oherwydd bod conntrack yn gwrthdroi'r mapio. Nid oes unrhyw beth ar y llwybr hwnnw yn dadgryptio nac yn ailaillamgryptio: mae TLS yn dal i redeg rhwng y cleient a thystysgrif y cymhwysiad ei hun.

Mae'r rheol hefyd yn trwsio'r moddau methu y byddwch yn dod ar eu traws yn nes ymlaen. Os yw'r borth yn anfon ymlaen ond nad oes gan westai'r cymhwysiad unrhyw lwybr yn ôl at y cleient, mae atebion yn gadael gyda'r ffynhonnell anghywir ac mae'r ysgwyd llaw yn stopio. Os yw ail reol yn cyfateb gyntaf, y drefn sy'n penderfynu'r canlyniad, ac mae iptables -t nat -L -n -v yn dangos y cyfrifwyr sy'n profi pa reol a gymerodd y pecyn.

Mae'r tiwnel yn lapio'r pecyn cyn i'r gwrandawr ei weld

Nid yw VPN yn cyhoeddi'r cymhwysiad o gwbl. Mae'r cleient yn adeiladu pecyn allanol wedi'i gyfeirio at gyfeiriad cyhoeddus y borth, yn amgryptio'r pecyn mewnol y tu mewn iddo, ac mae'r borth yn dadgryptio ac yn llwybro'r pecyn mewnol i'r cyrchfan preifat. Gyda WireGuard y cludiant allanol yw UDP, fel arfer ar borth uchel; gyda OpenVPN dros TCP 443 mae'r pecyn allanol yn edrych fel TLS i unrhyw beth sy'n gwylio'r llwybr.

Y tu mewn i'r tiwnel mae'r pecyn mewnol yn cadw cyfeiriadau preifat: cyfeiriad tiwnel y cleient, dyweder 10.8.0.6, a'r cymhwysiad yn 10.20.30.40. Felly mae'r gwrandawr yn gweld ffynhonnell o'r pwll tiwnel, ac mae pob cleient yn rhannu'r borth hwnnw fel ei gam nesaf. Mae cofnodion mynediad y tu ôl i VPN yn aml yn dangos y borth yn hytrach na'r defnyddiwr am yn union y rheswm hwn, oni bai bod y borth yn cadw'r ffynhonnell wreiddiol.

Mae'r lapio yn costio lle pennawd, a dyna'r unig wahaniaeth ar lefel mecanwaith sydd â chanlyniad y gellir ei fesur. Mae pennawd IP allanol ynghyd â UDP ynghyd â phennawd WireGuard ei hun yn bwyta MTU'r llwybr, felly rhaid darnio pecynnau mawr neu rhaid i'r stac TCP mewnol glymu ei MSS. Gall trosglwyddiad sy'n gweithio dros y llwybr a gyfeiriwyd stopio dros y tiwnel pan fydd blwch canol yn gollwng yr ICMP a fyddai wedi nodi'r MTU llai.

ip route get 10.20.30.40
ping -M do -s 1400 10.20.30.40
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

Mae'r datguddiad yn cael ei benderfynu wrth y fynedfa, nid gan y seiffr

Mae'r ddau ddyluniad yn gorffen ar yr un gwrandawr TLS, felly mae'r ddau yn etifeddu'r un dystysgrif, yr un fersiynau protocol a'r un mewngofnod cymhwysiad. Yr hyn sy'n newid yw pwy ganiateir dechrau ysgwyd llaw. Gyda chyfeirio cyhoeddus, mae unrhyw westai sy'n cyrraedd 203.0.113.10:443 yn cael ysgwyd llaw TCP a TLS ClientHello cyn i awdurdodiad eich cymhwysiad gael ei ystyried o gwbl. Gyda mynediad drwy diwnel yn unig, dim ond o gyfeiriadau y mae'r borth yn eu llwybro i'r tiwnel y gellir cyrraedd y gwrandawr, ac mae SYN dieithryn yn marw ar bolisi'r borth.

Mae'r gwahaniaeth hwnnw'n ymwneud â chyrhaeddadwyedd, nid â chyfrinachedd. Nid yw gwasanaeth HTTPS wedi'i gyfeirio yn destun plaen, ac nid yw VPN yn dileu'r angen am ddilysu cymhwysiad: mae derbyn i'r tiwnel yn ateb a all dyfais anfon pecynnau i'r rhwydwaith hwn, tra bod y cymhwysiad ffeil yn ateb a all defnyddiwr ddarllen dogfen. Cymysgu'r ddau yw sut mae timau'n gorffen gyda VPN sy'n rhoi'r holl LAN a chymhwysiad ag un cyfrinair a rennir.

Archwiliwch y gwrandawr a'r polisi ar wahân, oherwydd gall y naill neu'r llall fod yn lletach nag yr ydych yn ei dybio:

sudo ss -ltnp 'sport = :443'
sudo nft list ruleset
openssl s_client -connect 203.0.113.10:443 -servername files.example.com </dev/null

Os yw ss yn dangos bod y gwrandawr wedi'i rwymo i 0.0.0.0, mae'r cymhwysiad yn cyrraeddadwy o ble bynnag y mae llwybro a pholisi mur cadarn yn caniatáu, a dim ond un ffordd i mewn yw'r cyfeirio. Mae rhwymo i'r cyfeiriad preifat, neu gyfyngu'r amrediad ffynhonnell yn y mur cadarn, yn benderfyniad ar wahân i ddewis VPN, a dyna'r penderfyniad sy'n culhau'r datguddiad mewn gwirionedd.

Mesurwch y llwybr, nid y label

Pan fydd rhywun yn honni bod y cyfeirio yn gyflymach, mae'r gymhariaeth onest yn cadw popeth arall yn gyson: yr un cleient, yr un rhwydwaith mynediad, yr un ffeil, yr un cyfluniad TLS, yr un gwestai cymhwysiad. Rhedwch y trosglwyddiad ddwywaith y llwybr a chofnodwch gyfanswm yr amser, nifer y methiannau a'r ymatebolrwydd, nid allbwn prawf cyflymder heb gysylltiad.

curl -sS -o /dev/null -w '%{time_connect} %{time_appconnect} %{time_total}\n' \
  https://files.example.com/report.pdf
mtr -rwc 20 203.0.113.10
mtr -rwc 20 10.20.30.40

Mae'r niferoedd hynny'n gwahanu sefydlu cysylltiad oddi wrth amser trosglwyddo, sy'n bwysig oherwydd bod y ddau lwybr fel arfer yn gwahaniaethu mewn hwyrni rownd-daith a MTU yn hytrach nag yng nghost y seiffr. Mae gwaith TLS yn digwydd yn y pen draw yn y ddau ddyluniad, ac mae tiwnel yn ychwanegu crynhoi, llwybr gwahanol ac efallai porth prysurach. Os yw llwybr y tiwnel yn hirach neu os yw ei borth yn llwythog, mae'r gwahaniaeth yn perthyn i'r llwybr ac nid i'r gair amgryptio.

Dewiswch y polisi mynediad y mae'r gwasanaeth ei angen mewn gwirionedd, yna penderfynwch a yw gwahaniaeth wedi'i fesur yn cyfiawnhau ei newid. Mae cyfeirio cyhoeddus yn addas ar gyfer gwasanaeth i'r rhyngrwyd agored, gyda chyfyngiadau ffynhonnell, TLS wedi'i ddiweddaru a monitro o'i flaen. Mae mynediad drwy diwnel yn unig yn addas ar gyfer offeryn mewnol y mae ei ddefnyddwyr eisoes wedi'u cofrestru, ar yr amod bod llwybro'r borth a chaniatadau'r cymhwysiad ill dau yn gulach na'r holl LAN.

Cyn i chi alw'r dyluniad yn gyflawn, cadarnhewch bedair peth: i ba gyfeiriad y mae'r gwrandawr wedi'i rwymo, pa reol neu lwybr sy'n derbyn y pecyn, a yw'r llwybr dychwelyd yn gweithio o wir gyfeiriad y cleient, ac a yw llwythi mawr yn goroesi'r MTU. Mae gan bob un o'r rhain orchymyn uchod, ac nid oes yr un ohonynt yn cael ei ateb gan y gair diogel nac gan siart lled band.

Erthyglau cysylltiedig