VPN කතන්දරය

Communication

කියවන්න කලිම් පොඩ්ඩක් මේක කියවල එන්නෙ මේකෙ අමුතුවෙන් මොනවත් නැ පාවිච්චි කරන වචන ටික විස්තර කරලා තියෙන්නෙ. - link

මුලින්ම අපි බලමු මේ Internet එකට connect වෙලා තියෙන device දෙකක් එකිනෙක අතරේ communicate කරගන්නෙ කොහොමද කියලා.

මෙහෙම communicate කරගද්දි එක එක devices එක එක විදි වලට වැඩ කරන්නෙ නැ. Device එක මොක වුණත් OS එක මොක වුණත් ඒක Internet හෝ local Network එකකට connect වෙනවනන් ඒ device එකේ මේ OSI Model එක සපුරන්න ඕනෙ. Device එක පාන් රෝස්ට් කරන එකක් වුණත් Wi-Fi connect වෙනවනන් අනිවාරෙන් මේ OSI Model එක support වෙන්න ඕනෙ.

ඇත්තටම මේ data කියලා කියන්නෙ අමුතු දෙකට නෙමෙ හැම වෙලේම හිතන්න මේ හැම දෙයක්ම හැදිලා තියෙන්නෙ 1, 0 න් කියලා. හිතන්නකො Photo  එකක් කියලා Photo එකක resolution  (Width * Height) එකෙන් එනවා එකේ pixels ගණන මේ එක pixel එකක් (හැම Photo එකම නෙමෙ) 24 bits වලින් represent කරනවා. ඒ කියන්නෙ bit 8කින් රතු පාටත් තවත් 8 කින් නිල් පාටත් ආයෙ කොල පාටත් විදිය මේ විදියට මුලු Photo එකේම pixel 1, 0 න් නිරූපණය කරනවා මෙහෙම 1, 0 එව්ව මිලියන ට්‍රිලියන ගාණක් එනවා. හිතන්නකො film එකක් කියලා film එකක් හැදිලා තියේ මේ වගේ photos විශාල ප්‍රමණයක් එකතු වෙලා. එතකොට හිතන්නකො 1, 0 කොච්චරක් ඇතිද කියල.  

දැන් ඔයා මේ photo එක Network cable එක දිගේ  transfer ( මෙහම මොනවහරි 1, 0 data ඇත්තටම යවනවා කිව්වට එහෙම යවන්න බැහැනෙ Electrical Signals, නැත්තන් Waves විදියට තමා යන්නෙ එහෙම 1, 0 ඒ වගේ දෙකට පරිවර්ථනය කරන්නෙ කොහොමද කියල ඔයාලම හොයල බලන්න. මම මෙච්චර low level පැහැදිලි කරන්න යන්නෙ නැ. ලස්සන සංකල්ප තියෙනවා හොයලා බලන්න starlink එහෙම මේ දේ කරන විදිය, තව Fiber optics, Cell Networks වල, ) කරනවා කියලා, ඉතින් එහෙම කරන්න. අපිට මේ photo එකේම binary values කෙලින්ම network cable දිගේ යවන්න බෑ මේකට විශාල හේතු ප්‍රමාණයක් තියෙනවා. (hops (දැනට devices කියල හිතන්නකො) කීපයකින් යවන්න තියෙද්දි යවන්නෙ කොහාටද කියලා හොයගන්න එක, data හරියටම ගියාද නැද්ද, receive කරන කෙනා දන්නෙ නැ කොච්චරක් data එනකම් බලන් ඉන්න ඕනෙද කියලා, යවපු කෙනා දන්නෙ නැ කොච්චරක් ගියාද මගින් කොච්චරක් Miss වුණාද, Network එකෙ අනික් devices හරහ යද්දි ඒ අයට බලන්න පුලුවන් photo එක මේ වගේ තවත් ගොඩාක් ප්‍රශ්ණ.)  ඒ නිසා තමයි මේ OSI Model  එක තියෙන්නෙ.

මෙහෙම devices දෙකක් අතරේ OSI model එකට අනුව Data transfer කරද්දි Data යවන්නෙ PDU විදියට PDU එකක maximum size එකක 1522 ඒ කියන්නෙ 1, 0 එව්වා 1522 ඒ වගේම අඩුම 64,

මේ OSI Model එකේ layers 7 (අපිට හිතන්න පහසුව සඳහා එහෙම වෙන් කරලා තියෙන්නෙ.) ක් තියෙනවා මේ හතට ආවේනික headers සහ encodings ඒ ඒ layer එකේදි pdu එකට add වෙනවා සිද්ද වෙනව මේකට අපි කියනවා pdu එක Encapsulate කරනවා කියලා. සරලව මෙහෙම හිතන්නකො එක පෙලට කාමර හතක් තියෙනවා මේ කාමර වලට ආවෙනික සේවකයො ඉන්නව කියලා ඉතින් පලවෙනි කාමරෙට මේ raw data ටික දුන්නහම් නැත්තන් photo මුල් කාමර වලින් මේක encrypt කරනවා ඊලග එව්වලින් කෑලි වලට කඩනවා, ඔහොම අවසාන ඉතින් මේ කාමර වලින් ඒවා අරගෙන් ඒක එයාලට අදාලව කරන්න ඕනෙ එව්ව ටික කරලා ඊලග කාමරේට pass කරනවා එහෙම එහෙම අවසාන එකට වෙනකම් ගියාට පස්සෙ මේ PDU එක ඇතුලේ ඒ ඒ කාමර වලින් ඇඩ් කරපු ගොඩක් දේව්ල් තියෙනවා.

ඒ වගේම pdu එකක් හදනවා වගේම Pdu එකක් receive වුනාම මේ කරපු ටිකේම අනික් පැත්ත කරන්නෙ. ඒ කියන්නෙ pdu එක ලෙහලා ඇත්තම අවශ්‍ය data ටික ගන්නවා.

