diff --git a/report/report.pdf b/report/report.pdf index 4d480c0..1d23e95 100644 Binary files a/report/report.pdf and b/report/report.pdf differ diff --git a/report/report.tex b/report/report.tex index 9f45e01..4891361 100644 --- a/report/report.tex +++ b/report/report.tex @@ -153,6 +153,13 @@ \newcommand{\arpDecodedUrl}{\repoGithub/blob/HEAD/exercise/results/exp2-arp/arp-decoded.txt} \newcommand{\arpPcapUrl}{\repoGithub/blob/HEAD/exercise/results/exp2-arp/arp.pcap} +% Experiment 3 +\newcommand{\routingExecutionUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/execution.txt} +\newcommand{\icmpAPcapUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-A.pcap} +\newcommand{\icmpBPcapUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-B.pcap} +\newcommand{\icmpADecodedUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-A-decoded.txt} +\newcommand{\icmpBDecodedUrl}{\repoGithub/blob/HEAD/exercise/results/exp3-routing/icmp-B-decoded.txt} + \begin{document} \InsertTitle @@ -1156,20 +1163,343 @@ Reply 192.168.1.131 is-at 4a:6f:2a:18:f4:80 Παρόλα αυτά το γεγονός ότι υπήρχε δεύτερο ζεύγος μας προβλημάτισε ιδιαίτερα μέχρι να ανακαλύψουμε τον λόγο ύπαρξής του! +% ========================= Πείραμα 3 ========================= + +\section{Πείραμα 3 -- Δρομολόγηση L3 και αλλαγή MAC} + +\subsection{Σκοπός και πειραματική διαδικασία} + +Σκοπός του τρίτου πειράματος είναι η παρατήρηση της προώθησης ενός IP πακέτου μεταξύ δύο διαφορετικών +υποδικτύων μέσω του δρομολογητή \texttt{r0}. +Ειδικότερα, εξετάζεται ο τρόπος με τον οποίο ο \texttt{h1} αποφασίζει ότι ο \texttt{h3} βρίσκεται σε διαφορετικό +υποδίκτυο, καθώς και οι μεταβολές των MAC διευθύνσεων και του TTL κατά τη διέλευση από τον router. + +Το πείραμα εκτελέστηκε στην ήδη ενεργή τοπολογία, στην οποία ο \texttt{h1} είχε αποκτήσει μέσω DHCP τη διεύθυνση +\texttt{192.168.1.131/24}, ενώ ο \texttt{h3} χρησιμοποιούσε τη στατική διεύθυνση +\texttt{192.168.2.10/24}. +Πριν από την καταγραφή εκκαθαρίστηκαν οι neighbor tables των δύο hosts και του router, ώστε να απομακρυνθεί +προϋπάρχουσα κατάσταση ARP. + +Οι πρώτες εντολές της εκτέλεσης ήταν: + +\begin{minted}{bash} + mininet> h1 ip neigh flush all + mininet> h3 ip neigh flush all + mininet> r0 ip neigh flush all + + mininet> h1 ip -4 -br addr + mininet> h1 ip route + + mininet> r0 ip -4 -br addr + mininet> r0 ip route + + mininet> h3 ip -4 -br addr + mininet> h3 ip route +\end{minted} + +Η κατάσταση διευθυνσιοδότησης και δρομολόγησης που επιβεβαιώθηκε ήταν: + +\begin{minted}{text} +h1: +192.168.1.131/24 +default via 192.168.1.1 dev h1-eth0 + +r0: +r0-eth0: 192.168.1.1/24 +r0-eth1: 192.168.2.1/24 + +h3: +192.168.2.10/24 +default via 192.168.2.1 dev h3-eth0 +\end{minted} + +Στη συνέχεια ξεκίνησαν \textbf{δύο ταυτόχρονες καταγραφές ICMP}, μία στο Subnet A μέσω του \texttt{h1} και μία +στο Subnet B μέσω του \texttt{h3}. +Έτσι, το ίδιο ICMP Echo Request μπορούσε να παρατηρηθεί πριν και μετά την προώθησή του από τον \texttt{r0}. + +\begin{minted}{bash} + mininet> h1 rm -f /tmp/icmp-A.pcap + mininet> h3 rm -f /tmp/icmp-B.pcap + + mininet> h1 tcpdump -i h1-eth0 -n icmp -w /tmp/icmp-A.pcap & + mininet> h3 tcpdump -i h3-eth0 -n icmp -w /tmp/icmp-B.pcap & + + mininet> h1 ps aux | grep tcpdump + mininet> h3 ps aux | grep tcpdump + + mininet> h1 ping -c 1 192.168.2.10 + + mininet> h1 pkill -INT tcpdump + mininet> h3 pkill -INT tcpdump +\end{minted} + +Το ping ολοκληρώθηκε επιτυχώς: + +\begin{minted}{text} +64 bytes from 192.168.2.10: icmp_seq=1 ttl=63 time=1.66 ms + +1 packets transmitted, 1 received, 0% packet loss +\end{minted} + +Μετά την καταγραφή εμφανίστηκαν οι MAC διευθύνσεις των τεσσάρων interfaces που συμμετέχουν στη διαδρομή και +διαβάστηκαν τα δύο αρχεία \texttt{pcap} με εμφάνιση των Ethernet headers: + +\begin{minted}{bash} + mininet> h1 ip link show h1-eth0 + mininet> h3 ip link show h3-eth0 + mininet> r0 ip link show r0-eth0 + mininet> r0 ip link show r0-eth1 + + mininet> h1 tcpdump -n -e -vv -r /tmp/icmp-A.pcap + mininet> h3 tcpdump -n -e -vv -r /tmp/icmp-B.pcap +\end{minted} + +Η πλήρης συνεδρία της εκτέλεσης βρίσκεται στο \href{\routingExecutionUrl}{\texttt{execution.txt}}. +Οι αρχικές καταγραφές διατίθενται στα \href{\icmpAPcapUrl}{\texttt{icmp-A.pcap}} και +\href{\icmpBPcapUrl}{\texttt{icmp-B.pcap}}, ενώ οι αποκωδικοποιημένες μορφές τους βρίσκονται στα +\href{\icmpADecodedUrl}{\texttt{icmp-A-decoded.txt}} και \href{\icmpBDecodedUrl}{\texttt{icmp-B-decoded.txt}}. + +\subsection{Απόφαση δρομολόγησης μέσω bitwise AND -- Ζητούμενο 3.1} + +Ο \texttt{h1} πρέπει αρχικά να αποφασίσει αν η διεύθυνση προορισμού \texttt{192.168.2.10} ανήκει στο ίδιο +υποδίκτυο με τη δική του διεύθυνση \texttt{192.168.1.131/24}. +Για τον σκοπό αυτό εφαρμόζεται bitwise AND μεταξύ κάθε διεύθυνσης και της μάσκας +\texttt{255.255.255.0}. + +Για τη διεύθυνση του \texttt{h1} προκύπτει: + +\[ +192.168.1.131 +\mathbin{\&} +255.255.255.0 += +192.168.1.0 +\] + +ενώ για τη διεύθυνση προορισμού: + +\[ +192.168.2.10 +\mathbin{\&} +255.255.255.0 += +192.168.2.0 +\] + +Η διαφορά φαίνεται ήδη στο τρίτο octet: + +\begin{minted}{text} +h1: + 00000001 +AND 11111111 + = 00000001 + +h3: + 00000010 +AND 11111111 + = 00000010 +\end{minted} + +Εφόσον \texttt{192.168.1.0} και \texttt{192.168.2.0} είναι διαφορετικές network addresses, ο \texttt{h1} +συμπεραίνει ότι ο προορισμός \textbf{δεν βρίσκεται στο τοπικό του subnet}. +Συμβουλεύεται επομένως τον πίνακα δρομολόγησης και χρησιμοποιεί την προεπιλεγμένη διαδρομή: + +\begin{minted}{text} +default via 192.168.1.1 dev h1-eth0 +\end{minted} + +Το IP packet εξακολουθεί να έχει ως τελικό προορισμό την \texttt{192.168.2.10}, αλλά το Ethernet frame που +δημιουργεί ο \texttt{h1} αποστέλλεται στη MAC διεύθυνση του gateway \texttt{r0-eth0}. + +\subsection{Σύγκριση του ICMP Echo Request στα δύο υποδίκτυα -- Ζητούμενο 3.2} + +Οι MAC διευθύνσεις των interfaces που συμμετέχουν στη διαδρομή καταγράφηκαν πριν από την ανάλυση των πακέτων. +Οι τιμές που προέκυψαν κατά τη συγκεκριμένη εκτέλεση ήταν: + +\begin{table}[H] + \centering + \begin{tabular}{lll} + \textbf{Interface} & \textbf{IPv4} & \textbf{MAC} \\ \hline + \texttt{h1-eth0} & \texttt{192.168.1.131} & \texttt{4a:6f:2a:18:f4:80} \\ + \texttt{h3-eth0} & \texttt{192.168.2.10} & \texttt{2e:ef:81:65:2c:c9} \\ + \texttt{r0-eth0} & \texttt{192.168.1.1} & \texttt{ea:2e:7b:6d:78:82} \\ + \texttt{r0-eth1} & \texttt{192.168.2.1} & \texttt{7e:41:8e:cb:65:05} \\ + + \end{tabular} + \caption{Διευθύνσεις των interfaces που συμμετέχουν στη δρομολόγηση.} +\end{table} + +Στο Subnet A το ICMP Echo Request καταγράφηκε στη διεπαφή \texttt{h1-eth0} ως: + +\begin{minted}{text} +4a:6f:2a:18:f4:80 > ea:2e:7b:6d:78:82 +ttl 64 +192.168.1.131 > 192.168.2.10 +ICMP echo request, id 4650, seq 1 +\end{minted} + +Η source MAC είναι επομένως η MAC του \texttt{h1-eth0}, ενώ η destination MAC είναι εκείνη του +\texttt{r0-eth0}. +Το Ethernet frame στο Subnet A παραδίδεται δηλαδή από τον \texttt{h1} στην τοπική διεπαφή του gateway. + +Μετά την προώθηση του IP packet από τον \texttt{r0}, το ίδιο Echo Request καταγράφηκε στη διεπαφή +\texttt{h3-eth0} του Subnet B ως: + +\begin{minted}{text} +7e:41:8e:cb:65:05 > 2e:ef:81:65:2c:c9 +ttl 63 +192.168.1.131 > 192.168.2.10 +ICMP echo request, id 4650, seq 1 +\end{minted} + +Στο δεύτερο subnet η source MAC είναι πλέον η MAC του \texttt{r0-eth1}, ενώ η destination MAC είναι η MAC του +\texttt{h3-eth0}. +Ο router έχει επομένως δημιουργήσει νέο Ethernet frame για το επόμενο Layer-2 τμήμα της διαδρομής. + +Οι δύο καταγραφές επιτρέπουν την άμεση σύγκριση των πεδίων του ίδιου ICMP Echo Request: + +\begin{table}[H] + \centering + \small + \begin{tabularx}{\textwidth}{ + >{\raggedright\arraybackslash}p{3.0cm} + >{\raggedright\arraybackslash}X + >{\raggedright\arraybackslash}X + } + \textbf{Πεδίο} & \textbf{Subnet A} & \textbf{Subnet B} \\ \hline + Source IP & \texttt{192.168.1.131} & \texttt{192.168.1.131} \\ + Destination IP & \texttt{192.168.2.10} & \texttt{192.168.2.10} \\ + + Source MAC & \texttt{4a:6f:2a:18:f4:80} (\texttt{h1-eth0}) & \texttt{7e:41:8e:cb:65:05} (\texttt{r0-eth1}) \\ + Destination MAC & \texttt{ea:2e:7b:6d:78:82} (\texttt{r0-eth0}) & \texttt{2e:ef:81:65:2c:c9} (\texttt{h3-eth0}) \\ + + TTL & \texttt{64} & \texttt{63} \\ + \end{tabularx} + \caption{Σύγκριση του ICMP Echo Request στα δύο υποδίκτυα.} +\end{table} + +Η διαδρομή του Ethernet frame μπορεί επομένως να αποδοθεί συνοπτικά ως: + +\begin{minted}{text} +Subnet A ---- → | r0 | ← ---- Subnet Β + h1-eth0 → [r0-eth0 → routing → r0-eth1] → h3-eth0 +\end{minted} + +Οι IP διευθύνσεις, το ICMP identifier \texttt{4650} και το sequence number \texttt{1} επιβεβαιώνουν ότι οι δύο +καταγραφές αφορούν το \textbf{ίδιο ICMP Echo Request}. +Οι IP διευθύνσεις παραμένουν ίδιες, ενώ οι MAC διευθύνσεις αντικαθίστανται από εκείνες των interfaces που +συμμετέχουν στο εκάστοτε Layer-2 segment. + +Παράλληλα, το TTL μειώνεται από \texttt{64} σε \texttt{63}. +Η μεταβολή αυτή αποτελεί άμεση ένδειξη ότι το IP packet προωθήθηκε από έναν router, καθώς το TTL μειώνεται κατά +μία μονάδα σε κάθε Layer-3 hop. + +\subsection{Μεταβολή των MAC διευθύνσεων και διατήρηση των IP} + +Η διαφορετική συμπεριφορά των IP και MAC διευθύνσεων οφείλεται στο διαφορετικό πεδίο ισχύος των δύο επιπέδων. +Οι IP διευθύνσεις χαρακτηρίζουν τους \textbf{τελικούς endpoints της επικοινωνίας}, ενώ οι MAC διευθύνσεις +χρησιμοποιούνται για την παράδοση ενός Ethernet frame μέσα σε ένα συγκεκριμένο Layer-2 δίκτυο. + +Στο Subnet A ο \texttt{h1} δημιουργεί ένα IP packet με source \texttt{192.168.1.131} και destination +\texttt{192.168.2.10}. +Επειδή ο προορισμός βρίσκεται σε διαφορετικό subnet, το packet τοποθετείται σε Ethernet frame με destination +τη MAC του \texttt{r0-eth0}, δηλαδή τη MAC της διεπαφής του gateway που βρίσκεται στο ίδιο subnet με τον +\texttt{h1}. + +Ο \texttt{r0} παραλαμβάνει το Ethernet frame από το \texttt{r0-eth0}, αφαιρεί το Layer-2 header και εξετάζει +το IP packet. +Με βάση τον πίνακα δρομολόγησής του επιλέγει ως εξερχόμενη διεπαφή το \texttt{r0-eth1}, μειώνει το TTL κατά μία +μονάδα και δημιουργεί \textbf{νέο Ethernet frame} για το Subnet B. +Στο νέο frame source MAC είναι η MAC του \texttt{r0-eth1} και destination MAC η MAC του \texttt{h3-eth0}. + +Η διαδικασία αποτυπώνεται στις πραγματικές τιμές της καταγραφής ως: + +\begin{minted}{text} +Subnet A: +4a:6f:2a:18:f4:80 -> ea:2e:7b:6d:78:82 +h1-eth0 r0-eth0 +IP: 192.168.1.131 -> 192.168.2.10 +TTL: 64 +Subnet B: +7e:41:8e:cb:65:05 -> 2e:ef:81:65:2c:c9 +r0-eth1 h3-eth0 +IP: 192.168.1.131 -> 192.168.2.10 +TTL: 63 +\end{minted} + +Επομένως, οι MAC διευθύνσεις έχουν \emph{hop-by-hop} σημασία και αλλάζουν όταν το IP packet προωθείται από τον +δρομολογητή σε διαφορετικό Layer-2 δίκτυο. +Αντίθετα, οι IP διευθύνσεις έχουν \emph{end-to-end} σημασία και παραμένουν ίδιες από τον αρχικό αποστολέα μέχρι +τον τελικό προορισμό, καθώς στην τοπολογία δεν πραγματοποιείται μετάφραση διευθύνσεων NAT. + +Η ίδια συμπεριφορά παρατηρείται και στην αντίστροφη κατεύθυνση. +Στο Subnet B το ICMP Echo Reply καταγράφηκε ως: + +\begin{minted}{text} +2e:ef:81:65:2c:c9 > 7e:41:8e:cb:65:05 +ttl 64 +192.168.2.10 > 192.168.1.131 +ICMP echo reply, id 4650, seq 1 +\end{minted} + +Μετά την προώθησή του από τον \texttt{r0}, το ίδιο Reply εμφανίζεται στο Subnet A ως: + +\begin{minted}{text} +ea:2e:7b:6d:78:82 > 4a:6f:2a:18:f4:80 +ttl 63 +192.168.2.10 > 192.168.1.131 +ICMP echo reply, id 4650, seq 1 +\end{minted} + +Η αντίστροφη πορεία επιβεβαιώνει το ίδιο αποτέλεσμα: οι IP διευθύνσεις παραμένουν σταθερές, οι MAC διευθύνσεις +προσαρμόζονται στο εκάστοτε Layer-2 segment και το TTL μειώνεται κατά μία μονάδα κατά τη διέλευση από τον +\texttt{r0}. +\section{Συμπεράσματα} +Στην παρούσα εργασία υλοποιήθηκε ένας γενικός builder δικτυακών τοπολογιών για το Mininet, βασισμένος σε μία +δηλωτική γλώσσα περιγραφής σε JSON. +Η σχεδίαση της DSL βασίστηκε στον διαχωρισμό της επιθυμητής τοπολογίας από τις λεπτομέρειες της εκτέλεσης και +στην αντιστοίχιση των αφαιρέσεων της γλώσσας σε συγκεκριμένες δυνατότητες του Mininet και του Linux. +Η υλοποίηση οργανώθηκε με \textbf{compiler-like αρχιτεκτονική}, στην οποία η αρχική περιγραφή περνά διαδοχικά +από τα στάδια φόρτωσης, parsing, validation, planning και rendering. +Ο διαχωρισμός αυτός επέτρεψε κάθε στάδιο να έχει σαφή ευθύνη, ενώ το \texttt{ExecutionPlan} λειτουργεί ως +πλήρως επιλυμένη ενδιάμεση αναπαράσταση πριν από την παραγωγή του τελικού κώδικα. +Το παραγόμενο \texttt{topology.generated.py} αποτελεί την εκτελέσιμη ``assembly'' της DSL και ταυτόχρονα ένα +ανθρώπινα αναγνώσιμο artifact, το οποίο μπορεί να επιθεωρηθεί ανεξάρτητα πριν από την πραγματική εκτέλεση. +Η τοπολογία της εργασίας δημιουργήθηκε αποκλειστικά από το αντίστοιχο \texttt{topology.json}, χωρίς να απαιτείται +ειδική λογική στον builder για το συγκεκριμένο δίκτυο. +Η ίδια περιγραφή χρησιμοποιήθηκε για την αυτόματη δημιουργία των hosts, switches και links, την παραμετροποίηση +του router και την εκκίνηση της υπηρεσίας DHCP. +Τα τρία πειράματα επέτρεψαν την παρατήρηση της λειτουργίας του δικτύου σε διαφορετικά επίπεδα. +Στο πρώτο πείραμα καταγράφηκε η διαδικασία D.O.R.A. του DHCP και επιβεβαιώθηκε η απόκτηση δυναμικής διεύθυνσης +από τον \texttt{h1}, καθώς και η broadcast φύση του αρχικού DHCP Request. +Στο δεύτερο πείραμα παρατηρήθηκε η επίλυση μιας IPv4 διεύθυνσης σε MAC μέσω ARP, με broadcast Request και +unicast Reply. +Τέλος, στο τρίτο πείραμα καταγράφηκε το ίδιο ICMP Echo Request στις δύο πλευρές του router και επιβεβαιώθηκε +πειραματικά ότι οι IP διευθύνσεις παραμένουν σταθερές end-to-end, ενώ οι MAC διευθύνσεις μεταβάλλονται +hop-by-hop και το TTL μειώνεται κατά μία μονάδα κατά τη δρομολόγηση. -\subsection{Συμπεράσματα} -... +Ιδιαίτερη σημασία είχε το γεγονός ότι οι πραγματικές καταγραφές δεν περιορίστηκαν πάντα στην ελάχιστη +θεωρητική ακολουθία μηνυμάτων. +Στο DHCP, για παράδειγμα, παρατηρήθηκε επαναμετάδοση του Discover πριν από την ολοκλήρωση της διαδικασίας, ενώ +στο ARP εμφανίστηκε επιπλέον ανταλλαγή σχετική με τη διαχείριση του neighbor cache. +Οι παρατηρήσεις αυτές δείχνουν τη διαφορά ανάμεσα στην αφαιρετική περιγραφή ενός πρωτοκόλλου και στη συμπεριφορά +ενός πραγματικού δικτυακού stack. -\section{Σύνοψη} +Συνολικά, η εργασία συνέδεσε δύο διαφορετικά επίπεδα αφαίρεσης: από τη μία τη δηλωτική περιγραφή και αυτόματη +κατασκευή της υποδομής και από την άλλη την παρατήρηση των πραγματικών πακέτων που παράγονται κατά τη λειτουργία +της. +Ο διαχωρισμός αυτός καθιστά τον builder επαναχρησιμοποιήσιμο για διαφορετικές τοπολογίες, ενώ παράλληλα +διατηρεί τη δυνατότητα λεπτομερούς ελέγχου της συμπεριφοράς του δικτύου μέσω των συνηθισμένων εργαλείων Linux. +Η ίδια αρχιτεκτονική μπορεί να επεκταθεί με νέα είδη services, περισσότερες παραμέτρους συνδέσμων ή διαφορετικά +backend-specific settings, χωρίς να απαιτείται αλλαγή της βασικής ροής του builder. -Τέλος, ... \end{document}