OSI model එකේ layers

1. Application Layer 
2. Presentation layer
3. Session layer
4. Transport Layer
5. Network Layer
6. Data Link Layer
7. Physical Layer

1. Physical Layer

නමින්ම කියවෙනවා වගේ මේකට අදාල වෙන්නෙ ඔක්කොම cables, උපාංග අනන් මනන් සහ ඇත්තටම bitstream එකක් transfer වෙන්නෙ මේකෙදි මම මේක ගැන වැඩිය විස්තර කර්න්න යන්නෙ නැ ඔය ගොල්ලො හොයන්න.

*192.168.0.0/24 මේක ඇතුලෙ ip 256 ක් තියෙනව 192.168.0.0 - 192.168.0.255 වෙනකම් ඒ කියන්නෙ ඒක ඇතුලෙ device 254 කට (අනික් දෙක broadcast, network addr එකයි) connect වෙන්න පුලුවන් switch එකකින් අපිට මේ ඕක්කොම connect (තනි එක්කින් එහෙම කරන්න බැ විදියක් තියේ දැනට නිකන් හිතන්න) කලහම් ඒක network එකක් වෙනවා.

2. Data Link Layer

මේ layer එක ගැන කතා කරනවනන් ගොඩක් තියෙනවා කතා කරන්න සරලව කියන්නම්. Same Network එකක node node අතරෙ ඒ කියන්නෙ ඔයා Pdu එකක් යැව්වොත් ඒක කෙලින්ම destination ට යන්නෙ නැනෙ මේ pdu එක routers switches හරහා යන්න ඕනනෙ ඉතින් මෙහම same network එක ඇතුලෙ යන්න  sup එක දෙන්නෙ මේකෙන්. ඒ වගේම මේ layer එකේදි pdu එකට විශේෂ නමක් කියනවා Frames කියලා විශේශයෙන්ම switches operate (layer 3 switches ත් තියෙ) වෙන්නෙ මේ layer එකේ mac address එහෙමත් අදාල වෙන්නෙ මේකට උදාහරණයක් මම කියන්නම් switch එක්කට Frame එකක් හම්බුනාම ඒකෙන් පටස් ගාල pdu එක මේ Data Link Layer එකට වෙනකම් ලෙහනව ලෙහලා next hop එක බැලුව forward කරා එයාට එතනින් පහල layer වල මොනව තිබ්බත් අදාල නැ. ( මම මේ කිව්වෙ ඉතාම සරලව ) 

උඩ කිව්ව Network එකට අදාලව ගත්තොත් 192.168.0.2 pc එක 192.168.0.3 pc එකට pdu එකක් යවනවනම් 192.168.0.2 pc එකෙන් ඒක switch එකට යවනවා switch එක ලග මේ ඔක්කොම pc වලට අදාලව mac table එකක් තියෙනවා. ඉතින් ඒකට අදාලව pdu එක අදාල pc එකට forward කරනවා.

මේ layer එකට ip address port අනන් මනන් අදාලම නැ. Mac address වලින් තමා device අදුර ගන්නෙ.

3. Network Layer

දැන් හිතන්න Network දෙකක් ගැන 192.168.0.0/24, 192.168.1.0/24 වගේ 

මේ layer එක අවශ්‍ය වෙන්නෙ different network දෙකක් අතර communicate කරගනිද්දි උදාහරණයක් විදියට 192.168.0.0/24 192.168.1.0/24 මේ දෙක ඒ කියන්නෙ different network දෙකක්   හිතන්නකො 192.168.0.3 pc එකෙන් pdu එකක් 192.168.1.5 pc එකට යවනවා කියලා මේ Pdu එක මුලින්ම ඒ Network එකේ switch එකට යනවා එතනින් switch එකෙන් Layer දෙකට වෙනකම් ලෙහලා network එක වෙන කරන අදාල router එකට forward කරනවා. Router එකෙන් layer 3 වෙනකම් මේක ලෙහලා එකේ තියෙන් destination ip එක බලල router එකට දාලා තියෙන් routes අනුව එයා ඒ pdu එක forward කරනවා. ඒ වගේම මේ Layer එකේ තමා අපි ping කරන්න use කරන ICMP protocol එක එහෙම run වෙන්නෙ මේ layer එකෙදි අපි pdu එකට කියන්නෙ ip packet එකක් කියලා

මේ වෙනකම් මුකුත් තේරුනෙ නැත්තන් හැම එකක්ම අල්ලල දාන්න, මෙතනින් එහා ටික තම වැදගත් ටික තියෙන්නෙ.

4. Transport Layer

මේ layer එකෙන් තමා Data transfer කරන එක ගැන වගකීම දරන්නෙ අපි කියන TCP, UDP (quic දුවන්නෙත් udp ම නිසා මම වෙන් කරන්නෙ නැ.) කියන ප්‍රදාන data transfer protocol  දෙක දුවන්නෙ මේ layer එකේ. UDP කියන protocol එක connectionless ඒ කියන්නෙ packet එකක් යැව්වා එච්චරයි ඒක ගියාද end device එකට ඒක හම්බුනාද අනන් මනන් අදාලම නැහැ.

Udp හරිම අඩුවෙන් තමා use වෙන්නෙ dns ඉල්ලද්දි ඒ වගේම Multiplayer gaming වලදි සහ video call, voice call, online meetings වගේ realtime දේවල් වලට තමා use කරන්නෙ මොකද latest ම data නෙ වැදගත්.

TCP:

හැබැයි TCP කියන්නෙ එහෙම නෙමෙ මේක මාර protocol එකක්, reliable ඒ වගේම මේක connection ( මේ connection කියන වචනෙ ඉස්සරහට හරියට වැදගත් වෙනව. ) එකක් විදියට වැඩ කරන්නෙ සරලව කිව්වොත් මුලින්ම packet කීපයක් එහාට මෙහාට (tcp handshake) කරාට පස්සෙ. එතනින් එහාට අපි ඒකට කියන්නෙ connection එකක් කියලා නැත්තන් tcp stream එකක් කියලා.  හිතන්නකෝ මේ tcp stack එකට 30MB destination ට යවන්න කියලා දෙනවා කියලා මේ tcp protocol එකෙන් අනිවාරෙන් අපිට 30MB අනිවාරෙන්ම 100% destination ට යවනවා. (ඒ කියන්නෙ 30MB send කරලා ඉවරයි කිව්වොත් අනිවාරෙන් dst ට ඒක හම්බෙලා, UDP වලින් 30MB send කරා කිව්වොත් dst ට කීයක් හම්බෙලාද කියලා දන්නෙත් නැ (special development එකක් නැතුව quic වගේ))  ඉතින් මේ tcp stack එක communicate කරන device දෙකෙම run වෙන්න ඕනෙ(නැත්තන් කොහොමද වැඩ කරන්නෙ LOl 🤦‍♂️). ඒ run වෙන වෙලාවෙ ඒ ඒ Tcp stream එකට අදාල කරන data transfer කරගන්නෙත් අර උඩ කියපු pdu හරහාම තමා. (tcp stack එකෙ data(runtime variables, state values ) transfer කරන්න වෙනම pdu යවන්නෙ නැ.) මේ layer එකේදි Pdu එකට කියන්නෙ Segment එකක් කියලා, ඉතින් මේ layer එකේ tcp run වෙද්දි එයා හැම pdu එකටම tcp header එකක් ඇතුලත් කරනවා මේකෙ අමුතු දෙයක් නැ. 

( මේ tcp connection එකක් send/receive වෙන segment එකිනෙකට සම්බන්දයි. Udp වල එහෙම නැ. ඒ වෙලාවට යවන packet එක පමණයි. )

ඒක ඇතුලෙ send කරන්න ඕනෙ data සහ අදාල් connection එක ගැන data තමා තියෙන්නෙ (සරලව, දැනට කොච්ච්‍රක් යැව්වද තව මෙච්ච්‍රක් යවන්න තියෙනවා. මෙච්චරක් හම්බුනා වගේ කියලා හිතන්නකො, connection එකට අදාල src, dst port ack, seq numbers, resv, දැන් යවන data කොටස (payload එක) අනන් මනන් පස්සෙ හොයල බලන්න, )

ඒ වගේම මේ Port කතන්දරය එන්නෙත් මෙතනදි තමා.එකම device දෙක අතරෙ එකම වෙලාවෙ source and destination (port සමාන) connection පවතින්න බැ. ඉතින් මේකෙන් අපිට එකම device එක අතරම එකම වෙලාවෙ connection කිහිපයක් පවත්තවන්න පුලුවන්. ඒ ඒ connection එක අනික් connection වලට සම්බන්දයක් නැහැ. (tcp layer එකේදි)

මේ port එකෙන් තමා ඒකට අදාලව application/service එක වෙන් කරලා හඳුනගන්නෙ, මෙහෙම Port කියලා සංකල්පයක් තිබ්බෙ නැත්තන් අපිට මුලු device එකටම same dst ට එකම connection එකක් තමා හදන්න වෙන්නෙ. ඒ නිස එකම වෙලාවෙ application/service කිහිපයකින් හෝ එකම service එකෙන් connection කිහිපයක් establish කරගන්න පුලුවන්.

මේ tcp stack එක බොහෝ දුරට run වෙන්නෙ Os එකේ Kernel එකෙන් ඒ කියන්නෙ හිතන්නකො ඔයා ඔයාගෙ program එකක මොකක් හරි server එක්කට http request එකක් ගහනවා කියලා එතකොට ඔයාගෙ program එකෙන් මේ tcp වත් එතනින් පහල (අති විශේශ අවස්ථාවක් හැරුනු කොට හෙ හේ) layers ගැනවත් බලන්නෙ නැ. OS එකට system call එකක් ගහලා තමා tcp socket එකක් ඉල්ලනවා ඉතින් ඔයාගෙ Program එකට තියෙන්නෙ ඒකට byte  write (1 byte = 8 bit) කරන්න විතරයි ඔයාට packet handle කරන්න අනන් මන්න මුකුත් අවශ්‍ය නැ. Tcp handshake ඇතුලු ඊට පහල layers ඔක්කොම Handle කරන්නෙ kernel එකෙන්

ඒ වගේම මේ connection එකක් bidirectional ඒ කියන්නෙ connection එකෙන් read කරන්නත් පුලුවන් ඒකට write කරන්නත් පුලුවන්.

පහල Img එකෙන් ඔයාලට tcp header එක බලාගන්න පුලුවන්

Ip packet And Tcp Segment (PDUs)

5. Session layer

6. Presentation layer

7. Application Layer 

මේ layers තුන ගැන මම එකටම කතා කරනවා. මේ තුන අර වගේ හරියටම වෙන් කරන්නත් බැ සමහර සමහර තැන් වලදි ඇත්තටම් මේ layers තුන තමා අපි අපේ Programs වල පාවිච්චි කරන්න. HTTP, SQL, RPC, WS, FTP, SSH, TELNET, TLS වගේ Protocol ඕක්කොම මේ ගොඩට තමා වැටෙන්නෙ මම මේවලින් කිහිපයක් විතරක් විස්තර කරනවා.

SSL/TLS

මේ ssl/tls කියන්නේ දෙකම එකයී ssl කියන්නෙ පරණ Version දැන් බොහෝදුරට use කරන්නෙ tls 1.0, 1.1, 1.2, 1.3 වගේ version. මේ tls ගැන හිතද්දි මේකත් layer එකක් වගේ හිතන්න ඒක ලේසි tls වැඩ කරන්නෙත් tcp වලට උඩින්.

Tls කියලා එකක් තියෙන්නෙ ඇයි ?

Connection එකේ data වලට security කියන දේ දෙන්න මේ Tls වලින්, මෙතනින් පහල කිසිම layer එකකින් data secure කරන්න අදාල දෙයක් කරන්නෙ නැ. ඒ නිසා src, dst අතර ඉන්න ඕනෙම (ISP) කෙනෙකුට network එක capture කරලා ඕයාගෙ private data ඕනෙම දෙයක් බලන්න පුලුවන් මොකද raw data යන්නෙ. ඉතින් ඒකට විසඳුමක් විදියට තමයි මේ tls එන්නෙ.

Tcp connection එකක් establish වුණාට පස්සෙ Tls secured connection එකක් කරනවනන් client විසින් යවනව client hello Message එක ඉතින් මේක ඇතුලෙ ගොඩක් විස්තර තියෙනව MSg Type, Version Number, Session ID,  Cipher Suites list, Sni(ඕනෙම දේ නේද 😁)  සරලව client ගැන විස්තර එයා support කරන Protocol Versions, ඊට පස්සෙ මේකට respond එක විදියට server එකෙන් server hello message එක එවනවා. ආයෙත් server එකෙන් එයාගෙ certs client ට එවනවා client මෙව්ව බලලා ( insecure true නම්) මේ certs root CA එක්කින් signed කරලද කියලා බලලා එහෙම කරලනම් connection එක establish කරනවා. (කරනව කිව්වට තව පියවර ටිකක් වෙනවා.) 

දැන් මේක Tls තියෙන connection එකක් src, dst අතර ඉන්න අයට මේකෙන් යන්නෙ මොනවද කියලා හොයන්න බැ. දැම් ඔයා http use කරත් ftp use කරත් ඔයාගෙ custom විදියට මොනවහරි binary data server එකට send කරත් මොනවත් හොයන්න බැ. 3MB file එකක් මේකට send කරන්න දුන්න කියලා මේ file එක chunks වලට කැඩිලා ඒ එක chunk එක ගාණෙ තමා encrypt වෙන්නෙ ආපහු receive වෙද්දිත් decrypt කරන්නෙ එහෙමයි ඒ එකකට tls record එකක් කියනවා. මේ tls record තම tcp protocol එක හරහා transfer වෙන්නෙ ඉතින් මැදින් ඉන්න කාටවත් මේකෙ මොනවද යන්නෙ කියල හොයන්න බැ. 

• HTTP

හැමෝම හැම තැනම කතාවෙන Protocol එක, බනිද්දිත් දැන් මේක අපි Use කරනවනෙ 😁, මේක text based protocol එකක් ඒ කිව්වෙ tcp handshake එක වෙලා tls ඇතුව හෝ නැතුව ( tls තියෙද්දි අපි මේකට කියනවා https) අපි data සෙන්ඩ් කරන්නෙ text විදියට . ඔයාල දැකලා ඇති Http request එහෙකට අදාලව http headers එහෙම තියෙනවා, ඒ වගේම http Method කියලත් තියෙනවා, GET, POST, PUT, DELETE, HEAD ඔය ආදි වශයෙන් මම පහලින් http request එකක් දාන්නම් එතකොට පැහැදිලි වෙයි මේ text based කියන්නෙ ඇයි කියලා

GET /path HTTP/1.1

Host: example.com

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36

Accept: text/html

Accept-Language: en-US,en

Accept-Encoding: gzip, br

Connection: keep-alive

ඉතින් ඔය උඩ තියෙන text ටික tcp handshake එකෙන් පස්සේ හදාගත්ත tcp socket එකට ලිව්වාම ඒක http request එකක් තමා. ඊට පස්සෙ response එක socket එකෙන් read කරගන්න ඕනෙ. ඒ වගේම ඔය තියෙන headers අදාල වෙන්නෙ ඒ අදල service එකට (ex - rest api) මේ headers අනන් මනන් මුකුත් osi model එකට අදාල නැහැ .

HTTP වලත් versions කිහිපයක් තියෙනවා 1.0, 1.1 2, 3 version num වලින්ම පේනවා 2, 3 ගොඩක් වෙනස් කියලා. H2 කියන්නෙ මම කිව්වා වගේ නෙමෙ Binary protocol එකක් 1.0 නම් දැන් use වෙන්නෙ නැ. හැම request එකකටම tcp connection එක ගාණෙ open ඛරන close කරනවා මේක ගොඩක් expensive වැඩක් efficiency ගොඩක්ම අඩුවෙනවනෙ 1.1 වල එකම connection එකේ ගොඩක් req වලට යොදා ගන්නවා

H2 මේක ගැන ම්ම විස්තර කරන්න යන්නෙ නැ කලිම් එව්වල වගෙ මේක text based නෙමෙ multiplexing  වගේ features ත් h2 යටතෙ හම්බෙනවා. ඔයාල හොයලා බලන්න

H3 මේකත් එහෙමයි අඩුම තරමෙ මේකෙ tcp use කරන්නෙත් නැ. Quic use කරන්නෙ තම්න්ට හොයලා බලන්න පුලුවන්

• Websocket

Http වගේ req, res මේකෙ නැ මෙකත් කෙලින්ම raw tcp වගේමයි bidirectional communicate කරහැකි. මේක ගොඩක් web based දේවල් වලට පාවිච්චි කරනවා real time data ගන්න chat apps, connection status, අනික browser වල directly tcp handle කරන්න බැහැනෙ, JS dev ළ දන්නව ඒ හින්ද ws තමා තියෙන්නෙ. 

ඒ වගේම මේ ws connection එකක් establish වෙන්න නම් මුලින්ම් http 1.1 req එකක් තමා server එකට යවන්නෙ අදාල port එකට ඒකෙන් ආඵු එවනව 101 response එකත් එක්ක ws වලට switch wenna පුලුවන් කියලා.

ලොකූවට විස්තර කරන්න යන්නෙ නැ ඕන අය ගිහින් හොයන්න, තව protocols තියෙනවා ඕනෙ තරම් හොයලා බලන්න, grpc, ftp, ssh

අපි බලමු දැන් සම්පූර්ණ pdu එකක් හැදෙන තැන ඉදලා dst දක්වා යන විදිය. tcp handhsake එක වෙද්දි යවන පලවෙනි syn packet එක ගමු. මුලින්ම browser (browser එකම වෙන්න ඔන්නෙ නැ) එකෙන් kernel එකට system call එකක් ගහල කියනවා connect() tcp socket එකක් ඕනෙ කියලා kernel එකෙන් තමා මේ packet එක යවන්නෙ මොකද kernel එකට තමා socket එක init කරන වැඩේ භාර වෙන්නෙ මුලින්ම syn packet එකට අදාලව source port එහෙම දාල (source port එක random select කරන්නෙ) header එක kernel එකෙන් හදනවා මේක දැන් tcp segment එකක්, ඊලගට pc එකේ routing table එක බලලා interface එකක් select කරගෙන ඒකෙ source address, dst addres එහෙම දාලා ip packet එකක් හදනවා හදලා මේක දෙනවා අදාල Interface එකට ඒකෙන් මේකට Layer 2 header එක set කරනවා දැන් මේක සම්පූර්ණ frame එකක් ඊලගට frame එක transmit කරන්න network buffer එකට දනවා. ඊට පස්සෙ මේක routers and switches ගනනාවකින් ගිහින් dst දක්වා යනවා. dst ඉදලා src දක්වා එද්දිත් වෙන්නෙ මෙහෙමයි.

Note - ඊතින් මේ මට පුලුවන් විදියට සරල ආකරයෙන් OSI reference model එකේ අවශ්‍ය ටික කියලා දුන්නෙ. මේකෙ ඕනෙ තරම් වැරදි අඩුපාඩු තියෙන්න පුලුව්න් එහෙම් තිබ්බොත් අනිවාරෙන් comment එකක් දාල කියන්න මමත් දන්න විදියට තමා කිව්වෙ.

Ipv4 (අමතර)

Ipv4 Address එකක් කියන්නෙ 32 bit වලින් හැදුනු ඇඩ්‍රස් එකක් 0.0.0.0 - 255.255.255.255 වෙනකම් ලෝකෙ address තියෙනවා. (255*255*255*255) ප්‍රමාණයක් ip address තියෙනවා මේ ලෝකෙ.

10.0.0.0 to 10.255.255.255 (10.0.0.0/8)

172.16.0.0 to 172.31.255.255 (172.16.0.0/12)

192.168.0.0 to 192.168.255.255 (192.168.0.0/16) 

මෙ උඩ තියෙන rangers තුන private ips කියලා හදුන්වන්නෙ ඒ කියන්නෙ මොකක්ද කියලා මම උදාහරනයකින් කියන්නම් ඔයා 192.168.0.1 dst තියෙන්න packet එකක් send කලොත් ඒ ip එකෙන් ඔයාගෙ Local network එකේ device එකක් තිබ්බෙ නැත්තන් ඒ පැකට් එක drop වෙනවා නැතුව ඇමරිකාව දිහා තියෙන 192.168.0.1 තියෙන device එකක්ට ඒක යන්නෙ නැ. එහෙම නැතුව ඔයා Public IP එකකට pdu එක යැව්වොත් ඒක ලෝකෙ කොහෙ තිබ්බත් හොයාගෙන යනවා ( වැඩිය හිතන්න යන්න එපා.)

DNS (අමතර)

මම සරලව කියන්නම් මේ dns ගැන. මේ ඩ්න්ස් thiyenne ip address number විදියට කාටවත් මතක තියගන්න බැහැනෙ හරිම කරදරයක් ඒක youtube.com යන්න ඕන්නම් ඔයාට අමුතු අන්ක ටිකක් මතක් තියග්න්න උනනම් කොහොමද, ipv6 වුණම හොඳටම ආතල්. ඒ හින්දා තමා මේ dns server තියෙන්නෙ dns server එකට domain Name එක යවපුවාම ඒකෙන් අනික් පැත්තට අදාල ip එක එවනවා ඉතින් අපිට මේ ip එකට dial කරලා youtube එක්ක connection එක්ක හදාගන්න පුලුවන්. ඊලගට එන ප්‍රශ්ණය තම එතකොට dns server එකේ ip එක ගන්නෙ කොහොමද කියලා. ඒකෙ Ip ගන්නෙ නැ. 1.1.1.1, 8.8.4.4 මේ වගේ public dns server දෙනවා ඒ වගෙම isp ගෙනුත් හම්බෙනවා.

Dns req කරන්න විවිද ක්‍රම තියෙනව, පහල තියෙන්නෙ කිහිපයක්

Udp, DNSSEC (TCP), DNS over HTTPS (DoH), DNS over TLS (DoT)

VPN 

දැන් බලමු මේ vpn කතන්දරය වැඩ කරන්නෙ කොහොමද කියලා. කලින් කොටස කියවන්නෙ නැතුවනන්ම් මේක කියවන්න එපා.

Free Internet Vpn ගැන කියන්න කලිම් මම මේ vpn එකක් කියන්නෙ මොකක්ද කියලා කියන්නම්

නමෙන්ම තේරෙනවනෙ Virtual private network ඒ කියන්නෙ ඉතින් මේ vpn එකක් use කරලා අපිට remotely local network එහෙකට access karanna පුලුවන්. මම කලින් කිව්වනෙ ඇමරිකාව දිහා තියෙන Pc එකක් හොයාගෙන් යන්නෙ නැ කියලා. බැරිවෙලා හරි අපිට එහෙම තියෙන private network එහෙකට access කරන්න ඕන වුණොත් කොහොමද කරන්නෙ ඉතින් මෙන්න මෙතනදි තම vpn එන්නෙ. ඔයා ඒ Remote Network එකට අදාලව තියෙන එක public ip එකකට connect වෙලා ඒ හරහ එයාලගෙ මුලු private Network එකටම access කරන්න පුලුවන්. (මෙහෙම නිකන් කියනව වගෙ නෙමෙ මෙව්ව ඇත්ත scenario වලදි ගොඩක් වෙනස් වෙන්න පුලුවන් )

තව ගොඩක් වාසි තියෙනවා අපිට vpn එකකින් (free internet නෙමෙ) Security පැත්තට තමා ගොඩක්ම ඉතින්. 

ලංකාවෙ බොහෝ දෙනා දන්නෙ vpn දැම්මාම ඔහෙ නිකන් ip මාරුවෙනව එච්චරයි.

මම නිකන් සරලව vpn එකක් වැඩ කරන්නෙ හරය කියන්න මෙ කිසිම vpn protocol එහෙකට specific විදියට නෙමෙ කියන්නෙ.

මොනවා කරන්නත් කලින් vpn server එකයි ඔයා අතරයි connection එකක් හදාගන්න ඕනෙ. මේකට tcp use කරන්නත් පුලුවන් ඊට උඩින් තව encryption දාල හරි නැත්තන් quic හරි නැත්තන් network layer එකෙම run වෙන protocol එකක් හරි කෝම හරි server, client අතරේ connection ( මෙතනදි connection එකක් කියන්නෙ tcp connection එකකටම නෙමේ ඒ වගෙම පහසුවෙන් data transfer කරගන්න විදියක් වගේ කියලා හිතන්න) එකක් හදාගන්න ඕනෙ මෙහෙම connection එකක් හදාගත්තට පස්සෙ.

Client ගේ ඔක්කොම traffic packet විදියට හෝ connections (vpn අනුව වෙනස්) විදියට අරගෙන එව්වා vpn protocol එකට ආවෙනික ක්‍රමවේද භාවිතා කරලා server එකට transfer කරනවා. raw packets පිටින් යවන්නෙ නැ අවශ්‍ය metadata ටිකයි end server එකට යවන්න ඕනෙ data යි යවන්නෙ.

( 

උදාහරණයක් විදියට, vpn දාල ඔයා youtube.com යන්න යනවා කියලා එතකොට වෙන්නෙ මේ youtube එකට යන්න ඕන packets vpn එකෙන් Interrupts කරලා අරගෙන vpn එක server එකත් එක්ක හදලා තියෙන connection එකට අර පැකට් එකට අදාලව තියෙන විස්තර යවනන්වා Youtube නම්,

මුලින්ම අපි හිතමු dst address, dst port, domain (if needed) vpn protocole එකට අදාල දේවල යවලා. 

1. Vpn server එකයි Youtube server අතරෙයි tcp connection එක
2. අපියි vpn server එකයි අතරෙ tcp connection එක
3. Device එකෙන් යන ඔක්කොම traffic interrupt කරලා ගන්න එක

මෙන්න මේ උඩ සිද්දි තුන කරගන්නවා.

දැන් හරි දැන් ඔයා browser එකෙන් Youtube.com එකට මම කලිම් කිව්ව Http req එකක් ලිව්වොත් (Tcp connection එකට) ඒක ලියවෙනව 2 connection (උඩ තුනෙන්) එකට ඊට පස්සෙ ආයෙ ඒක ලියවෙනවා 1 connection එකට එතකොට ඇත්තටම Youtube වලට පේන්නෙ මේක vpn server එකේ ඉදලා එනවා වගේ මොකද transport layer එකට පහල ඔක්කොම layers vpn server එකට අදාලව වැදුනු එව්වා තමා youtube වලට පේන්නෙ ( ඒ නිසා තමා ip addres එහෙම වෙනස් වෙනවා කියන්නෙ) http response එක read වෙද්දිත් මේකම අනික් පැත්තට වෙනවා.

අපියි Vpn server එකයි අතරෙ තියෙන connection එක හැම connection එකක් ගානෙම ඒකත් අලුත් එකක් හදනවා වෙන්නත් පුලුවන් නැත්තන් Multiplexing වගේ use කරනවා වෙන්නත් පුලුවන් ( එක එක vpn එකෙන් එකට වෙනස් ) නැත්තන් එහෙම connection හදන්නෙත් නැ network layer එකෙ වගේ operate වෙන්නත් පුලුවන් (ex:- wireguard, ipsec),

)

OpenVPN: Highly secure and widely used open-source protocol.

IPSec: Internet Protocol Security, often paired with L2TP.

WireGuard: Lightweight and faster than traditional protocols.

PPTP: Point-to-Point Tunneling Protocol, less secure but faster.

IKEv2/IPSec: Reliable and secure, especially for mobile devices.

මේ protocols ගැන තමන්ට හොයලා බලන්න පුලුවන් 

FREE Internet

දැන් කතා කරමු free Internet වැඩ කරන ආකාරය.

මේ free Internet කතන්දරේ එන්නෙ මේ isp දෙන packages based කරගෙනනෙ ඉතින් හැමෝටම ප්‍රශ්නයක් ඇති ISP කොහොමද මේ යන connections හරියටම ඒ ඒ අදාල service වලට යන්නෙ කියලා detect කරන්නෙ කරන්න ක්‍රම ගොඩක් තියෙ මේ තියෙන්නෙ කිහිපයක්

1 Dns request check.

2 Dst Address check කිරීම.

3 Tls නැතිවිට http header වල host check කිරීම.

4 Tls Client Hello Message එකේ Sni check කිරීම.

මේවා විතරක් නෙමේ තව ඉතින් එක එක විදියට check කරනවා වෙන්න පුලුවන් තව කොච්චර parameters තියෙනවද connection එහෙක. බොහෝ සෙයින් කතා වෙන්නෙ මෙව්වා හින්දා මම මේ සෙට් එක ගැන කියන්නම්.

Dns req කරන්න තිබ්බ ක්‍රම දැක්ක ගමන් තේරෙනවා මේක ISP පැත්තෙන් කරා කියලා කිසිම තේරුමක් නැ. ඒක අපි එහෙමම් අතැරල දාමු.

ඊලගට එන වැඩේ තමා අති සාර්ථක දේ (ISP පැත්තෙන් ) අපිට කට උත්තර නැ. හිතන්නකො packet එකක් isp හරහා යනවා කියලා ISp චෙක් කරනවා මේකෙ destination ip බලලා ඒ අදාල client එවලෙට මේ service එකට ගියහැකිද package එකක් දාලද anytime data තියේද කියල බලනවා. ( බලනව කියන්නෙ මෙව්ව programs හරිද මනුස්සයො බලන්නෙ නැ 😅) ඉතින් client ට service එක valid නම් ඒක forward කරනව. ඇයි ඉතින් මේක හැම එකටම කරන්න බැරි. මේක හැම එකටම කරන්න බැරි වෙන්නෙ youtube වගෙ ගත්තොත් ip අති විශාල ප්‍රමණයක් තියෙනවා සමහර්ක් වෙලාවට ඒ ip වලින්ම Google ලගෙ වෙනත් service වලට access කරහැකි, cdn network එකක් ip allow කරොත් එහෙම තම හොඳටම කෙලවෙන්නෙ. මේ වගේ ප්‍රශ්ණ එනවා ගොඩක්.

ඒ හින්දා තව බලන දෙයක් තමා tls auth එකෙ client hello එක වෙනවනන් ඒ වෙනකන් packet එහාට මෙහාට transfer වෙන්න දීලා ( client hello එක sni එක check කරන එක එතකොට ඒ client අදාල sni එකට ගැලපෙන්න packages දාලනම් එතනින් එහාට මුලු tcp stream එකම connection එක close කරනකම් allow කරනව. ( මම හිතන විදිය සහ අත්දැකල තියෙන විදියට වෙන දේ,  ඇත්තටම් වෙන දෙ ඉතින් ISP වැඩ කරන කෙනෙක්ගෙන් තමා අහන්න වෙන්නෙ. ) ඕනම ip address එකක් එක්ක් tcp handshake එක වෙනකම් packets transfer කරගන්න පුලුවන් ඔන්න්ම check කරල බලන්න නැත්තන් කොහොමද එයාල client hello එක හරි http host (without tls) බලන්නෙ. මේ tls sni චෙක් කරනවා වගේම තම http host බලන්නෙත්.

දැන්නම් ඉතින් සමහරුන්ට හිතාගන්නත් පුලුවන් ඇති free internet වැඩ කරන්නෙ කෝමද කියල.

ISP විසින් භාවිත කරන මේ 3, 4 ක්‍රම නිසා තමා අපි ගොඩක්ම free internet access ගන්නෙ එහෙමත් නැත්තන් cdn ip එකක් allow කරොත් හරි ඒ ගැන අවසානෙට කතා කරන්න බලමු.

මම මේ ගැන කතා කරන්න vless කියන protocol එක උදාහරණයක් විදියට ගන්නම්. මේක specially design කරලා තියෙන්නෙ මේ වැඩේ කරග්න්න තමයි. මේ වැඩේ කිව්වෙ ලන්කාවෙ free internet සිද්දිය නෙමේ මම පහලින් කියන්න යන එක

මේ vless protocol අර කලිම් කියපු standard vpn protocol වගේ නෙමෙ vpn එකක් ලක්ශන ඔක්කොම වගේ මේකෙත් තියෙනවා ඊටත් වඩ වෙනස් දේවල් ටිකකුත් තියේ ඒ වගේම client and vpn server එක අතරෙ tcp connection පමණයි තියෙන්නෙ. ඉතින් මේ client හා vpn server එක අතරේ connection එකක් හදාගනිද්දි මුලිනම් tcp handshake සාම්න්‍ය විදියට කරනවා ඊට පස්සෙ. අපි දීල තියෙන configuration අනුව ( අපි හිතමු tls + ws config එකක් ) බොරු tls connection එකක් හදන්න client hello එකක් යවනවා. ඒකෙ අපිට ඕනෙ sni තමා තියෙන්නෙ මොකද server එකත් අපේනෙ ඒ හින්ද server එකෙ reject කරන්නෙ නැ අපිට ඕනෙ දෙයක් කරහැකි. ඉතින් client hello එකේ මේ යවන බොරු sni එක ISP check වෙනව ඒකෙන් හිතනවා ආ හරි මේ යන්නෙ පැකේජ් එකට අදාලව තමා එතනින් එහාට මුලු tcp stream එකම allow කරනව. ( මේ streme එකම allow වෙන කතාව මම හිතන විදියට එහෙම තමා වෙනවත් ඇත්තෙ ගොඩක් වෙලාවට ඒක දන්න කෙනෙක් ඉන්නවනන් නිවැරදි කරන්න.)

මම අර vpn ගැන කියද්දි කිව්ව අපියි vpn server එකයි අතර connection එක හරි ඒ වගේම මේ connection එකට තමා ISP අදාල වෙන්නෙ server එකෙන් එලියට යන එකවත් අපේම device එකේ packet interrupt කරන එකටවත් ISP අදාල නැ

ඉතින් කලිම් vpn වලදි කිව්වා වගේ මේකට ඉදිරියට function වෙන්න පුලුවන්.

vmess, trojan, ssh+stunnel මේ ඔක්කොගෙම client සහ vpn අතර connection establish වෙන්නෙ මේ විදියටමයි එතනින් එහා දේවල් වෙනස් වෙනවා.

Protocol headers, vmess වලනම් එතනින් එහා tcp වලින් data transfer කරද්දි එව්ව ඔක්කොම encrypt කරනවා, මම පහලින් vless header එකේ ss එකක් දාන්නම් 

Connection between vpn server and client:

දැන් ඔයාල ආයෙ බලයි මේක කොයි වෙලාවෙද යන්නෙ කියලා. මතක තියාගන්න අපි මේ කතා කරන්නෙ vpn server and client අතර connection එක ගැන

මුලින්ම client විසින් server එකත් එක්ක tcp handshake එක කරගන්න ඕන. මේක කරගන්න කොහොමත් ISP අවසර දෙනවා නැත්තන් එයාට බලාගන්නත් නැනෙ.

ඊට පස්සෙ client විසින් බොරුවට configuration අනුව tls (config එක ws + tls කියලා හිතමු) client hello එක ය්වද්දිම isp බලනවා sni එක මොකක්ද කියලා sni එක එයාලගෙ එවලෙට පවතින rules (client ගෙ state එක අනුව වෙනස් activate කරලා තියෙන packages data තියෙනවද නැද්ද) ගැලපෙනවනම් එතනින් එහාට stream එකම allow කරනව. ඊට පස්සෙ අපිට vpn සහ client අතරේ connection එකක් හැදිලා තියෙන්නෙ tls ත් දැන් වැටිලා ඉවරයි කියමුකො. 

ඊට පස්සෙ මේක ws නිසා ws handshake එක වෙනවා http1.1 req එක එහෙම යවලා ඒකත් ඉවර වුණාම. දැම් හරි vpn එකේ ඇත්තටම data යවන්න මේ connection එක ready. (මේක දැම් ඇත්තටම tcp ත් නේමෙ ws connection එකක් ඒත් යටින් දුවන්නෙ tcp ම තමා )

දැම් හිතන්න client browser එකෙන්  twitter  ( free internet ) යන්න හදද්දි තමා අර server එකයි client අතරෙයි connection එක හැදුනෙ කියලා ඉතින්, ඇත්තම twitter වලට browser එකෙන් යවපු req එක තාම තියෙන්නෙ client ලග vpn එකෙ buffer වෙලා. දැම් ඒ twitter වලට අදාලව buffer වෙච්ච conn එකේ data සහ vpn configuration එකෙ data ( uuid, protocol version) වලින් අර ss එකෙ දාපු vpn header එක පුරවනවා. පුරවලා ඒක සම්පූර්ණ එක client vpn අතර තියෙන connection එකට ලියනවා.

(මේ uuid එකක් use කරන්නෙ client ව විශේශයෙන් අදුරගන්න නැත්තන් හැමෝටම ඔහෙ නිකන් server එක use කරහැකි. එහෙම නැතුව වැරදි uuid එකක් ආවොත් server එකෙන් connection close කරලා දාන්න පුලුවන්)

ඉතින් මේක receive කරගන්නවා vpn server එක විසින් ඊතින් ඒකෙන් මෙ header එක ලෙහලා ඒකෙ තියෙන info ( Address Port)  අරගෙන ඒකට connection එකක් Dial කරනවා. Dial කරලා ඒකට Request Data ටික write කරනවා. ඉතින් මේ write කරන්නෙ ඇත්තම twitter server එකත් එක්ක හැදුන connection එකට මේ write වෙන්නෙ අර client ගෙන් browser එකෙන් ආපු http request එක ඒකට response එක විදියට twitter වලින් vpn server එකට එවනවා. Vpn server එකෙන් මේ එන data උඩ img එකේ පහලින් තියෙන response header එකට දාල client ට එවනවා vpn client මේක අරගෙන් එයාගෙම් pc එකෙ අදාල application ව්ලට මේක දෙනවා. මෙතනින් පස්සෙ ආයෙ මේ client and vpn server connection එකේ vpn headers response headers read/write වෙන්නෙ නැ. Twitter ඒ අදාල connection එකටම ලියන data කෙලින්ම vpn server එකටත් vpn server එකෙන් twitter server එකටත් ලියනවා අනික් පැත්තටත් එහෙමයි. (vmess & trojan වලත් සන්කල්පය එකමයි මේ headers වගේ දේවල් වෙනස් වෙනවා, data හසුරවන විදි අනුව performance වෙනස්කනුත් එනවා. Vmess වල තවත් encryption එකක් දුවන නිසා performance වලට කොහොමත් බලපෑමක් තියෙ)

ඔයාලට පහල Img එක බලලා මේක තව දුරටත් තෙරුම් ගන්න පුලුවන්. ඒකෙ ඒ වගෙ එක tcp connection එකක් ගැන විතරයි විස්තර කරලා තියෙන්නෙ Application එකෙන් connection එකක් ඉල්ලන වාරයක් ගාණෙ මේ වගෙ සම්පූර්ණ cycle එකක් vpn & client connection, vpn & actual server connection හැදෙනවා. ( multiplex use කරනවනන් පොඩ්ඩක් වෙනස් vpn server & client අතර connection කිහිපයක් විතරක් අතර පවත්වගෙන ඒ සෙට් එකෙන් ඉතුර් connection ඔක්කොම wrap කරනවා මේක වැඩිය හිතන්න එපා.)

මේකෙ වැරදි අඩුපාඩු ඇති සහ මම මේ මූලික අදහස දුන්නෙ කොහොමද වෙන්නෙ කියලා තව ගොඩාක් දෙවල් තියේ දැන් තම්න්ටම ඒ දේවල් හොයලා බලන්න පුලුවන්. මොනවහරි වැරැද්දක් තිබ්බොත් comment එකක් දාන්න ඒ වගේම මේක යාලුවන්ටත් share කරන්න.